Alternative templating schemes

In another thread (An Outsider’s Perspective) there has been a bunch of talk of changes to Lucee to make it seem less like CFML and appeal to the “wider audience”.

One thing I’d like to see is we allow the view files to use Handlebars syntax in view files as an alternative to #variableName#, cfloop, cfoutput, etc. You’d no longer need cfoutput since {{variableName}} would automatically be translated.

It also removes a visual link to the CFML past. Obviously we’d need to keep the current parser in place or we’d break every CFML app people tried to bring to Lucee. I have no idea how difficult this would be for the parser to support but I personally like the idea of having a very similar paradigm to the JS that we all are increasingly writing.

Food for thought (hopefully).

Dan

Yup. good idea.

Having moved off CFML for views (we’re using Twig
http://twig.sensiolabs.org/doc/templates.html now), I actually find CFML
tags a bit clunky to look at; with their endless repetition of CF-this and
CF-that, and general verbosity.

Also - as you say - if they’re moving away from being identified with CFML,
the “<cf” has to go.

I’d recommend picking the most popular templating system and using a
flavour of that instead.

Nice one, Dan.–
Adam

On 6 February 2015 at 13:04, Dan Skaggs <@Dan_Skaggs> wrote:

In another thread (An Outsider’s Perspective) there has been a bunch of
talk of changes to Lucee to make it seem less like CFML and appeal to the
“wider audience”.

One thing I’d like to see is we allow the view files to use Handlebars
syntax in view files as an alternative to #variableName#, cfloop, cfoutput,
etc. You’d no longer need cfoutput since {{variableName}} would
automatically be translated.

It also removes a visual link to the CFML past. Obviously we’d need to
keep the current parser in place or we’d break every CFML app people tried
to bring to Lucee. I have no idea how difficult this would be for the
parser to support but I personally like the idea of having a very similar
paradigm to the JS that we all are increasingly writing.

Food for thought (hopefully).

Dan


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/99798043-B60D-4DF7-A327-94F64A9598A3%40web-meister.com
.
For more options, visit https://groups.google.com/d/optout.

How about Mustache.js in Lucee?
Simple syntax and very easy to use!

If we are going this route I would prefer the ability to choose a rendering
engine, but would rather not have to specify which one to use at an
application level - I can imagine scenarios where one might want to mix and
match.On Friday, February 6, 2015 at 12:37:47 PM UTC-6, Mark Drew wrote:

Or do as express.js does and leave the rendering engine up to you. So add
an extension for moustache or handlebars and just do

This.renderer=“moustache”;

Mark Drew

On 6 Feb 2015, at 18:30, Dan Skaggs <da...@web-meister.com <javascript:>> wrote:

Yeah that’s kinda what I had in mind but I mentioned Handlebars as my
example because that’s the one I’m familiar with. From what I understand
Mustache and Handlebars are very similar.

On Feb 6, 2015, at 1:28 PM, Jonas Hauß <hauss...@gmail.com <javascript:>> wrote:

How about Mustache.js in Lucee?
Simple syntax and very easy to use!


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+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/3906b56f-bf31-4e1b-91f8-19e219a870c3%40googlegroups.com
https://groups.google.com/d/msgid/lucee/3906b56f-bf31-4e1b-91f8-19e219a870c3%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


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+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CC2A1C6D-6C64-439D-B8B1-24D88CC44A73%40web-meister.com
https://groups.google.com/d/msgid/lucee/CC2A1C6D-6C64-439D-B8B1-24D88CC44A73%40web-meister.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

Just a suggestion, whatever templating language is chosen for Lucee files, can we use a character that is obvious on both Mac and PC keyboards?

(No Mac vs PC war here pls) On Mac, the # is Alt+3 which is annoying for newbies (I have muscle memory now) so { or [[ or whatever is cool

But not keys like ¡ € # ¢ ∞ § ¶ • ª or º ok?

Regards

Mark Drew> On 6 Feb 2015, at 13:42, Adam Cameron <@Adam_Cameron1> wrote:

Yup. good idea.

Having moved off CFML for views (we’re using Twig http://twig.sensiolabs.org/doc/templates.html now), I actually find CFML tags a bit clunky to look at; with their endless repetition of CF-this and CF-that, and general verbosity.

Also - as you say - if they’re moving away from being identified with CFML, the “<cf” has to go.

I’d recommend picking the most popular templating system and using a flavour of that instead.

Nice one, Dan.


Adam

On 6 February 2015 at 13:04, Dan Skaggs <@Dan_Skaggs mailto:Dan_Skaggs> wrote:
In another thread (An Outsider’s Perspective) there has been a bunch of talk of changes to Lucee to make it seem less like CFML and appeal to the “wider audience”.

One thing I’d like to see is we allow the view files to use Handlebars syntax in view files as an alternative to #variableName#, cfloop, cfoutput, etc. You’d no longer need cfoutput since {{variableName}} would automatically be translated.

It also removes a visual link to the CFML past. Obviously we’d need to keep the current parser in place or we’d break every CFML app people tried to bring to Lucee. I have no idea how difficult this would be for the parser to support but I personally like the idea of having a very similar paradigm to the JS that we all are increasingly writing.

Food for thought (hopefully).

Dan


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 mailto:lucee%2Bunsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/99798043-B60D-4DF7-A327-94F64A9598A3%40web-meister.com https://groups.google.com/d/msgid/lucee/99798043-B60D-4DF7-A327-94F64A9598A3%40web-meister.com.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.


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 mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKfy9p%3DKz8g1Fed0fvyqVLLiDBRZ7aPcB52zZ1BttEn_qg%40mail.gmail.com https://groups.google.com/d/msgid/lucee/CAFwR%2BKfy9p%3DKz8g1Fed0fvyqVLLiDBRZ7aPcB52zZ1BttEn_qg%40mail.gmail.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

I agree on the moving from CF stigmas, but I think we should be careful on
what we throw out with the dishwater.

+1!

For instance, if we make the templating syntax the same as handlebars or
mustache or all the other double-curly template engines, it further blurs
the line between what is server side and what is client side and could
easily cause collisions. Many times I want to serve a fully server-side
rendered page that has client-side templating embedded in the html so that
it can dynamically re-render when state changes client-side. If Lucee
automatically parsed the double curlies it could bring unexpected results
like throwing server side errors.

Indubitably! I like the idea of using extensions (cfmustache,
cfhandlebars, etc.) vs. changing the standard.

I personally think the templating syntax for cfml is actually really good
if used responsibly. Using tags to control basic logic and #'s to evaluate
code is a very natural fit inside html.

Couldn’t agree more! I was a little bummed to see so much angst about tags
in general. They are just a way of giving context, and separating stuff,
and you have to do that regardless of what you use. JSON really needs
schemas, for instance, but only the “big players” have realized that so
far.

-DenOn Sat, Feb 7, 2015 at 11:35 AM, Abram Adams wrote:

2 things are very important for me:

  1. it should be about loosing weight not get a other person, we should keep
    what makes cf unique and good, only ditch the bullshit.

  2. The application.cfc is like a mini framework and I was asking myself a
    lot in the past, should we go further with that concept. But I don’t think
    so today, we have great framworks like fw/1 and coldbox that do a great job
    in that sector, so add any further framework logic to the language only
    limits the possibilities.

MichaAm Samstag, 7. Februar 2015 schrieb Adam Cameron :

On Sat, Feb 7, 2015 at 8:53 PM, Sean Corfield <@Sean_Corfield <javascript:_e(%7B%7D,‘cvml’,’@Sean_Corfield’);>> wrote:

I also agree but I would like to see the amount of logic restricted in
view templates so perhaps a <lc:tagname …> … </lc:tagname> syntax but with
only a small subset of tags actually available? Maybe just:

Yup.

  • lc:script - if you really must embed logic, at least make it script!

I’d say custom tag for that. Or just not allow it, because if you needed
it, you’re doing it wrong. Don’t do it wrong.

On 7 February 2015 at 20:17, Jean Moniatte <@Jean_Moniatte <javascript:_e(%7B%7D,‘cvml’,’@Jean_Moniatte’);>> wrote:

And the ability to call built-in and user defined functions as well ?

Formatting-for-output functions, yes.

And methods on objects. Ones that return something to be iterated over, or
strings to be output.

But the bulk of CFML’s functionality simply does not belong in views.


Adam


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
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAFwR%2BKeWA-4D0STM1-W3GURNj4%2Bm8FUv5HcJ8-n%2BW3pSreV5%3DA%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAFwR%2BKeWA-4D0STM1-W3GURNj4%2Bm8FUv5HcJ8-n%2BW3pSreV5%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

I also agree but I would like to see the amount of logic restricted in
view templates so perhaps a <lc:tagname …> … </lc:tagname> syntax but with
only a small subset of tags actually available? Maybe just:

Yup.

  • lc:script - if you really must embed logic, at least make it script!

I’d say custom tag for that. Or just not allow it, because if you needed
it, you’re doing it wrong. Don’t do it wrong.> On Sat, Feb 7, 2015 at 8:53 PM, Sean Corfield <@Sean_Corfield> wrote:

On 7 February 2015 at 20:17, Jean Moniatte <@Jean_Moniatte> wrote:

And the ability to call built-in and user defined functions as well ?

Formatting-for-output functions, yes.

And methods on objects. Ones that return something to be iterated over, or
strings to be output.

But the bulk of CFML’s functionality simply does not belong in views.


Adam

I like this list as well, with lc:if being crucial. One of the biggest
issues I have with Handlebars, and I love Handlebars, is that there is
zero logic allowed, which is good in theory, but in practice, can be a
pain the in the rear. Handlesbars has an IF, but only for one value, you
can’t do something like, if X=Y.

When migrating a CF site to Node recently and using Handlebars, I had to
write a custom function just to support this in CFML:

<option value="something" selected>SomethingOn Saturday, February 7, 2015 at 1:53:09 PM UTC-6, Sean Corfield wrote: > > On Feb 7, 2015, at 11:37 AM, Jean Moniatte <je...@ugal.com > wrote: > > On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <cfxc...@gmail.com > wrote: > >> I personally think the templating syntax for cfml is actually really good >> if used responsibly. Using tags to control basic logic and #'s to evaluate >> code is a very natural fit inside html. > > I agree, I do not see a need for change here. CFML is really good for view > templates. > > > I also agree but I would like to see the _amount_ of logic restricted in > view templates so perhaps a … syntax but with > only a small subset of tags actually available? Maybe just: > > * > * > * > * - if you really must embed logic, at least make it script! > >

For instance, if we make the templating syntax the same as handlebars or
mustache or all the other double-curly template engines, it further blurs
the line between what is server side and what is client side and could
easily cause collisions. Many times I want to serve a fully server-side
rendered page that has client-side templating embedded in the html so that
it can dynamically re-render when state changes client-side. If Lucee
automatically parsed the double curlies it could bring unexpected results
like throwing server side errors.

I see it like client-side JS vs server-side JS. People seem to cope with
that OK.

I reckon using the “best” or most-popular (according to today’s zeitgeist)
client-side view-template engine for doing the server-side templating as a
reduction in barrier-to-entry.

my $0.02

Your opinion is worth more than that, mate. Don’t sell yourself short.

My 500 quid.On 7 February 2015 at 18:35, Abram Adams <@Abram_Adams> wrote:


Adam

Views are one of the areas where I feel I can still hold my head high
as a CFML developer. I worked with a front-end designer recently and
after the usual raised eyebrow on learning the back-end was CF, he was
actually surprised at how easy my views were to deal with compared
with the Ruby he normally had to wrangle. The #s did trip him up a bit
given that they have meaning in HTML as anchors/ids and need escaping,
but the tag/attribute combination is very familiar (which was as the
Allaire bros intended it).On 7 February 2015 at 18:47, Abram Adams <@Abram_Adams> wrote:

I personally think the templating syntax for cfml is actually really good if used responsibly. Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.

I personally think the templating syntax for cfml is actually really good if used responsibly. Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.

I agree, I do not see a need for change here. CFML is really good for view templates.

+1, CFML is absolutely fine for view templates. There’s no need to jump on another syntax bandwagon for the templating purpose just because some currently hip JS frameworks do certain things.

Cheers
Kai> On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <@Abram_Adams> wrote:

I also agree but I would like to see the amount of logic restricted in view templates so perhaps a <lc:tagname …> … </lc:tagname> syntax but with only a small subset of tags actually available? Maybe just:

Sean Corfield – (904) 302-SEAN
An Architect’s View – http://corfield.org/

“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)On Feb 7, 2015, at 11:37 AM, Jean Moniatte <@Jean_Moniatte> wrote:

On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <@Abram_Adams mailto:Abram_Adams> wrote:
I personally think the templating syntax for cfml is actually really good if used responsibly. Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.
I agree, I do not see a need for change here. CFML is really good for view templates.

so given the following pseudo code (assuming js templating is wired up):

someVar = "def";
{{someVar}} {{someVar}}

What would the the output be?On Saturday, February 7, 2015 at 10:58:36 AM UTC-8, Adam Cameron wrote:

On 7 February 2015 at 18:35, Abram Adams <cfxc...@gmail.com <javascript:>> wrote:

For instance, if we make the templating syntax the same as handlebars or
mustache or all the other double-curly template engines, it further blurs
the line between what is server side and what is client side and could
easily cause collisions. Many times I want to serve a fully server-side
rendered page that has client-side templating embedded in the html so that
it can dynamically re-render when state changes client-side. If Lucee
automatically parsed the double curlies it could bring unexpected results
like throwing server side errors.

I see it like client-side JS vs server-side JS. People seem to cope with
that OK.

I reckon using the “best” or most-popular (according to today’s zeitgeist)
client-side view-template engine for doing the server-side templating as a
reduction in barrier-to-entry.

my $0.02

Your opinion is worth more than that, mate. Don’t sell yourself short.

My 500 quid.


Adam

And the ability to call built-in and user defined functions as well ?On Sat, Feb 7, 2015 at 8:53 PM, Sean Corfield <@Sean_Corfield> wrote:

On Feb 7, 2015, at 11:37 AM, Jean Moniatte <@Jean_Moniatte> wrote:

On Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <@Abram_Adams> wrote:

I personally think the templating syntax for cfml is actually really good
if used responsibly. Using tags to control basic logic and #'s to evaluate
code is a very natural fit inside html.

I agree, I do not see a need for change here. CFML is really good for view
templates.

I also agree but I would like to see the amount of logic restricted in
view templates so perhaps a <lc:tagname …> … </lc:tagname> syntax but with
only a small subset of tags actually available? Maybe just:

Sean Corfield – (904) 302-SEAN
An Architect’s View – http://corfield.org/

“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)


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/DD6264EC-BAD7-4032-ADEA-DDBCBA1FF470%40corfield.org
https://groups.google.com/d/msgid/lucee/DD6264EC-BAD7-4032-ADEA-DDBCBA1FF470%40corfield.org?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

