+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
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:
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!)
One good idea our mate Abram Adams had seems painfully obvious once it’s
… 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 , , ,
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
Good thinking Abram.
What do y’all think?