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:
