Lucee v. CFML

I mentioned this on another thread, but would it be a good idea to have
separate groups for discussions on Lucee’s CFML engine and Lucee’s proposed
“new” language/syntax/whatever it may be?

I for one get confused on many posts when people are making suggestions for
something new/different whether they are referring to current CFML
implementations and/or the new .lucee script?

I also would be interested in some clarification on what the new .lucee
language is envisioned to be? Is the idea for it to be something completely
new from the ground up? Is it supposed to be Lucee CFML with all of the
cruft, backwards compat baggage, etc. stripped out? I guess I am asking
what the starting point or baseline is? If new concepts are incorporated
into .lucee is the plan to also make them available to the CFML compat
extension (where it makes sense)? Will the CFML extension continue to try
to mimic new advances made by ACF or will anything new just be adopted into
.lucee syntax (assuming it’s deemed appropriate)?

I understand that it’s still just an idea floated by Micha, but curious to
hear from him and others involved in this to know some more specifics about
direction.

I’m thrilled with with what I think is happening here, just not sure if
what I think is the new path is what Micha thinks it is, is what other
posters think it is, etc. Sorry for the rambling…

I mentioned this on another thread, but would it be a good idea to have separate groups for discussions on Lucee’s CFML engine and Lucee’s proposed “new” language/syntax/whatever it may be?

I think this is an excellent suggestion!

I think that if Lucee really is to attract non-CFML developers into the pool, it’s going to need a community space that doesn’t talk about CFML — and therefore it needs a separate community space for all those CFML developers who want to run their “legacy” code on Lucee. As someone with 90kloc CFML in production, I’d certainly like two groups since I will want to be able to post CFML-related questions without polluting the “shiny new Lucee community” that will (hopefully) be full of non-CFML developers.

I for one get confused on many posts when people are making suggestions for something new/different whether they are referring to current CFML implementations and/or the new .lucee script?

Based on several threads here, you aren’t the only one so far, and you won’t be the only one in the future unless this is addressed. And whilst I think this is an important division to make, it’s also going to be a controversial one — I expect some people will feel this is “yet another step” toward making CFML seem a “second class citizen” in the Lucee world (and, in some ways, it would be — since the whole point of distancing Lucee from CFML is to make Lucee more attractive to non-CFML developers, who will generally be put off by seeing discussion of CFML). That latter point means the Lucee-only group would almost certainly need to be moderated to keep CFML discussions out of it - in order to avoid the “stigma”.

Given the discussions in this group so far - it’s clearly going to have to be the “Lucee CFML” group (unless a lot of threads and/or posts are deleted from the archive!). I don’t know whether a mailing list can be renamed? (to lucee-cfml for example)

I also would be interested in some clarification on what the new .lucee language is envisioned to be? Is the idea for it to be something completely new from the ground up? Is it supposed to be Lucee CFML with all of the cruft, backwards compat baggage, etc. stripped out?

Based on the discussions here, I’d say it’s the latter: an evolution of CFML… perhaps “CFML: The Good Parts”. Right now tho’, it is just that: “discussions”. There have been no specifics about direction. I wouldn’t even say the Lucee developers themselves have a consensus on what Lucee should be right now (Igal? Micha? Denny? Anyone?).

My personal sense is that many people believe a good starting point would be:

  • One file extension (maybe .lucee)
  • Script-only components
  • Tag-only view templates (removing the ‘cf’ prefix)

In addition:

  • Possibly add a “tag island” syntax to Lucee script so XML or HTML fragments can easily be generated in components
  • Almost certainly restrict the number of tags available in view templates to avoid runaway logic in views
  • Remove some of the weird cruft from both script and tags to streamline / modernize the language

Some of that has seemed more controversial, some less controversial.

I would expect the sweet spot to be that well-structured CFML code - which in my opinion is tag-based views with very little logic and script-based components - should be relatively easy to migrate to the new Lucee language. I think “most” CFML does not fall into that category tho’, so the commitment to continue to support .cfm/.cfc files is going to be important for most CFML developers (potentially via a CFML extension that would be supported by the Lucee Association and readily available, if not by the core engine itself).

