Lucee and the future

dev google-group-archive
1

there is a lot of discussions going, on about a possible support for
an additional dialects for Lucee that is controlled with help of a file
extensions.

First of all, atm this are just discussions nothing more!
It is great to talk about everything, there should be nothing we do not
question! but again that does not mean it will happen!

We talk here only about a dialect of the language, that mostly already can
be done with the settings in the administrator. The cf prefix for example
is changed in seconds.
So not a fork with an other direction, only a dialect on top of the engine.

What I can say for sure, Lucee is the best CFML engine out there and we
have no plans to change that. the only purpose of the Lucee Association
Switzerland is to maintain and extend the language and to spread the word
about it (like defined in the articles).
The only question is, how we can do the last thing (spread the word). In
our opinion this can best be done by not using the word “CFML” to much,
that is also the reason we do not use the word “CFML” on the homepage. This
dialect is in only a possible way to spread the word about lucee further
and not doing a new language!!!
Remember lucee (former Railo) is not only CFML, that is only the base lucee
is and was always more, but the base will remain!

Micha

2

Between the lines

Micha

Thanks Micha for the explanation. What are some of the initiatives on
things like documentation and spreading the word on Lucee?

The wiki is open to everybody, I try to force everybody to contribute
there, please do!
We are already working together with pixl8 to improve the website.
Mark drew is working on doc.lucee.org, he can for sure also need help on
this.

But our resources are limited, but we do our best.

I guess where do I sign up to help.

It’s funny I just added a text to the website for exactly this question
(not published yet)Am Dienstag, 10. Februar 2015 schrieb Andrew Penhorwood :

Andrew Penhorwood

–
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/9167f74b-f7a0-4679-94e9-662fcef235a2%40googlegroups.com
https://groups.google.com/d/msgid/lucee/9167f74b-f7a0-4679-94e9-662fcef235a2%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

3

Thanks Micha for the explanation. What are some of the initiatives on
things like documentation and spreading the word on Lucee? I guess where
do I sign up to help.

Andrew Penhorwood

4

I think the biggest misunderstanding was that people was thinking that we
will fork lucee and have 2 products in the future and that on a long run
there will be a loser and a winner and they could end up on the losing site.
That will not happen! Whatever the outcome is, we always will have only one
project!

MichaAm Dienstag, 10. Februar 2015 schrieb Sean Corfield :

On Feb 10, 2015, at 9:35 AM, Jesse Shaffer <@Jesse_Shaffer <javascript:;>> wrote:

Thank you for this - it calmed many concerns of one of my co-workers.

Well, if CFML devs weren’t such Chicken Little about this whole thing –
“OMG! CFML is Dead! You’re taking away my tags! You’re forcing me to learn
something new!” — they would have realized all along that that was EXACTLY
what was being discussed :slight_smile:

Seriously folks, the ridiculous panic and silly assumptions in these
threads lately is exactly why so many non-CFML developers think the CFML
community aren’t “real” programmers. Change is a good thing! It’s how
progress is made. Sheesh.

Languages evolve. Breaking changes get introduced in all languages over
time. In fact part of what’s held CFML back so much is Macromedia and
Adobe’s extreme commitment to not breaking any CFML code — and having to
ensure that even really bad code from a decade or so ago still runs! That’s
been one of the biggest problems for Railo — maintaining compatibility with
really stupid behavior in ColdFusion. Other languages are much more
pragmatic about that, and that’s how they’ve evolved faster than CFML and
why CFML looks old-fashioned by comparison. Because Macromedia and Adobe
never forced you to change, now you’re set in your ways and you don’t want
to change and you’re afraid of change.

So now we have the idea that today’s CFML will run “as-is” on Lucee in
.cfc and .cfm files and a new language — evolved from CFML — will run in
.lucee files. Your current CFML applications will continue to run “as-is”.
You can leverage the new, improved language if you want in .lucee files.
You can — if you wish — migrate some of your .cfc and .cfm files to .lucee
files, updating the code to match the new dialect.

This seems to be the best of both worlds: Lucee can offer a much improved
scripting language that might appeal to non-CFML devs, as well as letting
all that primordial code still run in “compatibility mode”.

Win-win!

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

“If you’re not annoying somebody, you’re not really alive.”
– Margaret Atwood

–
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:;>.
To post to this group, send email to lucee@googlegroups.com <javascript:;>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/C55556AE-33CF-47BD-9FBA-634462B054B0%40corfield.org
.
For more options, visit https://groups.google.com/d/optout.

5

First of all, let’s try to be nice, being mean never proves a point.

Dominic you should measure me not about what I’m saying, you should do it
on what I did the last 8 years with Railo. I tried hard to be as compatible
to CFML as possible, even this voices to break compatibility with acf was
always there and even it was a pain in the ass sometimes…

MichaAm Dienstag, 10. Februar 2015 schrieb Dominic Watson :

That’s pretty insulting to the folks who lead these projects…

You’ve a track record there Sean:
https://issues.jboss.org/browse/RAILO-3001

And you are also missing my point, or choosing to ignore it. When people
miss the point, or get the wrong end of the stick, they don’t need or want
to be publicly belittled. This attitude causes far more harm than people
raising their “unfounded” objections and opinions.

Having multiple dialects is a concern that needs to talked through
carefully. People want to be able to keep up with where the project is
focused. If that focused energy is on a dialect that will leave them unable
to upgrade, they will be left behind and the community will shrink further.

Whether or not that is actually what is going to happen, it certainly
feels like it might and fears are legitimate. Not stupid, silly or
ridiculous.

On 10 February 2015 at 20:13, Sean Corfield <@Sean_Corfield <javascript:_e(%7B%7D,‘cvml’,‘@Sean_Corfield’);>> wrote:

On Feb 10, 2015, at 11:59 AM, Judith Barnett <@Judith_Barnett <javascript:_e(%7B%7D,‘cvml’,‘@Judith_Barnett’);>> wrote:

When languages change with no thought for the damage to the existing
code base, it creates havoc for those of us doing the support.

“no thought”? Really, you believe language designers and projects change
language features on a whim, and apply “no thought” to their decisions?
That’s pretty insulting to the folks who lead these projects…

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
<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/E5FCC9B3-E5E9-48AE-BE66-114D3D886618%40corfield.org
.
For more options, visit https://groups.google.com/d/optout.

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
<javascript:_e(%7B%7D,‘cvml’,‘info@pixl8.co.uk’);>
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

–
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/CAEYvUxkwcPxDPCHR9oW7ANCOEo9Bd2fbtZL%2BPsRJrZaVNaibKA%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAEYvUxkwcPxDPCHR9oW7ANCOEo9Bd2fbtZL%2BPsRJrZaVNaibKA%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

6

That makes plenty of sense - and keeping in mind that I sponsored Issue 82
https://bitbucket.org/lucee/lucee/issue/82/5x-proposal-class-syntax concerning
classes, realize I am personally all for additional, new syntax.

I think the key is understanding *exactly *what you mean by this phrase:

Remember lucee (former Railo) is not only CFML, that is only the base lucee

is and was always more, but the base will remain!

I read this as the Lucee is an underlying Java framework supporting CFML’s
syntactical constructs (pages, tags, functions, components, etc), loosely
coupled with the CFML syntax itself. So if a new .lucee extension is
introduced - with its own parser - it is still utilizing this same
framework producing compatible bytecode, just getting there a different
way. Therefore, if the bytecode is compatible, then similar constructs
should be interoperable between syntaxes. For example, I would expect that
then that a CFM template could use to load a Lucee template
(even if lcml [lucee markup language] templates resemble
handlebars/mustache/whatever else is hot) - and vice versa. As for my
class syntax proposal - CFCs could then be instantiated within by a Lucee
Class, and vice versa. Perhaps it means that they can even extend each
other.

I love the extension concept. Looking around in the code, the thought
occurred to me as how nice it would be if the parser was modular, or at
least where it could support plugins, so that additional constructs could
more easily be introduced.On Tuesday, February 10, 2015 at 3:34:03 PM UTC-6, Micha wrote:

Let’s make me an example , Railo Is supporting the “scope
cascading setting” or the support of “no variables scope in cfc setting” a
long with many others since version one.
Yes this was a extra effort to implement them, but it takes no real extra
effort to maintain the engine when they are there.