I’d say custom tag for that. Or just not allow it, because if you needed
it, you’re doing it wrong. Don’t do it wrong.

thats just like, your opinion man. And I think its important to point this
out because there are some people who take what you say as having weight
and authority here. Sure, there are lots of reason for good separation of
concerns in application development, even reasons to encourage that from a
language standpoint. But there are other people who will disagree for good
reason. Take a look at react for an example of mixing logic and
view. Please remember that there are people who need to write simple
scripts, not applications - and that may mean a one page chunk of logic and
view. Please, in general, remember that there are people who have needs and
tastes that don’t match your own.

I’m not against supporting other template engines, especially if it makes
someone coming from other languages more comfortable, but I don’t see any
point in getting rid of pound signs and cfml just because you think its old
and crufty. Give people options, don’t restrict based on some high-horse
idea of right and wrong. Lets extend the language, give new options. Make
the case why the new way is the best way and let developers convert as they
are convinced, not take away their toys and tell them they’re playing with
them wrong.

I would still argue that lucee’s long term success comes from converting
devs from ACF (including those who you think killed CFML because they had
the audacity to use features they were given). Maybe lucee 5 will prove me
wrong, but I just don’t see lucee appealing to people outside of the
existing CFML community, no matter how much you try to distance yourself
from its CFML past. Perhaps we can broaden appeal with new .lucee files
that have modern, “strict mode” features, but if you eschew the CFML that
brought you, who is lucee going to appeal to? Why should I pick lucee over
even any of the other JVM languages that set out with clear goals and
modern features from the outset? I’m here because of two reasons - my
employer(s) and I have a large amount of existing code we would like to
continue to support; and I have 15+ years of experience writing CFML. I
can completely understand the desire to move in a new direction and get rid
of the past, but I would have literally no reason to stick around. Perhaps
i’m the only one like this, I suspect i’m not.