If new concepts are incorporated into .lucee is the plan to also make them available to the CFML compat extension (where it makes sense)?

Good question. My vote would be “no” unless doing so was trivial for the Lucee team and created no future maintenance overhead (I expect Lucee to evolve in an incompatible way to CFML so that it doesn’t have to deal with the baggage of backward compatibility).

Will the CFML extension continue to try to mimic new advances made by ACF or will anything new just be adopted into .lucee syntax (assuming it’s deemed appropriate)?

Good question. I haven’t seen any advances made by ACF lately tho’. I’ve seen Adobe copy stuff from Railo and deliberately implement it in an incompatible way (their horrendous tags-as-script approach in ACF11, for example). I’ve seen Adobe add really, really dumb stuff that satisfies the PHB checklists (cfclient, cfsocial, etc). That stuff should not be in CFML in the first place, in any flavor.

I’m thrilled with with what I think is happening here, just not sure if what I think is the new path is what Micha thinks it is, is what other posters think it is, etc. Sorry for the rambling…

You’re in the same boat as most of us. The only thing Micha’s really been clear on is that this is all just discussion at the moment — nothing is set in stone.

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 21, 2015, at 11:40 AM, ADK <@ADK> wrote:

it’s called a forum right… haha.

If only google groups had features… #dreaming

We discussed this topic with our members in details and we will come with
an official roadmap for this in the near future, but we agreed that this
approach is in general the best future for lucee.

We have taken the concerns from the community about this very serious. We
working also on our website to improve our promotion for CFML in general,
to embrace more existing CFML developers.
So the biggest problem is to find the right message to embrace everybody…

CFML is for sure the best language in his field (at least for me) and this
new extension is only a way to make this clear to everybody, so it is not
about doing a new language it is only about loosing weight on the existing
one (more or less)
Please see my answers between the lines for details

Micha

I mentioned this on another thread, but would it be a good idea to have
separate groups for discussions on Lucee’s CFML engine and Lucee’s proposed
“new” language/syntax/whatever it may be?

ATM most users using lucee because they use CFML before (Railo,acf …). I
think that is a good approach worth to think about in the future, but I
think atm it is to early.

I for one get confused on many posts when people are making suggestions
for something new/different whether they are referring to current CFML
implementations and/or the new .lucee script?

Yeah, also here we have to find the right way, so that not every second
thread end with, “see the other group…”

I also would be interested in some clarification on what the new .lucee
language is envisioned to be? Is the idea for it to be something completely
new from the ground up?

No

Is it supposed to be Lucee CFML with all of the cruft, backwards compat
baggage, etc. stripped out?

Yes, we are speaking about a new dialect on top of the engine.

I guess I am asking what the starting point or baseline is? If new
concepts are incorporated into .lucee is the plan to also make them
available to the CFML compat extension (where it makes sense)?

New features are made in the engine of course, so the lucee and cfml
dialect will be on top of that and profit from it, only if we decide that
something makes no sense in on or the other dialect, we will disable it.
But atm I’m only can think about features missing in the new dialect, not
in the old one. Cfml for example had a function named lsDateFormat and
dateFormat, the new extension will only have one of them …

Will the CFML extension continue to try to mimic new advances made by ACF
or will anything new just be adopted into .lucee syntax (assuming it’s
deemed appropriate)?

This new extension will not change our handling of this in the future for
the cfml dialect. Like the working names of the latest acf releases are
showing, they only added some dazzling features, that maybe look good for
people in charge, but are bullshit from a technical standpoint (cfclient).
In my opion that is maybe good for s quick sell, but not on a long
run. With lucee 5 we are moving a lot of the core functionality to
extensions, so if we ever will to a cfclient tag for example, it will for
sure only be a extension because a feature like this should not be in the
core, so for new acf functionality the question will be, “do we add it to
the core or not”, the dialect itself will not be a big question, but to be
honest I don’t expect a lot coming from acf in the future …

I understand that it’s still just an idea floated by Micha, but curious to
hear from him and others involved in this to know some more specifics about
direction.