We are speaking about that you can control this setting with help of a
extension.
Remember my dvd/cd example in the beginning.
Maybe we will add some features, but that will take for sure no extra
effort in maintaing the engine, I will make sure for that, believe me, then
that is the most important task. It always is whe. We add settings like
this.

Techically all this is not a big deal anyway, implementing most of the
changes we talked so far is done in a couple of days, including the list is
posted.
It not about adding this features it more about adding a template based
switch that produces no overhead.

Micha

7

Thank you for this - it calmed many concerns of one of my co-workers.

8

I love the extension concept. Looking around in the code, the thought
occurred to me as how nice it would be if the parser was modular, or at
least where it could support plugins, so that additional constructs could
more easily be introduced.

So… I didn’t finish that paragraph.

You could support modular parsing by introducing Lucee extensions (the OSGi
bundled extensions that is) which bind a file extension to its own provided
parser.

9

Thank you for that clarification Micha, very important to some of us.

I get that you’re in a bind trying to make that clear, while leaving the
ColdFusion stigma behind. It’s hard to see how that separation will be
possible at the developer level though – it doesn’t take a lot of digging
at the code or history level to discover the connection. Hopefully
developers can focus on actual capability, where there’s a really good
story to tell.On Tuesday, February 10, 2015 at 10:48:30 AM UTC-5, Micha wrote:

there is a lot of discussions going, on about a possible support for
an additional dialects for Lucee that is controlled with help of a file
extensions.

First of all, atm this are just discussions nothing more!
It is great to talk about everything, there should be nothing we do not
question! but again that does not mean it will happen!

We talk here only about a dialect of the language, that mostly already can
be done with the settings in the administrator. The cf prefix for example
is changed in seconds.
So not a fork with an other direction, only a dialect on top of the engine.

What I can say for sure, Lucee is the best CFML engine out there and we
have no plans to change that. the only purpose of the Lucee Association
Switzerland is to maintain and extend the language and to spread the word
about it (like defined in the articles).
The only question is, how we can do the last thing (spread the word). In
our opinion this can best be done by not using the word “CFML” to much,
that is also the reason we do not use the word “CFML” on the homepage. This
dialect is in only a possible way to spread the word about lucee further
and not doing a new language!!!
Remember lucee (former Railo) is not only CFML, that is only the base
lucee is and was always more, but the base will remain!

Micha

10

Well, if CFML devs weren’t such Chicken Little about this whole thing – “OMG! CFML is Dead! You’re taking away my tags! You’re forcing me to learn something new!” — they would have realized all along that that was EXACTLY what was being discussed :slight_smile:

Seriously folks, the ridiculous panic and silly assumptions in these threads lately is exactly why so many non-CFML developers think the CFML community aren’t “real” programmers. Change is a good thing! It’s how progress is made. Sheesh.

Languages evolve. Breaking changes get introduced in all languages over time. In fact part of what’s held CFML back so much is Macromedia and Adobe’s extreme commitment to not breaking any CFML code — and having to ensure that even really bad code from a decade or so ago still runs! That’s been one of the biggest problems for Railo — maintaining compatibility with really stupid behavior in ColdFusion. Other languages are much more pragmatic about that, and that’s how they’ve evolved faster than CFML and why CFML looks old-fashioned by comparison. Because Macromedia and Adobe never forced you to change, now you’re set in your ways and you don’t want to change and you’re afraid of change.

So now we have the idea that today’s CFML will run “as-is” on Lucee in .cfc and .cfm files and a new language — evolved from CFML — will run in .lucee files. Your current CFML applications will continue to run “as-is”. You can leverage the new, improved language if you want in .lucee files. You can — if you wish — migrate some of your .cfc and .cfm files to .lucee files, updating the code to match the new dialect.

This seems to be the best of both worlds: Lucee can offer a much improved scripting language that might appeal to non-CFML devs, as well as letting all that primordial code still run in “compatibility mode”.

Win-win!

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

“If you’re not annoying somebody, you’re not really alive.”
– Margaret AtwoodOn Feb 10, 2015, at 9:35 AM, Jesse Shaffer <@Jesse_Shaffer> wrote:

Thank you for this - it calmed many concerns of one of my co-workers.

11

Having multiple dialects is a concern that needs to talked through
carefully. People want to be able to keep up with where the project is
focused. If that focused energy is on a dialect that will leave them unable
to upgrade, they will be left behind and the community will shrink further.

That is exactly the concerns that were being felt over this way. How far
can a “dialect” go before it becomes a language competing with itself?

12

Not any objections. Just certain uninformed, unfounded objections. About things that aren’t even being proposed for .cfm / .cfc files. And the problem is those folks are getting in the way of discussing what .lucee could be by constantly bringing the issue back to what they want .cfm / .cfc to remain.

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 10, 2015, at 12:05 PM, Dominic Watson <@Dominic_Watson> wrote:

I’m quite sure you don’t mean it this way Sean, but your wording translates to calling anyone who raises any objections “silly” and “ridiculous”.

13

Let’s make me an example , Railo Is supporting the “scope
cascading setting” or the support of “no variables scope in cfc setting” a
long with many others since version one.
Yes this was a extra effort to implement them, but it takes no real extra
effort to maintain the engine when they are there.

We are speaking about that you can control this setting with help of a
extension.
Remember my dvd/cd example in the beginning.
Maybe we will add some features, but that will take for sure no extra
effort in maintaing the engine, I will make sure for that, believe me, then
that is the most important task. It always is whe. We add settings like
this.

Techically all this is not a big deal anyway, implementing most of the
changes we talked so far is done in a couple of days, including the list is
posted.
It not about adding this features it more about adding a template based
switch that produces no overhead.

MichaAm Dienstag, 10. Februar 2015 schrieb Jesse Shaffer :

Having multiple dialects is a concern that needs to talked through

carefully. People want to be able to keep up with where the project is
focused. If that focused energy is on a dialect that will leave them unable
to upgrade, they will be left behind and the community will shrink further.

That is exactly the concerns that were being felt over this way. How far
can a “dialect” go before it becomes a language competing with itself?

–
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/f93f00d6-182f-4680-8d2f-d2316e789795%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f93f00d6-182f-4680-8d2f-d2316e789795%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

14

Please have in mind that this is and was a open discussion and this
discussion will not end with a final product, it will lead to official
process to define this dialect and we will communicate as open as possible,
but again nothing is decided yet…

About arguments scope, that was just a example of many, I have no strong
opinion on that, I just tried to explain why I think the argument scope is
a bad thing, but of course this is just my opinion, in my code you will
find never a argumentcollection=arguments because I personally don’t like
that. So whatever a possible outcome will be there will be always something
you will not like. When you want to have black there will be someone that
prefers white.
Best example are tags, some would love to seem the gone, others hate
cfscript, black and white …
So again a pragmatic and simple solution.

MichaAm Dienstag, 10. Februar 2015 schrieb Dave Merrill :

Right, I get it, we have a lot of production code that references the
arguments scope and other quaint antiquities, and so do our customers. We’d
prefer not to rewrite it, and so would they, so we’re all Chicken Littles,
not Real Programmers™. Sheesh.

This wasn’t about assumptions, it was about a clear statement of intent,
which we now have. Win-win!

Perhaps there was one somewhere before, but since there’s no place where
such things are known to live, folks were effectively if not actually in
the dark.

Just like newcomers will be in the future until they find this thread, or
a mission statement to this effect gets published in some appropriately
obvious place. Except that there won’t be one because we don’t want to
associate Lucee with CFML in public. I’m having trouble seeing how this
whole conversation doesn’t just keep happening.

ducks

On Tuesday, February 10, 2015 at 2:24:37 PM UTC-5, Sean Corfield wrote:

On Feb 10, 2015, at 9:35 AM, Jesse Shaffer dajest...@gmail.com wrote:

Thank you for this - it calmed many concerns of one of my co-workers.

Well, if CFML devs weren’t such Chicken Little about this whole thing –
“OMG! CFML is Dead! You’re taking away my tags! You’re forcing me to learn
something new!” — they would have realized all along that that was EXACTLY
what was being discussed :slight_smile:

Seriously folks, the ridiculous panic and silly assumptions in these
threads lately is exactly why so many non-CFML developers think the CFML
community aren’t “real” programmers. Change is a good thing! It’s how
progress is made. Sheesh.