I’d like to also propose that for large feature proposals like this that we
take a page from JS, Python, Java and other languages and actually put
forward actual formal proposals. Here is an example from
python: https://www.python.org/dev/peps/pep-0255/, or another from
JS: https://github.com/tc39/Array.prototype.includes/ This would allow us
to discuss and refine ideas, allow the lucee team to accept proposals but
say that certain parts need tweeks or more thought. It would also make it
clear to outsiders exactly what status a given proposal is in, and if it
has the approval of the team or not. I would argue both the google group
and the bitbucket issues are not ideal places for conversations like these,
unless it is a simple new function or tweak. I don’t know all the answers
on how to do it, but want to throw it out there for considerations.

My 2 cents.On Saturday, February 7, 2015 at 2:24:12 PM UTC-6, Adam Cameron wrote:

On Sat, Feb 7, 2015 at 8:53 PM, Sean Corfield <se...@corfield.org <javascript:>> wrote:

I also agree but I would like to see the amount of logic restricted in
view templates so perhaps a <lc:tagname …> … </lc:tagname> syntax but with
only a small subset of tags actually available? Maybe just:

Yup.

  • lc:script - if you really must embed logic, at least make it script!

I’d say custom tag for that. Or just not allow it, because if you needed
it, you’re doing it wrong. Don’t do it wrong.