We will publish a roadmap for this in the near future.
The current idea is to add a experimental implementation to Lucee 5 that is
disabled by default, so we have a base to discuss about. Technically this
is not a big deal, we only have to add a switch that works different for
settings you can already switch off/on today.
Most of the things we discussed so far are only setting on top of the
engine …

I’m thrilled with with what I think is happening here, just not sure if
what I think is the new path is what Micha thinks it is, is what other
posters think it is, etc. Sorry for the rambling…

Go on…, we had big concerns loosing the name “Railo” but in the end it
turned out to be a good thing, at least in my opion. This also have giving
us a chance to start over and make things right and learn from the past. I
see this extension as part of this approach … What not mean we leave
someone behind …Am Samstag, 21. Februar 2015 schrieb ADK :


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/cb60f626-ec00-4ef9-8efe-65f363e09ce6%40googlegroups.com
https://groups.google.com/d/msgid/lucee/cb60f626-ec00-4ef9-8efe-65f363e09ce6%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

https://support.google.com/groups/answer/2645570?hl=en

Guess the admins could create categories for this Google Group…
#easysolutionOn Monday, 23 February 2015 02:49:25 UTC+11, Christopher Dawes wrote:

it’s called a forum right… haha.

If only google groups had features… #dreaming

I don’t think so. I managed to add some tags to the web interface (as a manager) so that we can now tag posts and have some pre-suggested ones.

Mark Drew

develop • deploy • deliver
http://charliemikedelta.com ttp://charliemikedelta.com> On 23 Feb 2015, at 17:42, Igal @ Lucee.org <@Igal> wrote:

+1 for tags. but how do you tag a message from an email client? is that possible?

On 2/23/2015 8:53 AM, Mark Drew wrote:

It looks like the better way to go with this would be to create tags. Categories (at this point) would seem too structured and annoying if you had to drill down into each category all the time.

On Sunday, February 22, 2015 at 4:13:14 PM UTC, Christopher Dawes wrote:
https://support.google.com/groups/answer/2645570?hl=en https://support.google.com/groups/answer/2645570?hl=en

Guess the admins could create categories for this Google Group… #easysolution

On Monday, 23 February 2015 02:49:25 UTC+11, Christopher Dawes wrote:
it’s called a forum right… haha.

If only google groups had features… #dreaming

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/67ea2d12-56a5-4ecf-8679-493eff0f4ff4%40googlegroups.com https://groups.google.com/d/msgid/lucee/67ea2d12-56a5-4ecf-8679-493eff0f4ff4%40googlegroups.com?utm_medium=email&utm_source=footer.
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/54EB666F.5070003%40lucee.org https://groups.google.com/d/msgid/lucee/54EB666F.5070003%40lucee.org?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

It looks like the better way to go with this would be to create tags.
Categories (at this point) would seem too structured and annoying if you
had to drill down into each category all the time.On Sunday, February 22, 2015 at 4:13:14 PM UTC, Christopher Dawes wrote:

https://support.google.com/groups/answer/2645570?hl=en

Guess the admins could create categories for this Google Group…
#easysolution

On Monday, 23 February 2015 02:49:25 UTC+11, Christopher Dawes wrote:

it’s called a forum right… haha.

If only google groups had features… #dreaming

+1 for tags. but how do you tag a message from an email client? is
that possible?On 2/23/2015 8:53 AM, Mark Drew wrote:

It looks like the better way to go with this would be to create tags.
Categories (at this point) would seem too structured and annoying if
you had to drill down into each category all the time.

On Sunday, February 22, 2015 at 4:13:14 PM UTC, Christopher Dawes wrote:

https://support.google.com/groups/answer/2645570?hl=en
<https://support.google.com/groups/answer/2645570?hl=en>

Guess the admins could create categories for this Google Group...
#easysolution

On Monday, 23 February 2015 02:49:25 UTC+11, Christopher Dawes wrote:

    it's called a forum right... haha.

    If only google groups had features... #dreaming


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/67ea2d12-56a5-4ecf-8679-493eff0f4ff4%40googlegroups.com
https://groups.google.com/d/msgid/lucee/67ea2d12-56a5-4ecf-8679-493eff0f4ff4%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.