Languages evolve. Breaking changes get introduced in all languages over
time. In fact part of what’s held CFML back so much is Macromedia and
Adobe’s extreme commitment to not breaking any CFML code — and having to
ensure that even really bad code from a decade or so ago still runs! That’s
been one of the biggest problems for Railo — maintaining compatibility with
really stupid behavior in ColdFusion. Other languages are much more
pragmatic about that, and that’s how they’ve evolved faster than CFML and
why CFML looks old-fashioned by comparison. Because Macromedia and Adobe
never forced you to change, now you’re set in your ways and you don’t want
to change and you’re afraid of change.

So now we have the idea that today’s CFML will run “as-is” on Lucee in
.cfc and .cfm files and a new language — evolved from CFML — will run in
.lucee files. Your current CFML applications will continue to run “as-is”.
You can leverage the new, improved language if you want in .lucee files.
You can — if you wish — migrate some of your .cfc and .cfm files to .lucee
files, updating the code to match the new dialect.

This seems to be the best of both worlds: Lucee can offer a much improved
scripting language that might appeal to non-CFML devs, as well as letting
all that primordial code still run in “compatibility mode”.

Win-win!

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

“If you’re not annoying somebody, you’re not really alive.”
– Margaret Atwood

–
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/f30a90ef-7bf4-43a5-a13a-67348c43f9a3%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f30a90ef-7bf4-43a5-a13a-67348c43f9a3%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

15

Seriously folks, the ridiculous panic and silly assumptions in these
threads lately is exactly why so many non-CFML developers think the CFML
community aren’t “real” programmers. Change is a good thing! It’s how
progress is made. Sheesh.

I hate to bring this up, but I feel I must after seeing a lot of this kind
of messaging over the last week or so.

What has disappointed me, far more than people raising concerns, is the
belittlement of those opinions. I’m quite sure you don’t mean it this way
Sean, but your wording translates to calling anyone who raises any
objections “silly” and “ridiculous”.

No one in these past few threads has mentioned that CF is dead and there
has been little or no hyperbole, just legitimate choices to be made by
businesses and legitimate fears (and also a difference of opinion on which
particular changes are needed / wanted).

A branding change, and change or direction, is going to leave people
disoriented and will take time to settle. Reassurance, respect and
positivity should be the order of the day. I hope that will prevail.

Respectfully,

DominicOn 10 February 2015 at 19:24, Sean Corfield <@Sean_Corfield> wrote:

On Feb 10, 2015, at 9:35 AM, Jesse Shaffer <@Jesse_Shaffer> wrote:

Thank you for this - it calmed many concerns of one of my co-workers.

Well, if CFML devs weren’t such Chicken Little about this whole thing –
“OMG! CFML is Dead! You’re taking away my tags! You’re forcing me to learn
something new!” — they would have realized all along that that was EXACTLY
what was being discussed :slight_smile:

Seriously folks, the ridiculous panic and silly assumptions in these
threads lately is exactly why so many non-CFML developers think the CFML
community aren’t “real” programmers. Change is a good thing! It’s how
progress is made. Sheesh.

Languages evolve. Breaking changes get introduced in all languages over
time. In fact part of what’s held CFML back so much is Macromedia and
Adobe’s extreme commitment to not breaking any CFML code — and having to
ensure that even really bad code from a decade or so ago still runs! That’s
been one of the biggest problems for Railo — maintaining compatibility with
really stupid behavior in ColdFusion. Other languages are much more
pragmatic about that, and that’s how they’ve evolved faster than CFML and
why CFML looks old-fashioned by comparison. Because Macromedia and Adobe
never forced you to change, now you’re set in your ways and you don’t want
to change and you’re afraid of change.

So now we have the idea that today’s CFML will run “as-is” on Lucee in
.cfc and .cfm files and a new language — evolved from CFML — will run in
.lucee files. Your current CFML applications will continue to run “as-is”.
You can leverage the new, improved language if you want in .lucee files.
You can — if you wish — migrate some of your .cfc and .cfm files to .lucee
files, updating the code to match the new dialect.

This seems to be the best of both worlds: Lucee can offer a much improved
scripting language that might appeal to non-CFML devs, as well as letting
all that primordial code still run in “compatibility mode”.

Win-win!

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

“If you’re not annoying somebody, you’re not really alive.”
– Margaret Atwood

