Lucee v. CFML

[ADK]

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...

[Sean Corfield]

On Feb 21, 2015, at 11:40 AM, ADK <and...@leftbower.com> wrote:
> 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)

[Michael Offner]

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

Am Samstag, 21. Februar 2015 schrieb ADK :

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 ...

 

--
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.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/cb60f626-ec00-4ef9-8efe-65f363e09ce6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christopher Dawes]

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

If only google groups had features... #dreaming

[Christopher Dawes]

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

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

[Mark Drew]

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. 

[Igal @ Lucee.org]

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

--

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.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/67ea2d12-56a5-4ecf-8679-493eff0f4ff4%40googlegroups.com.

[Mark Drew]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/54EB666F.5070003%40lucee.org.