On 7 February 2015 at 20:17, Jean Moniatte <je...@ugal.com <javascript:>> wrote:

And the ability to call built-in and user defined functions as well ?

Formatting-for-output functions, yes.

And methods on objects. Ones that return something to be iterated over, or
strings to be output.

But the bulk of CFML’s functionality simply does not belong in views.


Adam

I agree on the moving from CF stigmas, but I think we should be careful on what we throw out with the bathwater.

For instance, if we make the templating syntax the same as handlebars or mustache or all the other double-curly template engines, it further blurs the line between what is server side and what is client side and could easily cause collisions. Many times I want to serve a fully server-side rendered page that has client-side templating embedded in the html so that it can dynamically re-render when state changes client-side. If Lucee automatically parsed the double curlies it could bring unexpected results like throwing server side errors.

I personally think the templating syntax for cfml is actually really good if used responsibly. Using tags to control basic logic and #'s to evaluate code is a very natural fit inside html.

my $0.02

Don’t get me wrong, I am not suggesting that Lucee should be generating
anything that runs on the client, I just mean using the same syntax.

So instead of having something like:

  • #name#

one would have:

    {% for user in users %}
  • {{ user.name }}
  • {% endfor %}

(that’s using Twig syntax, purely because it’s what I use @ work in PHP,
and it was the easiest to knock together)

I’m not advocating using Twig for server-side templating, I’m advocating
using the same dialect of [whatever’s most popular at the moment]. But
still on the server.

The benefit being that ppl how are used to doing it clientside will be au
fait with it server side too. And, indeed, in mixed-responsibility
environments (client- & server-side templating both), the files can be
reused.

The main point is that there are a number of fairly similar templating
systems out there which ppl are familiar with. And then there’s CFML code.
Which most people are not familiar with. There’s no need to persist with
the CFML style of doing views if we’re not hanging on to CFML.–
Adam

On 7 February 2015 at 19:52, Abram Adams <@Abram_Adams> wrote:

so given the following pseudo code (assuming js templating is wired up):

someVar = "def";
{{someVar}} {{someVar}}

What would the the output be?

On Saturday, February 7, 2015 at 10:58:36 AM UTC-8, Adam Cameron wrote:

On 7 February 2015 at 18:35, Abram Adams cfxc...@gmail.com wrote:

For instance, if we make the templating syntax the same as handlebars or
mustache or all the other double-curly template engines, it further blurs
the line between what is server side and what is client side and could
easily cause collisions. Many times I want to serve a fully server-side
rendered page that has client-side templating embedded in the html so that
it can dynamically re-render when state changes client-side. If Lucee
automatically parsed the double curlies it could bring unexpected results
like throwing server side errors.

I see it like client-side JS vs server-side JS. People seem to cope with
that OK.

I reckon using the “best” or most-popular (according to today’s
zeitgeist) client-side view-template engine for doing the server-side
templating as a reduction in barrier-to-entry.

my $0.02

Your opinion is worth more than that, mate. Don’t sell yourself short.

My 500 quid.


Adam


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/81cfeb20-523d-48cc-bab4-8c3be123cd00%40googlegroups.com
https://groups.google.com/d/msgid/lucee/81cfeb20-523d-48cc-bab4-8c3be123cd00%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

I personally think the templating syntax for cfml is actually really good
if used responsibly. Using tags to control basic logic and #'s to evaluate
code is a very natural fit inside html.

I agree, I do not see a need for change here. CFML is really good for view
templates.

Thanks,
JeanOn Sat, Feb 7, 2015 at 7:47 PM, Abram Adams <@Abram_Adams> wrote:

Jean Moniatte
UGAL
@Jean_Moniatte
http://www.ugal.com

Plus a bunch for this Ryan.

I’ll get back to Ryan separately. :expressionless:

I don’t mean to be overly dramatic, but is it really our intent to do away
with open source CFML? To improve on every existing language, more or less
from scratch?

Did you miss the entire part of the conversation that any of this .lucee
stuff is in addition to the existing and continued CFML support?

If your concern is the continuation of CFML support… a) there is no
concern; b) I don’t think this is the right thread to be voicing your
(unwarranted) concerns.On 8 February 2015 at 12:05, Dave Merrill <@Dave_Merrill> wrote:


Adam