–
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/C55556AE-33CF-47BD-9FBA-634462B054B0%40corfield.org
.
For more options, visit https://groups.google.com/d/optout.

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

16

If we’re talking about legacy CFML features, the roadmap says keep that code in .cfc/.cfm.
I’d hope that wasn’t set in stone. We’re already seeing them cut out cfform style tags from the core and moving to extensions which I think is a brilliant move.

My reading is that there would be a way to start Lucee up with the various (officially supported) CFML modules you needed in order to run “full” CFML code — or you could start it up without some of those if you don’t use them (e.g., cfform and its ilk, the ORM — for which I would be very grateful since I don’t want Hibernate lumbering around in my app’s memory since I never use the ORM!).

I would presume that the .lucee extension would disrespect backward compatibility for various aspects from the get go.

That is also my reading (and I’m fine with that).

I would expect to be able to run World Singles .cfm / .cfc code on Lucee 5 with several CFML modules omitted to provide a leaner, faster CFML engine, and then we could write new components in .lucee files — and maybe new views too (with the stripped down tag set available there to “encourage” better separation of logic from the views).

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

dev.Objective() - Developing Apps, Developing Skills, Developing Community
– May 12-15, 2015 - Bloomington, MN - http://devobjective.comOn Feb 11, 2015, at 10:05 AM, Dominic Watson <@Dominic_Watson> wrote:

17

In general I like the idea of the .lucee approach. On the other hand it is
pretty obvious, that we will ran into the same problems like now, with the
subsequent releases of the .lucee dialect - e.g. the backward
compatibility, correcting wrong decisions etc. As ACF will probably not
support .lucee, we would have more freedom to evolve the dialect, for the
price of a less homogenous lucee engine and a general incompatibility with
ACF (if the .lucee source code is involved in frameworks, tools etc.).

On a sidenode. Let’s get rid of ACF! Well, I would like to, but we are
simply not able to port all our legacy applications mainly because of the
mass of (undocumented) incompatibilities with ACF. (In our case we update
the legacy applications regularly with knew releases of our CMS, which has
to stay compatible with ACF as long those legacy apps are supported). I
have a list of around 50 issues, which are not so easy to report because
some are ACF bug, some Railo bugs, some in between, some where reported but
refused. I guess a lot of people have similar problems. Before we sails to
new shores, I would like Lucee to put major effort in solving every (sane)
compatibility issue and provide a red carpet for the people who wants to
migrate. One problem is the resolve time of a blocker - when I try to
migrate, I want to do it now. Maybe we could plan some weeks/month to fully
concentrate on that problem, with the aim to solve or document every known
incompatibility. After that, I would be ready to board the ship.

On the switches. I did some framework stuff and had the same problems as
Sean described. While Micha invented the “dialect switches” to evolve the
language while staying compatible with ACF, it was painful to me to hear
“we can add a setting in the administrator for that”. How can you develop a
framework that supports all the scope options in Railo? Its pretty
difficult. Even more important, we have a small community and few OS tools
out there should be usable on as much as plattforms as possible. But those
settings are bad for portability, maintainability, testability etc.

How can we turn that weakness into a strength? I think we need to get rid
of the settings in the administrator and provide it on a package level. The
main unit of reuse is the package, if we can define the required settings
in the package, frameworks and OS tools and libraries could use their own
settings, decoupled from their consumer’s codebase. This would only work if
those settings are “a blackbox” to other packages, eg. how would a full
null support work with inheritance in other packages without full null
support. So I guess its not that easy. I think a major point would be to
identify the settings that are compile time settings, because those could
be easier implemented as “a blackbock”, eg. replace component{…} the new
syntax class{…}. Other things to discuss and clarify would be:

  • Which settings are reasonable on a package level.
  • Definition in the package, e.g. package.lucee in json-Format, with json
    schema validation?
  • Do the templates get recompiled after setting changes.
  • How can the package definition format evolve in future Lucee versions.
  • Tools to generate and edit the package definition.
  • …

If we could solve those problems, we would gain much more freedom with
backward compatibility in the future.

So, yes to .lucee, but let all willing people participate (migrate) and
lets think about how .lucee is going to evolve.

18

