View templating for .lucee code? Use CFML

dev google-group-archive
1

G’day:
There’s been a lot of back-and-forth about Lucee and view template
implementations, and tags in .lucee files (or no tags in .lucee files!)
etc.

One good idea our mate Abram Adams had seems painfully obvious once it’s
pointed out…

… just use CFM files for the views.

This pretty much kills (in a good way) the conversation about which tags to
support, which tags to include, how few one should use etc.

We can all just do what we like. I’d use and , and probably
not much else. Someone else can use , , ,
whatever.

I also think this is still OK with the direction the Association seems to
want to take with distancing itself from CFML to an extent: it’s a
reasonable separation, and I think there’s still a good case to be made for
CFML’s approach for view templating. They could even go as far as losing
the “<cf” prefix and just run with “<lc:” or something, or get rid of the
prefix completely. I can’t see that being tricky for the parser to deal
with?

Good thinking Abram.

What do y’all think?–
Adam

2

+1 Adam Adam for voicing that.

(note for wording below: when I refer to Lucee, I mean the entire platform
(cfml + new dialect), when I refer to .lucee I mean strictly the new
dialect).

Lucee is a great opportunity to evolve the language by adding a new dialect
that modernizes the platform. I would vote that .lucee have no tags,
and *no *way to output anything other than json data, binary or platform
native objects (for internal cfml/lucee communication of queries, structs,
arrays, cfc, etc…). Provide a way to override the default serializing
methods (so those stuck on xml can cope) and you’ve reached the end of what
.lucee’s output should handle.

With that mindset, we as developers can use .lucee files to build API’s
that are “front-end agnostic”. Clear separation. If we need server side
templating, we can use just use cfm files (.lcml or whatever) or any other
server templating platform we choose. If we require client-side templating
we just use one of the many options out there. The problem of templating
has been solved, many times over. Let’s not reinvent the wheel just
because a NIH mantra or because we are ashamed of how cfml has been used to
create ugly code.

Also agree with you on the renaming to <lc: or whatever. The .lucee
dialect should be the bridge from cfml to modern development, not a
slightly better version of the same old cruft.On Thursday, February 12, 2015 at 2:37:51 PM UTC-8, Adam Cameron wrote:

G’day:
There’s been a lot of back-and-forth about Lucee and view template
implementations, and tags in .lucee files (or no tags in .lucee files!)
etc.

One good idea our mate Abram Adams had seems painfully obvious once it’s
pointed out…

… just use CFM files for the views.

This pretty much kills (in a good way) the conversation about which tags
to support, which tags to include, how few one should use etc.

We can all just do what we like. I’d use and , and probably
not much else. Someone else can use , , ,
whatever.

I also think this is still OK with the direction the Association seems to
want to take with distancing itself from CFML to an extent: it’s a
reasonable separation, and I think there’s still a good case to be made for
CFML’s approach for view templating. They could even go as far as losing
the “<cf” prefix and just run with “<lc:” or something, or get rid of the
prefix completely. I can’t see that being tricky for the parser to deal
with?

Good thinking Abram.

What do y’all think?

–
Adam

3

not sure why I doubled your name mate :)On Thursday, February 12, 2015 at 3:46:48 PM UTC-8, Abram Adams wrote:

+1 Adam Adam for voicing that.

(note for wording below: when I refer to Lucee, I mean the entire
platform (cfml + new dialect), when I refer to .lucee I mean strictly the
new dialect).

Lucee is a great opportunity to evolve the language by adding a new
dialect that modernizes the platform. I would vote that .lucee have
no tags, and *no *way to output anything other than json data,
binary or platform native objects (for internal cfml/lucee communication of
queries, structs, arrays, cfc, etc…). Provide a way to override the
default serializing methods (so those stuck on xml can cope) and you’ve
reached the end of what .lucee’s output should handle.

With that mindset, we as developers can use .lucee files to build API’s
that are “front-end agnostic”. Clear separation. If we need server side
templating, we can use just use cfm files (.lcml or whatever) or any other
server templating platform we choose. If we require client-side templating
we just use one of the many options out there. The problem of templating
has been solved, many times over. Let’s not reinvent the wheel just
because a NIH mantra or because we are ashamed of how cfml has been used to
create ugly code.

Also agree with you on the renaming to <lc: or whatever. The .lucee
dialect should be the bridge from cfml to modern development, not a
slightly better version of the same old cruft.

On Thursday, February 12, 2015 at 2:37:51 PM UTC-8, Adam Cameron wrote:

G’day:
There’s been a lot of back-and-forth about Lucee and view template
implementations, and tags in .lucee files (or no tags in .lucee files!)
etc.

One good idea our mate Abram Adams had seems painfully obvious once it’s
pointed out…

… just use CFM files for the views.

This pretty much kills (in a good way) the conversation about which tags
to support, which tags to include, how few one should use etc.

We can all just do what we like. I’d use and , and
probably not much else. Someone else can use , ,
, whatever.

I also think this is still OK with the direction the Association seems to
want to take with distancing itself from CFML to an extent: it’s a
reasonable separation, and I think there’s still a good case to be made for
CFML’s approach for view templating. They could even go as far as losing
the “<cf” prefix and just run with “<lc:” or something, or get rid of the
prefix completely. I can’t see that being tricky for the parser to deal
with?

Good thinking Abram.

What do y’all think?

–
Adam

4

With all due respect, I’ve recently learnt from your responses here and
from your blog post

that you are not very tolerant and sometimes insulting to others point of
view. So I think you don’t deserve any comment.

5

With all due respect, I’ve recently learnt from your responses here and
from your blog post

Adam Cameron's Dev Blog: Using small words (for the Lucee Google Group followers)

that you are not very tolerant and sometimes insulting to others point of
view. So I think you don’t deserve any comment.

It’s jolly good you took the time to point that out.On Friday, 13 February 2015 19:52:09 UTC+13, andreas rueger wrote:

–
Adam

6

Micha,

So could the prefix be made a setting? In that way, backwards compatibility
could be maintained, and folks who want to change it, whatever their
reason, could do so.> only this 3 tags are making the difference

cf

false

7

You calling me fat???On 12 February 2015 at 23:47, Abram Adams <@Abram_Adams> wrote:

not sure why I doubled your name mate :slight_smile:

On Thursday, February 12, 2015 at 3:46:48 PM UTC-8, Abram Adams wrote:

+1 Adam Adam for voicing that.

8

Instinctively like this too, but might it not be a hostage to fortune?
Few if any clashes now, but what if or found their way
into HTML6? A lot of code would break. Hence namespacing.

But agree that it would be nice not to have to type or look at colons
or %s. We’re often not the only ones working on our views. Front end
devs/designers need to understand them and the current is
very clear (and beats the competition in that regard I think).

Understand the need to get rid of <cf…>, but ? Not
sure those particular letters work well as prefixes.On 13 February 2015 at 09:53, Mark Drew <@Mark_Drew> wrote:

I am with you here dom, remove prefixes if we are doing it. There are so very FEW tags that are mixed up with html that it would all work.

9

Yes, I think you’re right. Just raising it as potential issue as we
think all this through. I’d love the simplicity of .On 13 February 2015 at 10:17, Mark Drew <@Mark_Drew> wrote:

I very much doubt you will have and in html as it is not logic based, but a structural markup

10

Am also looking forward to the day I can go from being cfsimplicity to
just simplicity. No hope of getting the domain though.

Julian
http://cfsimplicity.com/On 13 February 2015 at 10:23, Julian Halliwell <@Julian_Halliwell> wrote:

I’d love the simplicity of .

11

I very much doubt you will have and in html as it is not logic based, but a structural markup

And if HTML6 add them, lucee just has to add or a setting to default it or you just include a .htm file so it isn’t parsed by lucee… but to prepare for that if and make me type <cf a bazillion times till that happens… I have already got <cf muscle memory that I shouldn’t have

Mark Drew

develop • deploy • deliver
http://charliemikedelta.com ttp://charliemikedelta.com> On 13 Feb 2015, at 10:13, Julian Halliwell <@Julian_Halliwell> wrote:

Instinctively like this too, but might it not be a hostage to fortune?
Few if any clashes now, but what if or found their way
into HTML6? A lot of code would break. Hence namespacing.

But agree that it would be nice not to have to type or look at colons
or %s. We’re often not the only ones working on our views. Front end
devs/designers need to understand them and the current is
very clear (and beats the competition in that regard I think).

Understand the need to get rid of <cf…>, but ? Not
sure those particular letters work well as prefixes.

On 13 February 2015 at 09:53, Mark Drew <@Mark_Drew> wrote:

I am with you here dom, remove prefixes if we are doing it. There are so very FEW tags that are mixed up with html that it would all work.

–
You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAC_5Vorbi%3DjJOetvSNu5D_D%2B-4EtQyk1EU2UdoL5Zsyov2ktiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

12

Love the idea. This is one of the few strength we have, a lot of experience
with 2 languages in one - tags and script. And the alternative templating
syntax I have seen so far, was at least not better than CFML/HTML.Am Donnerstag, 12. Februar 2015 23:37:51 UTC+1 schrieb Adam Cameron:

G’day:
There’s been a lot of back-and-forth about Lucee and view template
implementations, and tags in .lucee files (or no tags in .lucee files!)
etc.

One good idea our mate Abram Adams had seems painfully obvious once it’s
pointed out…

… just use CFM files for the views.

This pretty much kills (in a good way) the conversation about which tags
to support, which tags to include, how few one should use etc.

We can all just do what we like. I’d use and , and probably
not much else. Someone else can use , , ,
whatever.

I also think this is still OK with the direction the Association seems to
want to take with distancing itself from CFML to an extent: it’s a
reasonable separation, and I think there’s still a good case to be made for
CFML’s approach for view templating. They could even go as far as losing
the “<cf” prefix and just run with “<lc:” or something, or get rid of the
prefix completely. I can’t see that being tricky for the parser to deal
with?

Good thinking Abram.

What do y’all think?

–
Adam