yes, the idea is that you can define with the startup script what you need
and Lucee will make sure you have it.

Every extension defines the bundles necessary to run the extension and the
extension can also define if a the bundles should be started right away or
not, the jdbc drivers for example to not start the bundles right away, they
get started when you use them the first time.
so even you have for example mysql extension installed, as long you not use
it, it get not loaded into the memory.

You also have a control panel where you can see all extension and the state
they have.

MichaOn Wed, Feb 11, 2015 at 8:35 PM, Sean Corfield <@Sean_Corfield> wrote:

On Feb 11, 2015, at 10:05 AM, Dominic Watson <@Dominic_Watson> wrote:

If we’re talking about legacy CFML features, the roadmap says keep
that code in .cfc/.cfm.
I’d hope that wasn’t set in stone. We’re already seeing them cut out
cfform style tags from the core and moving to extensions which I think is a
brilliant move.

My reading is that there would be a way to start Lucee up with the various
(officially supported) CFML modules you needed in order to run “full” CFML
code — or you could start it up without some of those if you don’t use them
(e.g., cfform and its ilk, the ORM — for which I would be very grateful
since I don’t want Hibernate lumbering around in my app’s memory since I
never use the ORM!).

I would presume that the .lucee extension would disrespect backward
compatibility for various aspects from the get go.

That is also my reading (and I’m fine with that).

I would expect to be able to run World Singles .cfm / .cfc code on Lucee 5
with several CFML modules omitted to provide a leaner, faster CFML engine,
and then we could write new components in .lucee files — and maybe new
views too (with the stripped down tag set available there to “encourage”
better separation of logic from the views).

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

dev.Objective() - Developing Apps, Developing Skills, Developing Community
– May 12-15, 2015 - Bloomington, MN - http://devobjective.com

–
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/D38125B5-E382-4F02-B00E-23C92325C843%40corfield.org
.
For more options, visit https://groups.google.com/d/optout.

19

Can’t wait to try this out. Going to be really great for building full
deployments when the end product is that much lighter. Really exciting.On 12 February 2015 at 00:25, Michael Offner <@Michael_Offner> wrote:

yes, the idea is that you can define with the startup script what you need
and Lucee will make sure you have it.

Every extension defines the bundles necessary to run the extension and the
extension can also define if a the bundles should be started right away or
not, the jdbc drivers for example to not start the bundles right away, they
get started when you use them the first time.
so even you have for example mysql extension installed, as long you not
use it, it get not loaded into the memory.

You also have a control panel where you can see all extension and the
state they have.

Micha

On Wed, Feb 11, 2015 at 8:35 PM, Sean Corfield <@Sean_Corfield> wrote:

On Feb 11, 2015, at 10:05 AM, Dominic Watson <@Dominic_Watson> wrote:

If we’re talking about legacy CFML features, the roadmap says keep
that code in .cfc/.cfm.
I’d hope that wasn’t set in stone. We’re already seeing them cut out
cfform style tags from the core and moving to extensions which I think is a
brilliant move.

My reading is that there would be a way to start Lucee up with the
various (officially supported) CFML modules you needed in order to run
“full” CFML code — or you could start it up without some of those if you
don’t use them (e.g., cfform and its ilk, the ORM — for which I would be
very grateful since I don’t want Hibernate lumbering around in my app’s
memory since I never use the ORM!).

I would presume that the .lucee extension would disrespect backward
compatibility for various aspects from the get go.

That is also my reading (and I’m fine with that).

I would expect to be able to run World Singles .cfm / .cfc code on Lucee
5 with several CFML modules omitted to provide a leaner, faster CFML
engine, and then we could write new components in .lucee files — and maybe
new views too (with the stripped down tag set available there to
“encourage” better separation of logic from the views).

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

dev.Objective() - Developing Apps, Developing Skills, Developing Community
– May 12-15, 2015 - Bloomington, MN - http://devobjective.com

–
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/D38125B5-E382-4F02-B00E-23C92325C843%40corfield.org
.
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+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/CAG%2BEEBxj96BPRYi4YtJ9kxweXG8Bc9YAE6oCHja5yTz9D2zQOQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBxj96BPRYi4YtJ9kxweXG8Bc9YAE6oCHja5yTz9D2zQOQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.

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

–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB