Outsider perspective

[Stephan Mos]

Hi Everyone,

Exciting to see some new development in the Railo/CFML space!

It looks like this new community driven effort is a great direction.

As an outsider Railo seemed like it had great developers but no organization (for example the two separate sites that were rarely updated just made things confusing.)

We run a fairly large site on railo and have been very happy with it (switched from CF to Railo over a year ago).

Unlike a lot of the frequent posters we are not involved at all in the development community and so have very little idea of what the plan was for Railo 5.0 and beyond.

In Adam Cameron's (http://blog.adamcameron.me/2015/01/lucee.html) post I saw this among the roadmap for Lucee's future:

"Being bolder about backwards compatibility deprecating old style CFML and pointless frontend tags"

Could someone please elaborate on what it means?

Not sure what is meant by old style CFML and frontend tags.

While we do keep up with development and switch to new tags on newer projects, we do have a lot of old code with deprecated tags that work fine, and the vast majority of our code base is still cf markup tags. Just wondering how we fit in with Lucee's future development roadmap.

Thanks,

Stephan

[Tim Brown]

Actually I guess I missed this: (from another thread's reply from Mark Drew)

"Public forums are actually here in Google.  There was a discussion about where the forums should be before the meeting and the message didnt get out to everyone. "

So I'm sure someone will weigh in on your question.

On Fri, Jan 30, 2015 at 9:33 AM, Tim Brown <timmay...@gmail.com> wrote:

Might want to re-post your question if you haven't already on the discourse forum (http://lucee.org:8080/) which will eventually be http://discourse.lucee.org as they aren't going to be using this google group any more in favor of Discourse.

--
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/5e6973b6-2978-43a8-b442-5fd286c4e1b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Brown]

Might want to re-post your question if you haven't already on the discourse forum (http://lucee.org:8080/) which will eventually be http://discourse.lucee.org as they aren't going to be using this google group any more in favor of Discourse.

On Fri, Jan 30, 2015 at 6:56 AM, Stephan Mos <ste...@modelscorp.com> wrote:

[Brad Wood]

My assumption when they say they are going to be bolder, is that they will be more likely to remove Adobe ColdFusion compatibilities if the community feels they are dumb.  Example, Railo never had CFClient and there are no plans to ever add it.  CF markup tags are related to any tag that directly outputs HTML or JavaScript.  Think cfform, cfinput, cfpod, cfdiv, cftable, etc.  These are widely hated in the post modern CFML community and perhaps at some point will be dropped from the core or moved into extensions.  I'm really just guess, but that's the kind of things that have always been talked about.  

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CANPdUeZ7VschDOjaQcg1xz4%2BZEpYtjVdvzOO7aN8VnrtWPYxkA%40mail.gmail.com.

[Stephan Mos]

Ok thanks, agreed that cfform and their like are pretty horrendous. 

We don't use them, so if that's the extent of old tags removed it wouldn't be a concern on our side.

[gary gilbert]

Hi Andere,

I would also like an official clarification as to what it means, we can all assume that it means the removal of the "dumbest tags ever to be created"(tm) but if they start breaking backwards compatability or inconsitencies in how the old core cfml tags work we are also going to have some major problems.  Our software is designed to work equally good with both Adobe as well as Railo/Lucee.  The more the languages differ from one another the harder it is for us to maintain and manage, and the more code branches we will need.  So I am truly hoping that its only the crappy front-end tags that will be dropped.


Cheers,

Gary

[Adam Cameron]

On 5 February 2015 at 10:15, gary gilbert <gary.g...@gmail.com> wrote:

Hi Andere,

I would also like an official clarification as to what it means, we can all assume that it means the removal of the "dumbest tags ever to be created"(tm) but if they start breaking backwards compatability or inconsitencies in how the old core cfml tags work we are also going to have some major problems.  Our software is designed to work equally good with both Adobe as well as Railo/Lucee.  The more the languages differ from one another the harder it is for us to maintain and manage, and the more code branches we will need.  So I am truly hoping that its only the crappy front-end tags that will be dropped.

I would expect any obsolescences to be presaged by a deprecation notice which would stay in place for at least 1-2 major point releases.

So if I was in the Lucee Association's position, I would do this:

* deprecate a whole bunch of stuff in 5.0

* for stuff like <cfform> and its ilk, move them out to a module (one that ships with Lucee) in 5.1. Offer security enhancements only.

* move them to an optional module for 5.2. Offer security enhancements only.

* cease all updates of any description and mark as obsolete in 5.3. Obviously the 5.2 version will still exist as an optional module.

?

-- 

Adam

[ADK]

Agreed. Let me also add that a notice ought to appear in the debug output that you are using a deprecated tag/function. Bonus points for also suggesting the proper alternative.

[Denard Springle]

I would also like an official clarification as to what it means, we can all assume that it means the removal of the "dumbest tags ever to be created"(tm) but if they start breaking backwards compatability or inconsitencies in how the old core cfml tags work we are also going to have some major problems.  Our software is designed to work equally good with both Adobe as well as Railo/Lucee.  The more the languages differ from one another the harder it is for us to maintain and manage, and the more code branches we will need.  So I am truly hoping that its only the crappy front-end tags that will be dropped.

One could argue (and I'm about to) that backwards compatibility *should* be broken in a lot of cases. So far, the team has been good about providing us with options for how some aspects of the system are treated - like nulls, for instance. Having null actually be null is advantageous to the language, and having the ability to still be not-null (like ACF) provides some backward compatibility. However, not only is this type of additional effort cumbersome and time consuming to implement, in many cases it allows developers to continue to use bad paractices.

From my perspective, backwards compatibility hurts both the language itself and the developers. Some things just shouldn't be backwards compatible if the language is to progress and modernize. If code is to remain compatible with both, then yes - you should have to maintain some level of 'if using ACF, do this - if using Lucee, do that' in your code. I don't see this requiring multiple branches - it could all exist in the same base code. Yes, it may end up being more time consuming for you, but we need to lead CFML out of the dark ages... and I, for one, am really hoping Lucee does just that. Someone needs to lead the effort - with Adobe spending all their time on goofy things like cfclient and not on addressing core language issues - someone needs to take the reins and lead the language in a new direction. Even if that means dragging some folks kicking and screaming along the way ;)

But yes, I'm sure if/when these changes become a reality that there will be enough advance warning as to allow developers to adjust their code to compensate for the changes, if they are so inclined. If Lucee, et al is smart they will lead the language in the right direction. If Adobe is smart they'll follow suit. If not, they will have to be divergent - and then let the best little engine that could win (that'd be Lucee, btw). \o/

My 2 cents...

-- Denny

[ADK]

This is such a tricky subject.

On the one hand, it's laudable to want to move the language forward and to cut and slash the cruft along the way, modularizing where it makes sense, etc. Personally, I am 100% for this.

However, I imagine - and perhaps I am completely wrong - that Lucee hopes to (eventually anyways) grab members from the ACF community to "seed" its base. Those of us who migrated over to Railo years ago have no problem making this move, but it has always been a rather painless transition from a codebase perspective primarily due to the backwards compatibility. Over the years I've witnessed person after person post to the Railo forum about being on ACF 8/9/etc. and moving now to Railo, etc. - rarely (ever?) have I seem similar posts from someone outside this already small community post in that forum.

So, while stripping away a lot of cruft and paring down and branching out in new directions and being less concerned with backwards compatibility, etc. sounds wonderful to me, personally - and to those who've already made the switch or at least played in these waters - I wonder how likely it is to be an impediment or pause for concern for those still in the ACF community to make the jump or even test the waters?

Getting management to try something new is rarely an easy task, I would presume that from a Lucee product marketing standpoint the desire would be to make that barrier to entry be negligible/non-existent? That management team needs to balance the cost of preservation of investment (existing codebase) vs. cost of switching... were I in that position, I think the greater that cost of switching, the more likely I would strongly consider another more established language that would make my business life simpler - and frankly more stable - down the road.

What's the plan to garner that all-important critical mass to get this thing to the next level and beyond?

So as I said, I am of two minds here: I want the lean, mean, modular, innovative, fast, hip machine that Lucee could become - indeed I am excited for it! But I'm also concerned that as a niche of a niche of a niche, it may just be me and a few others who will be playing with it.

[Sean Corfield]

On Feb 5, 2015, at 10:59 AM, ADK <and...@leftbower.com> wrote:
> This is such a tricky subject.

Indeed.

> However, I imagine - and perhaps I am completely wrong - that Lucee hopes to (eventually anyways) grab members from the ACF community to "seed" its base.

I’m not so sure. At this point, the Railo user base is pretty good and those folks will, as you said, happily make the move to Lucee and follow on down that path. Railo’s been a solid, free open source option for five years now and many ACF shops have migrated. Those that haven’t fall into a couple of categories, in my opinion:

* Too corporate / too entrenched to consider migration to FOSS at all.
* Too heavily reliant on ACF-specific features that they can’t move to Railo/Lucee (without a HUGE amount of effort).

So, whilst I think there may continue to be a slow trickle of migrations from ACF to Lucee, I think that ship has sailed… That means Lucee needs to draw developers from a wider pool going forward, and that means disconnecting from the stigma that is "ColdFusion" in the eyes of most of the world (I mix with a lot of developers in other languages and the favorable responses to the word "ColdFusion" are extremely few and far between - even tho’ most of the negativity is based on pre-JVM-rewrite timeline knowledge!). Any one of us who has interacted with developers in other communities knows how much disdain there is for both "ColdFusion" (the language / product) and for CFML developers in general.

> I wonder how likely it is to be an impediment or pause for concern for those still in the ACF community to make the jump or even test the waters?

It will be an impediment, yes. But I think there’s far fewer likely to jump ship now than there were. And many ACF shops will be looking to jump to a non-CFML technology when they do jump, to "get away from ColdFusion". In many ways, Lucee would be more attractive to those shops if it was seen as a clean break, a successful FOSS language not dragged down by the baggage associated with "ColdFusion".

> I think the greater that cost of switching, the more likely I would strongly consider another more established language that would make my business life simpler - and frankly more stable - down the road.

At World Singles, we’re in the middle of that process: we have 90kloc in CFML (+ 5kloc tests), which is Railo-specific (we switched from ACF five years ago), and we have 25kloc Clojure (+ 8kloc tests) which is our targeted language. We picked Clojure because it is a modern language that provides immutable data by default (which is awesome for concurrency) and a lot of powerful abstractions. Clojure first appeared in 2007 and in terms of jobs is currently smaller than ColdFusion - but Clojure is growing and ColdFusion is shrinking. Clojure’s *community* is much larger and much more active than what’s left of the CFML *community*. So I wouldn’t call Clojure a "more established language" but there are plenty of options that can make a business’s life simply and more stable. We live in a polyglot world where more and more new languages keep appearing all the time. They are often modular and interoperate really well.

If you’re looking for a "more established language" then you’d want to be moving away from CFML altogether and not considering a migration to Railo or Lucee - which was kind of my point above: those folk won’t come our way, they’ll go to Java or .NET or PHP.

> What's the plan to garner that all-important critical mass to get this thing to the next level and beyond?

See my comment about new languages above. A language doesn’t need to be wildly popular to be successful, it just needs to be good enough to attract folks from other languages - by evolving into something that is better (for those folks) than other languages. CFML definitely is not that sort of language, but Lucee could grow to be.

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

[Nando Breiter]

I would not discount the fact that Adobe has been shifting ColdFusion towards obscurity. Those who have been on Railo for some time won't sense the difference. I do, especially here in Europe. I've been shifting away from ACF because I sense a greater risk in remaining with ACF, on a variety of points like support, quality and vision. I would not be surprised if Adobe gives up on ColdFusion if they can't find new features, like cfclient, that they think will sell licenses to, how shall we put it, "challenged" developers (and this strategy continues to succeed in the market). Their strategy was good a decade ago. I don't see it working well anymore. Our field has become too complex to build a tool that makes it easy.

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

--

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/674c3949-887e-4bc0-9ace-53730efa3d9c%40googlegroups.com.

[ADK]

Thanks Sean. I certainly hope you are right re: Lucee could grow to be...

[Adam Cameron]

On 5 February 2015 at 19:34, Sean Corfield <se...@corfield.org> wrote:

On Feb 5, 2015, at 10:59 AM, ADK <and...@leftbower.com> wrote:
> This is such a tricky subject.

Indeed.

You pre-empt most of what I was thinking, said it better, and had more thoughts than I did on the subject. Just one thing to add...

 

> However, I imagine - and perhaps I am completely wrong - that Lucee hopes to (eventually anyways) grab members from the ACF community to "seed" its base.

I’m not so sure. 

I also don't think it's a winning approach. It's simply not sustainable to drive a model that is "chip away at the existing CFML install base". That's already getting smaller and smaller all the time, and before long will consist of a few hold-outs (who'll probably already be on Railo/Lucee), and other outfits whose ColdFusion is legacy / too deeply entrenched to pull out. Most of the ones that *do* migrate, will - as Sean said - be migrating off CFML altogether.

Lucee has to stop looking @ the CFML community for it bread and butter, and start marketing itself in other areas. I don't really get the impression they have much of a plan of how to do that though. Certainly Railo never seemed to. I'm hoping that with people like Alex onboard this might change, as he could probably even sell Lucee to the ColdFusion Team if he put his mind to it (that's a failed coals to Newcastle allusion).

So, yeah, focusing on what's gonna appeal to non-CFML developers is going to be key here.

(I know this is all at odds with my "formal spec" posting, but I like to consider multiple lines of similar but contrary thinking at once ;-)

-- 

Adam

[Andrew Penhorwood]

I think Sean just repeated what I hinted at in another post.  He did a much better job of describing the situation.  To move forward Lucee needs to appear like a new language not ColdFusion by another company.  Who would sign up to be a Pascal programmer today but you might become a Delphi programmer.  Delphi is Pascal only Delphi is cool or was.  Pascal died back in the 80s.

Andrew Penhorwood

[Sean Corfield]

On Feb 5, 2015, at 12:14 PM, Andrew Penhorwood <penho...@gmail.com> wrote:
> Pascal died back in the 80s.

I shed a tear for it’s passing - it was the first programming language I learned in depth, back in ’79 (I’d done a little Algol 60 before then).

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

[Michael Offner]

A lot to take in, sorry when I miss something ;-)

Moving stuff to extensions

So first of all the facts, Lucee 5 is moving a lot of stuff out of the core to extensions, this includes

- ORM (Hibernate)

- Search (Lucene)

- Form tags (YES!!!)

- Datasources (don't be afraid, some of them are preinstalled)

and that is just the beginning

this is not only about remove the old stuff, it is also about make the core ligther. 

depreciation framework

Then with Lucee>5 we plan to add a "depreciation framework", what does that mean?

Lucee will have a page in the admin and a possible setting in the application.cfc to define how deprecated stuff is handled.

there are 3 levels:

1. ignore the use of deprecated functionality

2. print a warning in the debug output

3. throw a error

So let's say you use the function "valueList" what is deprecated, if you have level 1, nothing is happening, on level 2 you get a warning in the debug output that "valueList" sucks and with level 3 Lucee is throwing a error.

ACF compatibility

ACF compatibility is still very important for Lucee in my opinion. today you can decide between being compatible and having it the right way with settings in the admin, that is not really handy!

But we you think about this:

Take as example a DVD player *, part of the DVD specification is that they must be able to play CDs, so every DVD player can also play CDs, means every DVD player is also a CD compatible.

Only the medium you use makes the difference, you don't have to change hundreds of setting in your DVD player to play a CD.

So what could be the medium for Lucee, that is very simple, the medium are templates (.cfc,.cfm).

What if Lucee acts different depending on the file extension.

So all templates with .cfm and .cfc extensions are still handled the old way, but files with the extension .lucee are handled in a modern way. this gives you the opportunity to still use your old code but you can extend it with new one and you have no confuguration nightmare anymore!

* i know DVD players are agent history, but it was the best example coming to my mind ;-)

What do you think about this?

Micha

--
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/0850BFD8-6A7D-4702-BAC4-CE1B8232D8A1%40corfield.org.

[Sean Corfield]

On Feb 5, 2015, at 1:58 PM, Michael Offner <mic...@lucee.org> wrote:

Moving stuff to extensions

So first of all the facts, Lucee 5 is moving a lot of stuff out of the core to extensions, this includes

- ORM (Hibernate)

- Search (Lucene)

- Form tags (YES!!!)

- Datasources (don't be afraid, some of them are preinstalled)

I’d give a big YES!!! to all of these.

depreciation framework

I approached deprecation in FW/1 in a similar manner so I like that approach.

So what could be the medium for Lucee, that is very simple, the medium are templates (.cfc,.cfm).

What if Lucee acts different depending on the file extension.

Sounds good to me. I look forward to writing Lucee code :)

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)

[ADK]

Re: lucee extension - I think that's a great idea!

[ADK]

Mine too: UCSD Pascal... just loved it way back then! then it was COBOL... my God I hated that language...

[Andrew Penhorwood]

I once write Pascal code too.

Andrew Penhorwood

[Andrew Penhorwood]

Sounds very reasonable to me.  So we can say I write stuff in Lucee and it also runs ColdFusion code.

Andrew Penhorwood

[Sean Corfield]

On Feb 5, 2015, at 2:39 PM, ADK <and...@leftbower.com> wrote:
> Mine too: UCSD Pascal... just loved it way back then!

I owned a SAGE IV (68000-based) - ran p-System as its "native" environment. I loved that machine! I wrote a lot of UCSD Pascal!

> then it was COBOL... my God I hated that language…

Hah, I ported the Microfocus COBOL compiler to the Sun-4 (SPARC) and Motorola 88000 chips. It was mostly written in COBOL, with some C code and a tiny bit of assembler for each new platform. I was actually quite fond of COBOL back then...

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

[Sean Corfield]

On Feb 5, 2015, at 2:37 PM, ADK <and...@leftbower.com> wrote:

Re: lucee extension - I think that's a great idea!

I think .lucee is a bit verbose. I looked on filext.com and it seems both .lc and .lce are already "taken" but .luc is not so maybe that’s a good choice?

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

[Michael Sprague]

Big plus one here. Different file extensions for different behavior/compatibility makes a lot of sense. 

I will be maintaining several CFML apps for years to come but would rather write new code that takes advantages of Lucee's progress going forward. 

Sad truth but it will be easier to "sell" Lucee as a JVM language, without ever mentioning CFML, to some clients that have tainted views for one reason or another. 

Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/30f354ad-9802-4747-a179-b2aeae4f6ff2%40googlegroups.com.

[Carl Von Stetten]

Micha,

I like almost all of what you stated, with a few exceptions:

• I don't think .lucee would be a suitable file extension, but .lcfm and .lcfc could distinguish "pure Lucee" from ACF-compatible code and would distinguish components from view code.
  
• I think you mean "deprecation" instead of "depreciation" - a common point of confusion, just ask @dfgrumpy on the CFHour podcast. ;-)
• I agree that setting ACF-compatibility in the administrator is not ideal.  What if instead there was a "this.acfcompatibility" setting added to application.cfc.  It would take a struct, and each deviation from ACF that Lucee takes would have a distinct key name and boolean value:
• this.acfcompatibility= { supportsomeACFscrewup: true, supportsomeotherACFscrewup: false };

But overall, I like where the thinking is going.

-Carl V.

On Thursday, February 5, 2015 at 1:58:35 PM UTC-8, Micha wrote:

[denstar]

On Thu, Feb 5, 2015 at 1:17 PM, Sean Corfield wrote:

On Feb 5, 2015, at 12:14 PM, Andrew Penhorwood wrote:
> Pascal died back in the 80s.

I shed a tear for it’s passing - it was the first programming language I learned in depth, back in ’79 (I’d done a little Algol 60 before then).

Pascal FTW!  "The king is dead, long live the king" Re: Delphi (and such), which I did some work in a couple years ago-- I hadn't even known from whence it sprang, at first.  Pascal is what got me into assembly language... good times!

-Den

[Denard Springle]

Moving stuff to extensions

depreciation framework

 

ACF compatibility

Wow... sometimes I'm really just too short-sighted.

Great ideas all of them. +1

-- Denny

[Sean Corfield]

On Feb 5, 2015, at 4:24 PM, Carl Von Stetten <vonner...@vonner.net> wrote:
> I don't think .lucee would be a suitable file extension, but .lcfm and .lcfc could distinguish "pure Lucee" from ACF-compatible code and would distinguish components from view code.

No, we really need to get away from the association with ColdFusion.

And really only one extension is needed - since if a file starts with < it’s going to be a view template otherwise it’s a script file (and I _really_ want to see tags omitted from business logic - that’s part of what gives ColdFusion such a bad rap!).

> • I think you mean "deprecation" instead of "depreciation" - a common point of confusion, just ask @dfgrumpy on the CFHour podcast. ;-)

The CFHour folks don't have the excuse of English not being their first language (although sometimes I wonder... :)

> • I agree that setting ACF-compatibility in the administrator is not ideal. What if instead there was a "this.acfcompatibility" setting added to application.cfc.

And then you have a language feature that is specifically tied to a vendor-specific implementation which is poor design... Many of the settings aren't ACF vs Railo (Lucee), they're multi-way adjustments on how a particular language feature behaves, so it's not really even about compatibility - it just happens that there's a mode for each features that happens to behave the same way as ColdFusion does.

> But overall, I like where the thinking is going.

Agreed.

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

[Jas Panesar]

Nice to see familiar names here.  

Random thoughts of support:

- moving/deprecating legacy tags to extensions is a great idea.  Innovation and backwards compatibility don't always like each other but this could be a simple and clean way to support both.

- .lc would be a nice extension if it's not commonly used.  I'm imagining typing .lucee 10,000 times..

- hope extensions can be managed through the command line

Jas

[Sean Corfield]

On Feb 5, 2015, at 7:44 PM, Jas Panesar <jas.p...@gmail.com> wrote:

- .lc would be a nice extension if it's not commonly used.  I'm imagining typing .lucee 10,000 times..

http://filext.com/file-extension/LC

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

[Mark Drew]

Reminds me of Live Cycle for some reason. 

.lu ?

Mark Drew

On 6 Feb 2015, at 06:05, Sean Corfield <se...@corfield.org> wrote:

On Feb 5, 2015, at 7:44 PM, Jas Panesar <jas.p...@gmail.com> wrote:

- .lc woul be a nice extension if it's not commonly used.  I'm imagining typing .lucee 10,000 times..

http://filext.com/file-extension/LC

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+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/AB97FB08-2EC5-4DC8-B69B-2823EF1384BB%40corfield.org.

[Sean Corfield]

On Feb 5, 2015, at 10:43 PM, Mark Drew <mark...@gmail.com> wrote:

.lu ?

ThoughtWing Library Unit: http://filext.com/file-extension/LU

That’s why I suggested .luc since it has no association on filext.com!

[Mark Drew]

Agh! Missed that one. So we are going to be serving good.luc to everyone! :)

Mark Drew

--
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/7CE7DAB7-0197-49C7-9077-C5BEA5DFA060%40corfield.org.

[Adam Cameron]

On Friday, 6 February 2015 03:44:08 UTC, Jas Panesar wrote:

- .lc would be a nice extension if it's not commonly used.  I'm imagining typing .lucee 10,000 times..

Yeah, but you're not exactly typing it 10000 *in a row*. How many new files are you creating within a given day?

And, like .java, .groovy... we're not all scared of keystrokes.

I think .lucee is better than scrabbling around on filext.com trying to find a non-used extension that vaguely resembles something to do with Lucee.

.luc is the best one suggested so far, but... really... just stick a coupla Es on the end and be done with it.

If someone can't cope with typing .lucee occasionally, there's nothing to stop them from remapping .l or something on their own installation.

-- 

Adam

[Adam Cameron]

On Thursday, 5 February 2015 21:58:35 UTC, Micha wrote:

What if Lucee acts different depending on the file extension.

So all templates with .cfm and .cfc extensions are still handled the old way, but files with the extension .lucee are handled in a modern way.

This has, as others have mentioned, a lot of potential.

Is this a "what if...?" or is it actually in the pipeline?

-- 

Adam

[Andrew Dixon]

I'm with Adam on this one, there is nothing wrong with .lucee and makes it very clear what the file is for. 

Also would like to see the "coldfusion" support moved out into an extension so you only install it if you want it, so then Lucee becomes a language in it's own right that has CFML support if you want/require it.

Kind regards,

Andrew

http://about.me/andrew_dixon

--

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/51c4ec07-65dc-498a-a507-423c13e0e5a3%40googlegroups.com.

[Gavin Pickin]

I wrote a rant about changing the name and file extension and starting fresh… everyone laughed at me… but its a good idea.

They already have a server name, so thats solved, so .luc is probably a good one… I would have gone with something whiz-bang and edgy, but nothing wrong with lucee and .luc 

Do you have 1 extension? 

Or 1 for scripts / classes & 1 for views like .lucv?

I know a lot of people want to make it so tags only run in a view file… make it more like a tempting extension, similar to how react does.

Makes it tough on framework and library and tools people though… but we all know that.

Gavin Pickin

gpi...@gmail.com

http://www.gpickin.com

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAB1Zp0Jt%2BnuXqP0GxBpW%2BO4mqcPwV-n6sycFRMjTEw%2Bgz%2Bq-QQ%40mail.gmail.com.

[Gavin Pickin]

Pascal / Object Pascal, with Delphi isn’t dead.

They have Delphi > Native iOS and Android tools out… my boss is trying to convince me to use them all the time ;)

Funnily enough, dot net developers I know use it to make their iOS apps :)

Gavin Pickin

gpi...@gmail.com

http://www.gpickin.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+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/e19dfb9d-9ee7-4b54-a8a2-1611f122dd7d%40googlegroups.com.

[Michael Offner]

about the extension, it is not my intention to call it ".lucee" that was just to make it clear that there could be a lucee specific extension.

so let's think about it:

Distinction between component and templates?

So the first question is, do we need a distinction with the extension?

from a technical standpoint no, it is easy to recognize if a template is a component or not.

And in my opionion mixing component and templates is a bad behaviour anyway, but f course that is my opinion.

What we have today

cfm=ColdFusion Markup (language)

cfc= ColdFusion Component

we are familiar with this extension, but they suck, to be honest!

Do we have a markup language in there, is that the message, I prefer the term script and template language.

What Lucee specific extension we already have

.lar = Lucee Archive (was .ra)

.lco = Lucee core (eas .rc)

What could it be if we have A distinction between component and templates

lt,lte,lute,templ,html,htm=Lucee Template

lc,lcm,luco,comp,cmp=Lucee Component

What could it be id we have NO distinction between component and templates

luc,lu

It is important that the most popular editors not already has support for the choosen extension

Micha

--
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/2164a6ad-0660-4458-90e4-b39199b226c2%40googlegroups.com.

[Jean Moniatte]

On Fri, Feb 6, 2015 at 11:33 AM, Michael Offner <mic...@lucee.org> wrote:

it is not my intention to call it ".lucee"

What is wrong with .lucee ? It looks like the most simple, elegant and catchy option to me.

[Matt Quackenbush]

Agreed. Besides, if a real IDE is supported, no one will ever have to type the extension, anyway. I'm not sure I've ever typed ".groovy" other than just now in this email.

> --
> 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/58a52c64-ff77-48f2-8beb-27597d657fa7%40googlegroups.com.

[Michael Offner]

it's funny, no body is discussion about the general idea, only about the extension for it ;-)

It's like we asked if we should get a new car and everybody is already discussing about the color of the car.

Adam asked what "what if" means, if this is already in the pipeline or just a idea?

If the community likes the idea, we go for it! technically there are no hurdles we cannot cross.

Micha

 

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAKa5oqJ9KWRrNX1-BK3gpYY_Dvze_4mfrKAg8kjhgUMgBDg%3Dqg%40mail.gmail.com.

[Matt Quackenbush]

Sorry for the misunderstanding, Micha, but I thought it was pretty clear that the vast majority was very much in favor. There'd be no other reason to discuss the extension. :-)

To be extra clear, I personally could not possibly be more in favor of the idea of moving forward and leaving Adobe completely in the dust so that "outsiders" can be enticed to give it a try, and this idea is quite likely the best way to do just that.

> To infinity and beyond!

:-)

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBzRBWE2Ju-sS5Vx%3D8bYjKymWrdK4gC8uCLg4VWRQUzRjw%40mail.gmail.com.

[Tanner Bachman]

Just my 2 cents, but why worry the extension name at all...make it a setting in the Serve and/or Web admin so that people can use whatever extension they want forneach of the 3 file handlers (CFML, CF Component and Lucee). Use a comma delimited list or something.

[Adam Cameron]

On 6 February 2015 at 10:59, Michael Offner <mic...@lucee.org> wrote:

it's funny, no body is discussion about the general idea, only about the extension for it ;-)

It's like we asked if we should get a new car and everybody is already discussing about the color of the car.

Adam asked what "what if" means, if this is already in the pipeline or just a idea?

If the community likes the idea, we go for it! technically there are no hurdles we cannot cross.

I didn't see any point in discussing it further prior to clarifying whether you were simply speculating, or whether it was going to happen. Which you still haven't. If it was merely a "what if...?" then my reaction is "lovely, but can we discuss something concrete pls, otherwise we're just wasting our time".

And the file extension "conversation" only cropped up because someone admitted being too lazy to type five characters for a file extension. I didn't think it needed conversation at all. The extension should be ".lucee", and should be the same for both class and view files.

Still: ppl like chatting... there's nothing wrong with that.

-- 

Adam

[Mark Drew]

The problem is that you need to configure that in the Servlet mapping (if you look in web.xml ) 

   <servlet-mapping>

      <servlet-name>CFMLServlet</servlet-name>

      <url-pattern>*.cfc</url-pattern>

      <url-pattern>*.cfm</url-pattern>

      <url-pattern>*.cfml</url-pattern>   

      <url-pattern>/index.cfc/*</url-pattern>

      <url-pattern>/index.cfm/*</url-pattern>

      <url-pattern>/index.cfml/*</url-pattern>

  </servlet-mapping>

Rather than a setting for Lucee itself. So you would either have to get Lucee to listen to everything and then filter out what it wants which is not optimal. 

At the end of the day you can get it to do whatever you want :

   <servlet-mapping>

      <servlet-name>CFMLServlet</servlet-name>

      <url-pattern>*.lucee</url-pattern>

      <url-pattern>*.luc</url-pattern>

      <url-pattern>*.lucy</url-pattern>   

 

  </servlet-mapping>

Regards

Mark Drew

--
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/CAG-7QUtvrzAyh4AiVYGRCcNVMmSw0rMXOz5totSbS8QEzycFEg%40mail.gmail.com.

[Mark Drew]

On 6 Feb 2015, at 11:27, Adam Cameron <dac...@gmail.com> wrote:

I didn't see any point in discussing it further prior to clarifying whether you were simply speculating, or whether it was going to happen. Which you still haven't. If it was merely a "what if...?" then my reaction is "lovely, but can we discuss something concrete pls, otherwise we're just wasting our time”.

It is going to happen if the community wants it to happen. That is people discussing it. So you have to throw ideas out there to the community. Micha did say: "If the community likes the idea, we go for it! technically there are no hurdles we cannot cross.”

And the file extension "conversation" only cropped up because someone admitted being too lazy to type five characters for a file extension. I didn't think it needed conversation at all. The extension should be ".lucee", and should be the same for both class and view files.

Makes it easier for parsers and what have you. Which is where the next question for me is, how is the lucee language going to look? Can we finally remove the "<cf” from view tags pls?

Still: ppl like chatting... there's nothing wrong with that.

If I ruled, people wouldn’t chat, they would converse! 

MD

[Adam Cameron]

If I ruled, [...]

People would revolt.

-- 

Adam 

[Mark Drew]

On 6 Feb 2015, at 11:34, Adam Cameron <dac...@gmail.com> wrote:

If I ruled, [...]

People would revolt.

Well, people are revolting already. Both meanings. 

[Michael Offner]

don't get me wrong, it was just great to watch that people already embraced that idea like this. 

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAKa5oqJteSmBfR18uq%3D4%3D0tmoSEvhpsRKbvhNNJGbw4BchrC-Q%40mail.gmail.com.

[Michael Offner]

yeah i was thinking about that, but there are 2 problems

1. mark already explained the first, second is that most people are depending on existing applications (FW/1, coldbox ...), so they need at least a default extension, a common ground.

On Fri, Feb 6, 2015 at 12:17 PM, Tanner Bachman <tanner....@gmail.com> wrote:

Just my 2 cents, but why worry the extension name at all...make it a setting in the Serve and/or Web admin so that people can use whatever extension they want forneach of the 3 file handlers (CFML, CF Component and Lucee).  Use a comma delimited list or something.

--
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/51286f55-fc10-472e-b543-e60520891aa8%40googlegroups.com.

[Michael Offner]

it just loved the dynamic of the discussion ...

Micha

--
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/CAFwR%2BKdKWfeSMSpUFSNEcBiEJsiOwYDV-3BWApoCX3Qu3xZebg%40mail.gmail.com.

[Tanner Bachman]

Micah, I was assuming that Lucee could adjust the web.xml file automatically based on the users input, however I have no clue as to whether the admin has/could have access to that file. Regarding the common ground issue...I agree and would just implement the basic defaults which probably leads us back to the file extension discussion...and I just don't care what it is.

Your the Ninja Master so I'm happy to sit back and do what I'm told.

Regards,

Tanner Bachman

[Adam Cameron]

On Friday, 6 February 2015 10:33:29 UTC, Micha wrote:

about the extension, it is not my intention to call it ".lucee" that was just to make it clear that there could be a lucee specific extension.

so let's think about it:

Distinction between component and templates?

So the first question is, do we need a distinction with the extension?

Nope.

-- 

Adam 

[Adam Cameron]

On Friday, 6 February 2015 11:32:25 UTC, Mark Drew wrote:

On 6 Feb 2015, at 11:27, Adam Cameron <dac...@gmail.com> wrote:

I didn't see any point in discussing it further prior to clarifying whether you were simply speculating, or whether it was going to happen. Which you still haven't. If it was merely a "what if...?" then my reaction is "lovely, but can we discuss something concrete pls, otherwise we're just wasting our time”.

It is going to happen if the community wants it to happen. That is people discussing it. So you have to throw ideas out there to the community. Micha did say: "If the community likes the idea, we go for it! technically there are no hurdles we cannot cross.”

That is to "discussion" what a stick of celery is to a BBQ.

There's clearly more to the idea that Micha is floating regarding diverging code "styles" from simply CFML to something else which one might put into a file with an entirely different extension, and unless he's gonna actually add some substance to it, I see little point in fucking around trying to guess what he's on about.

Which leaves the most interesting part of the discussion to be quibbling over the merits or otherwise of a five character file extension.

Your mileage might vary.

-- 

Adam

[Tom King]

Please not .lucee - those extra two chars would add days to my typing :)

But '.luc' or 'lc' might be nice  :P

http://www.fileformat.info/ext/l.htm

On Thu, Feb 5, 2015 at 9:17 PM, Sean Corfield <se...@corfield.org> wrote:

On Feb 5, 2015, at 12:14 PM, Andrew Penhorwood <penho...@gmail.com> wrote:
> Pascal died back in the 80s.

I shed a tear for it’s passing - it was the first programming language I learned in depth, back in ’79 (I’d done a little Algol 60 before then).

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+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/0850BFD8-6A7D-4702-BAC4-CE1B8232D8A1%40corfield.org.

[Dave Merrill]

Keep in mind too that some sites try to hide the technology they use, so they configure the web server to process .html files as CFML. That shouldn't change how Lucee processes those files. If the plan is for the file extension to control compatibility, there would need to be a way to configure how each extension is handled, or to put it differently, which extension(s) are handled as legacy/ACF-compatible vs new-world/Lucee compatible.

Dave

[Risto]

So should I name my first file Sweet.lucee or Sweet.lucy?

[Mark Drew]

> On 6 Feb 2015, at 15:17, Dave Merrill <enig...@gmail.com> wrote:
>
> Keep in mind too that some sites try to hide the technology they use, so they configure the web server to process .html files as CFML. That shouldn't change how Lucee processes those files. If the plan is for the file extension to control compatibility, there would need to be a way to configure how each extension is handled, or to put it differently, which extension(s) are handled as legacy/ACF-compatible vs new-world/Lucee compatible.

As I mentioned before, I doubt this would make it to the internals of Lucee (nor should it) since it is quite well defined in web.xml and it could be to have a LuceeServlet and a CFMLServlet and that would easily define it:

<servlet>
<servlet-name>CFMLServlet</servlet-name>
<servlet-class>lucee.loader.servlet.CFMLServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>CFMLServlet</servlet-name>
<url-pattern>*.cfc</url-pattern>
<url-pattern>*.cfm</url-pattern>
<url-pattern>*.cfml</url-pattern>

<url-pattern>*.html</url-pattern>

<url-pattern>/index.cfc/*</url-pattern>
<url-pattern>/index.cfm/*</url-pattern>
<url-pattern>/index.cfml/*</url-pattern>
</servlet-mapping>

<servlet>
<servlet-name>LuceeServlet</servlet-name>
<servlet-class>lucee.loader.servlet.LuceeServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>CFMLServlet</servlet-name>
<url-pattern>*.lucee</url-pattern>
<url-pattern>*.luc</url-pattern>

<url-pattern>/index.lucee/*</url-pattern>
<url-pattern>/index.luc/*</url-pattern>
</servlet-mapping>


And you are done

MD

[Adam Cameron]

On 6 February 2015 at 15:17, Dave Merrill <enig...@gmail.com> wrote:

Keep in mind too that some sites try to hide the technology they use, so they configure the web server to process .html files as CFML.

Some? All of them should.

Is this sort of thing not usually done with mod rewrite though, not pushing all HTML files through to the CFML server?

-- 

Adam

 

[Dave Merrill]

That works, didn't get what you meant by that before, with the two separate Lucee servlets.

Dave

[Andrew Dixon]

Mark, unless I'm misunderstanding shouldn't the second "servlet-name" in the "servlet-mapping" section be "LuceeServlet" and not "CFMLServlet"?

Kind regards,

Andrew

http://about.me/andrew_dixon

--
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/D72E9A4B-C4D4-4790-B0A0-604AC6DDB81C%40gmail.com.

[Mark Drew]

Yep, the second one should say LuceeSevlet, bit if a typo. 

Bear in mind that LuceeServlet DOESNT EXIST yet. 

MD 

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG1WijVoWdDah%3Dskwy2HzGkJ4NYU2Ypj%2B8gjdy9qxGt6NOzH-g%40mail.gmail.com.

[Dan Kraus]

I really like the idea of having a common-ground support of CFC and CFM and adding a new extension to segment the new from the old.

I feel like the homepage of lucee.org says it all:

"Lucee is a light-weight dynamic scripting language for the JVM that enables the rapid development of simple to highly sophisticated web applications."

It doesn't say anything about CFML, open source alternative, etc. It's a JVM scripting language. Continue to position it as such, shed the stigma and the baggage and it becomes attractive to other developers again and the eye rolls start to go away. Instead you get curious interest "You work with Lucee? What's that?". To echo others, chipping away at ACF's pool isn't going to grow this community and project very much. It's been a downward trend. Infuse new blood in from other places. We've hired some people who had more .NET and Java exposure in the past who have picked up writing script based CFCs up quick and have found it to be pretty easy and straight forward to work with and get what they need done.

-Dan Kraus

(I can add something about being a Lucee Supporter to my signature line or something, right? That was one of the perks, right? I want a membership card!)

On Friday, January 30, 2015 at 7:56:19 AM UTC-6, Stephan wrote:

Hi Everyone,

Exciting to see some new development in the Railo/CFML space!

It looks like this new community driven effort is a great direction.

As an outsider Railo seemed like it had great developers but no organization (for example the two separate sites that were rarely updated just made things confusing.)

We run a fairly large site on railo and have been very happy with it (switched from CF to Railo over a year ago).

Unlike a lot of the frequent posters we are not involved at all in the development community and so have very little idea of what the plan was for Railo 5.0 and beyond.

In Adam Cameron's (http://blog.adamcameron.me/2015/01/lucee.html) post I saw this among the roadmap for Lucee's future:

"Being bolder about backwards compatibility deprecating old style CFML and pointless frontend tags"

Could someone please elaborate on what it means?

Not sure what is meant by old style CFML and frontend tags.

While we do keep up with development and switch to new tags on newer projects, we do have a lot of old code with deprecated tags that work fine, and the vast majority of our code base is still cf markup tags. Just wondering how we fit in with Lucee's future development roadmap.

Thanks,

Stephan

[Sean Daniels]

+1 Having two servlets, web.xml is easy enough to customize and we can continue using whatever extensions we want by editing the relevant servlet-mappings.

I’m totally digging this concept. Move on from .cfm/.cfc, move the language forward while maintaining compatibility for those who need it.

I am extremely excited for Lucee and where she will take us!

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/396EA750-6702-4E72-A815-8DDD99C80D0A%40gmail.com.

[Nicholas Kwiatkowski]

Additionally, we should think about IDE vendors. CF support is half-assed in most IDEs, and those providing some of the better support pretty much locked into one or two extensions.  I'd vote for having a single or set of extensions which drive this content.

-Nick

On Friday, February 6, 2015 at 7:03:36 AM UTC-5, Micha wrote:

[Judith Barnett]

I think the concept is an excellent idea. Also, I like the idea of .lucee or.luc for the extension, and I see no need for separate extensions for templates versus components.

[Dan Kraus]

I actually like what Rails has done with templates vs plain ruby code. ERB is a Ruby templating library. You end up with something like 'controllers/user.rb' with straight Ruby code and 'views/user/index.html.erb'

<ul> <% @users.each do |user| %>

   <li><%= user.name %> - <%= user.email %></li>

<% end %> </ul>

The ERB tags in the html are rendered/compiled and then the rest of the html is served. If I recall correctly, you can even chain the file extensions to play with other processors and libraries. I don't think it'd hurt to have two extensions to be honest, one for components, and one for templates (the only real place CF tags belong)

--
You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/5Ol7vTOm6Gk/unsubscribe.
To unsubscribe from this group and all its topics, 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/CACtg%3DUKCdq-aw_iO-UtbHPk3xaaFV989B5iTvu5yBveJX49GYA%40mail.gmail.com.

[Geoff Parkhurst]

On 6 February 2015 at 10:33, Michael Offner <mic...@lucee.org> wrote:
> cfm=ColdFusion Markup (language)

Bring back .dbm I say!

(get off my lawn)

[Evagoras Charalambous]

To get back to the original post, I understand people's concern about having to change existing code and systems that run on ACF or Railo. Nobody wants to do that in a corporate environment when you have something in place that just works. For people like that, maintaining 100% (or close to that) backwards compatibility with ACF/Railo is very important, and they can justify it better to corporate heads.

However, by doing that I fear that Lucee will simply fall on the wayside, just like ACF has been for the last years, and unfortunately Railo as well. To have a language move forward you need new people to pick it up, with vitalized energy and excitement of the potential, to blog about it, talk about it, come up with awesome frameworks and plugins, make pull and push requests to git, be active. That is never going to happen if the language plays it safe. In a few years, there will be no need for ACF, Railo or Lucee. Look at all the people that we used to look up to for blogs and info - they may still publish a blog once in a while on CF, but they really don't have anything new to talk about anymore. It's all been said and done. If you are a developer who wants to write about the language, what do you really have to write about regarding CF, other than finding bugs in Adobe's or Railo's implementation?

Once we agree on a radical new approach to the language, then a lot of exciting things can happen. Micha talked about a new extension for example. Personally, I don't care if the extension is ".awesomenewjavajvmweblanguage", ".luc" or what not. The idea that we can lay a foundation for backwards compatibility, make that a starting point for the race, and then run forward with it is brilliant. I don't even care for backwards compatibility 1-2-3 settings (like Micha suggested). If someone wants to write ACF compatible code then stick with ACF, pay their fees and shut up. If you want to be involved with a sweet language that evolves, then go with Lucee.

One other thing I want to mention is the difficult distinction that needs to exist with the language itself and frameworks. I understand that those are not one and the same, and where the language stops, it's the framework's function to step in to make our life easier as a programmer. Frameworks like FW/1, ColdBox and so on really do make our lives easier (some would argue that), but I am a believer in what they try to achieve. If you look at a framework like Laravel, and create an app with it, the first thing you will ask yourself is what in the world are you doing writing CF? It's just plain awesome. You might say Laravel is not PHP though, and PHP sucks. I agree on that, PHP is not the best thought out language, but it moves forward, and it provides an incentive for frameworks like Laravel to come out and flourish. So, having that distinction in mind, I would still love to see an effort in the language itself to standardize things, in a sort of recommended framework approach to writing an app. There are just not enough people to create something like Laravel, and perhaps throwing some effort behind frameworks like FW/1 would really help bring new people in from other languages. To bring an example of what can be done, look at the way we write CFM and CFC nowadays, mixing script and tags in both. Lucee could make scripting mandatory for both, have one extension for both, and implement a Blade style template engine, where instead of writing HTML and injecting tags or script in templates, you would instead write script and inject HTML.

Honestly, I am happy we are having these type of conversations and excited to see what we can do.

[Dave Merrill]

Ah, templating... endless options here...

Personally...

- Using one extension for both script and template files seems to discard an available bit of info when eyeballing a collection of files. But a) in most cases directory structure should make the distinction clear, and if not, it's certainly arguable that there are larger problems afoot. b) Nothing stops you from using two extensions, just register both lucscr and luctmp (say), and use the appropriate one by convention.

- There's no way I like <%= user.name %> more than #user.name#. Maybe it's not as buzzword compliant, but it sure is cleaner and less verbose, at the expense of having to double # signs if to display one. Arguably <cfloop and friends are somewhat uglier, and apparently there's a lot of desire to get away from the 'cf' baggage, so I'm not sure where that leaves us.

- If Lucee is going to make fundamental changes in this area, it seems unlikely we need to reinvent the wheel. Don't know how easy it is to drop an existing package into Lucee, but that's probably the best plan. Is template handling another aspect of the language that should be modular rather than core, so you can drop in jsp, mustache, haml, cfml, etc?

- Unless template files are fully compatible with some widely supported convention, this sort of change would render every IDE and code editor useless. Extensions are typically configurable in an editor, but template parsing within a given language typically is not. That seems like a significant downside. It's hard enough gaining enough momentum to enhance the decent but clearly less than ideal CFML support that exists in current IDEs. The community (myself included) didn't manage to improve IntelliJ's CFML support, even though it's amazingly great as an IDE (IMO). Starting over from zero means there won't be anything available for some time.

Dave

[Sean Corfield]

On Feb 6, 2015, at 1:19 AM, Andrew Dixon <andrew...@gmail.com> wrote:
> I'm with Adam on this one, there is nothing wrong with .lucee and makes it very clear what the file is for.

True. I’m just used to .clj, .cljs, and .rs :)

> Also would like to see the "coldfusion" support moved out into an extension so you only install it if you want it, so then Lucee becomes a language in it's own right that has CFML support if you want/require it.

Big ol’ +1 on that! :)

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

[Tanner Bachman]

All this talk of killing "cf baggage" sounds like basically not supporting/updating CFML anymore.  So where does that leave the coldfusion developers that came over from Railo/ACF?  The reason I started (and continue to use) coldfusion was because it was tag based.  Super easy to learn and use...and you can rapidly build anything.

Sounds like at this point Lucee is a name, with no language, that is "backwards compatible" with cfml/coldfusion.

I agree that Adobe did a poor job of implementing certain things and an even worse job of marketing it, but I see no reason why that requires the invention of a new language.  If we now have so much control over everything, why not fix what's broken and add new tags/scripts that can make quick work of other commonly complicated programming tasks.

I hear people talking about moving coldfusion out of the core and into an extension...so what's left.  I hear things like "let's make scripting required in all templates"...why?  There are a million other scripting languages out there already, why start from scratch.  We all know that no language is perfect, and Lucee will be no exception, but why compete with other scripting languages.

I'm sure I'm probably one of the few that feel this way, but I'm not a "scripty" guy.  I love cfml and feel that a lot of awesome things could be done with it that just weren't and instead of improving it, it's being abandoned.

So where do the "coldfusion/cfml" developers go...ACF/openbd?

I know this is a community forum and ideas are flying right now, but I'd like to hear from someone in charge...get their vision of the future without biased from the community.

Thanks,

Tanner Bachman

[Shane McMurray]

I was just looking at switching to Railo and did some initial tests with one of my sites. Then I saw the move to Lucee. I'd like to add my 2 cents on the migration item. 

Just some background, I've been using CF since version 1.5, love it, and have stayed with it since. ACF is what I'm using now and I've played with OBD and Railo both.

I'm a small company, have a couple sites that basically provide reports/data to end users. Some paid, some free. Surviving on the paid part.

So, the migration issue for me has been the setup and configuration process. I know windows, have used it for years, it works for me. I use ACF because the setup is simple. I install it and it works. 

I've tried Railo several times and until recently I was able to successfully getting it working with out much effort on a windows server with the latest installer for Railo 4.2.

I have no problem spending the time to figure it out, but, if that effort takes more time in cost than to purchase a new copy of ACF, then it doesn't make sense to switch. I can just buy a new copy of acf, install, configure in mins and be on my way.

I'd love for this project to succeed. If the install and configure part could be easier for windows server folks, including multiple sites, then I think you'd get more people moving over, including myself. 

"Those that haven’t fall into a couple of categories, in my opinion: 

* Too corporate / too entrenched to consider migration to FOSS at all. 
* Too heavily reliant on ACF-specific features that they can’t move to Railo/Lucee (without a HUGE amount of effort). 

"

On Thursday, February 5, 2015 at 12:34:32 PM UTC-7, Sean Corfield wrote:

On Feb 5, 2015, at 10:59 AM, ADK <and...@leftbower.com> wrote:
> This is such a tricky subject.

Indeed.

> However, I imagine - and perhaps I am completely wrong - that Lucee hopes to (eventually anyways) grab members from the ACF community to "seed" its base.

I’m not so sure. At this point, the Railo user base is pretty good and those folks will, as you said, happily make the move to Lucee and follow on down that path. Railo’s been a solid, free open source option for five years now and many ACF shops have migrated. Those that haven’t fall into a couple of categories, in my opinion:

* Too corporate / too entrenched to consider migration to FOSS at all.
* Too heavily reliant on ACF-specific features that they can’t move to Railo/Lucee (without a HUGE amount of effort).

So, whilst I think there may continue to be a slow trickle of migrations from ACF to Lucee, I think that ship has sailed… That means Lucee needs to draw developers from a wider pool going forward, and that means disconnecting from the stigma that is "ColdFusion" in the eyes of most of the world (I mix with a lot of developers in other languages and the favorable responses to the word "ColdFusion" are extremely few and far between - even tho’ most of the negativity is based on pre-JVM-rewrite timeline knowledge!). Any one of us who has interacted with developers in other communities knows how much disdain there is for both "ColdFusion" (the language / product) and for CFML developers in general.

> I wonder how likely it is to be an impediment or pause for concern for those still in the ACF community to make the jump or even test the waters?

It will be an impediment, yes. But I think there’s far fewer likely to jump ship now than there were. And many ACF shops will be looking to jump to a non-CFML technology when they do jump, to "get away from ColdFusion". In many ways, Lucee would be more attractive to those shops if it was seen as a clean break, a successful FOSS language not dragged down by the baggage associated with "ColdFusion".

> I think the greater that cost of switching, the more likely I would strongly consider another more established language that would make my business life simpler - and frankly more stable - down the road.

At World Singles, we’re in the middle of that process: we have 90kloc in CFML (+ 5kloc tests), which is Railo-specific (we switched from ACF five years ago), and we have 25kloc Clojure (+ 8kloc tests) which is our targeted language. We picked Clojure because it is a modern language that provides immutable data by default (which is awesome for concurrency) and a lot of powerful abstractions. Clojure first appeared in 2007 and in terms of jobs is currently smaller than ColdFusion - but Clojure is growing and ColdFusion is shrinking. Clojure’s *community* is much larger and much more active than what’s left of the CFML *community*. So I wouldn’t call Clojure a "more established language" but there are plenty of options that can make a business’s life simply and more stable. We live in a polyglot world where more and more new languages keep appearing all the time. They are often modular and interoperate really well.

If you’re looking for a "more established language" then you’d want to be moving away from CFML altogether and not considering a migration to Railo or Lucee - which was kind of my point above: those folk won’t come our way, they’ll go to Java or .NET or PHP.

> What's the plan to garner that all-important critical mass to get this thing to the next level and beyond?

See my comment about new languages above. A language doesn’t need to be wildly popular to be successful, it just needs to be good enough to attract folks from other languages - by evolving into something that is better (for those folks) than other languages. CFML definitely is not that sort of language, but Lucee could grow to be.

[Stephan]

I completely agree. It seems there are two constituents to Railo users. We're in the same camp as you, we stuck with CF because of how simple and quick it is to code in it using tags, and the idea that Railo offered suddenly some hope that CFM might get out of Adobe's death grip.

Of course we are always looking at new technologies and Lucee could be a very exciting project we'd love to contribute to in some way, more likely by participating financially if we believe it makes sense for us long term, as we don't have the manpower and expertise to contribute on the coding side. But if tags and CFM baggage will end up removed then it's a whole other proposition. 

I am not discounting the active developers opinions here, it's great to see all the excitement and discussions, just giving one opinion from our perspective.

Thanks.

Stephan

[Sean Corfield]

On Feb 6, 2015, at 10:03 AM, Stephan <ste...@modelscorp.com> wrote:
> But if tags and CFM baggage will end up removed then it's a whole other proposition.

What’s being suggested is that CFC/CFM support continue to be in "Lucee" (the ecosystem) but maybe as an extension (that is fully supported and is easy to install). No one is actually proposing that handling of CFC/CFM files changes.

The point about "killing the CF baggage" is mostly to find a way to make Lucee appeal to a broader audience - i.e., non-CF developers - and to do so without the stigma of "being a CFML engine". Lucee is a scripting / templating system for the JVM (that just happens to also run your legacy CFML code).

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)

[Tanner Bachman]

Sean, I understand that Lucee will (for now) continue to be compatible with/support cfm/cfc, however I think for some of us would like some direct answers

1)  Is the longterm plan for Lucee to continue to update CFML tags to match their scripted counterparts?

2)  Is the longterm plan for Lucee to create new CFML tags to match some of the new scripting features that roll in?

What’s being suggested is that CFC/CFM support continue to be in "Lucee" (the ecosystem)  but maybe as an extension (that is fully supported and is easy to install). No one is actually proposing that handling of CFC/CFM files changes.

I think this is what has some people scared.  People from the Railo/ACF community are looking at Lucee as a new coldfusion engine, but having the coldfusion parts moved out of the core and into an extension indicates that Lucee will not be actively developing anything for the actual CFML language and instead Lucee will just run it as is.

 

The point about "killing the CF baggage" is mostly to find a way to make Lucee appeal to a broader audience - i.e., non-CF developers - and to do so without the stigma of "being a CFML engine". Lucee is a scripting / templating system for the JVM (that just happens to also run your legacy CFML code).

I think that what gave coldfusion in general bad stigma was the crappy job that Adobe did of marketing it and improving the language.  Maybe I'm completely ignorant with what I'm about to say, but why is a broader audience that important anyway?  I understand the devs give their time/get paid by a sponsoring company to build this stuff, but what's the end game...commercialize it...make money?

Thanks,

Tanner

[Andrew Penhorwood]

If the user base does not expand then it will shrink which means less paying positions.  Then it becomes a cycle: less jobs means less developer to choose from, means few companies using the tech and repeat.  You get the picture.  CF has been in the cycle for years now.  If nothing changes then CF will disappear.

I have spent the last 15 years coding in CF and I still use tags.  If we only continue down that road this will lead to a dead end.

Andrew Penhorwood

[Mark Drew]

Then surely it's time to also learn other skills and technologies no?

Mark Drew

--

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/7f893ad3-0992-4e0f-a94f-acc52b42d0ea%40googlegroups.com.

[Sean Corfield]

On Feb 6, 2015, at 10:39 AM, Tanner Bachman <tanner....@gmail.com> wrote:
> 1) Is the longterm plan for Lucee to continue to update CFML tags to match their scripted counterparts?
>
> 2) Is the longterm plan for Lucee to create new CFML tags to match some of the new scripting features that roll in?

I can’t speak to the "longterm plan for Lucee" since that’s up to the voting members of the association. What I would strongly prefer to see is no further development of CFML tags. Period.

> I think this is what has some people scared. People from the Railo/ACF community are looking at Lucee as a new coldfusion engine, but having the coldfusion parts moved out of the core and into an extension indicates that Lucee will not be actively developing anything for the actual CFML language and instead Lucee will just run it as is.

I think folks should look at Lucee as a way to escape the slow death spiral of ColdFusion, to be honest. Migrating to Lucee is going to be less painful than migrating to some other language. There’s going to be a time - and I think it will be sooner, rather than later - where ColdFusion simply ceases to exist.

> I think that what gave coldfusion in general bad stigma was the crappy job that Adobe did of marketing it and improving the language.

No, ColdFusion’s stigma is due to crappy code written by non-programmers and the ugliness of tag-based business logic which everyone outside the CFML community thinks makes it a "toy" language. ColdFusion had its bad reputation long before Adobe came along. Most people’s bad impression of ColdFusion was formed back in the early days before it was rewritten on top of the JVM. So that dates back to Allaire.

> Maybe I'm completely ignorant with what I'm about to say, but why is a broader audience that important anyway?

A language needs a growing community in order to survive. CFML’s community is shrinking. Even if everyone switched from ACF/Railo to Lucee, that would still be a shrinking community and the death spiral would continue. Lucee needs to be attractive to new (outside) developers. That’s why it needs to shed the stigma of ColdFusion - to encourage those folks to try it.

> I understand the devs give their time/get paid by a sponsoring company to build this stuff, but what's the end game...commercialize it...make money?

Lucee is an open source language project - potentially just like all the others out there that have gone on to have thriving communities and great business ecosystems grow up around them. You don’t need to commercialize a language to be successful. Indeed, there are almost no proprietary languages left anywhere.

[Tanner Bachman]

Sean, I appreciate the concise response.  This cleared up a lot of the questions that I had about the direction of Lucee.

Thanks,

Tanner

[Jim Pickering]

I'm with Adam; not a fan of wasting time. I can't even imagine what Lucee Server would be without its CFML engine. So many other languages that run on the JVM already. The modules Micha has proposed are great ideas. Make Lucee's core an efficient as possible. If I want ORM, I'll add it. 

But how about Lucee gets to a point where there are some installers ( that work on Windows, Mac, Linux ), and the current CFML language is cleaned up ( as proposed by Micha ) and documented well ( like ColdBox ) and in a year, assuming it takes that long to get there, then we talk about how to appeal to outside developers. Adobe isn't going to clean things up, and they've proven to be rather incompetent at fixing bugs in a timely manner. I for one, would love for Lucee to be the ColdFusion Server we've always wanted. Otherwise, the choice isn't which CFML server to use - it is which other server to switch to - NodeJS, Groovy, .NET, etc.  

[Sean Corfield]

On Feb 6, 2015, at 11:35 AM, Jim Pickering <jackofw...@gmail.com> wrote:
> Otherwise, the choice isn't which CFML server to use…

...it is which other server to switch to - Lucee, NodeJS, Groovy, .NET, etc.

[Michael Offner]

Hi Tanner 

Since I have started Railo, there was always the possibility to change the behavior of the language with help of settings.

Take as example the "scope cascading" setting, that was in Railo from beginning. Lucee is filled with settings like this. 

We now speak about having a file extension that just act with different rules on the engine. So a new tag will still be available in .cfm and .lucee.

It's not about to get rid of cfm, it's about the option to choose by extension instead of settings in admin. Sure the new extension will get rid of many old stuff. But that will not affect the old one!

In the beginning of the Railo project we fighted hard to keep up with ACF but that changed! We saw not a lot of new things coming from acf in the last years. When acf 10 was released, it took us a couple of days to adapt the new features. Most of the features where already available in Railo,  we just had to deal with the different dialect (script tags,member functions ...). 

In my opinion acf is making mostly money out of existing customers, so backward compatibility is extremely important for them.

So just add some new tags but do not change anything on the existing functionality that could it make difficult to update.

That is for sure a good approach to make money with not a lot of effort, maybe not for a long time but as long it works ...

That is for sure not the approach for Lucee, CFML is a great language and I love it. But it is for sure not wrong to clean the house as long you do not break backward compatibility.

See it like c and c++, you still can compile c code with a c++ compiler.

Micha

--

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/c25d3daa-5bc3-49be-ae30-fee4c333ee81%40googlegroups.com.

[Christian Meis]

I'm really happy discussions like this one is going on!
I've been doing ColdFusion for over 15 years now, having switched to Railo quite early after it was released.

Today we're still operating a bunch of smaller and bigger legay CFML applications.
Also some bigger new projects ar in their final stages including one launched today.

Things getting (too) quiet around Railo during the last months already gave me some headaches. Lucee looks like the best thing that could happen - thanks and congrats, Micha & co.!!

Regarding the future of Lucee (and implictly CFML, ColdFusion, ...):
Even being a fierce fighter for CFML for years there's no denying that ColdFusion as a language never gained a big developer community. And obviously is going down for years now - which is not solely Adobe's fault IMHO. One reason surely also is this kind of downwards spiral we all observe, I think.
One very obvious effect is that it's really hard to find freelancers/developers. Same thing goes for frameworks (sorry Sean - I love FW/1 and we use it for almost every current project; thanks for that!) etc.

So the question why we need a bigger user base asked above has at least one obvious answer for me: Only a bigger and growing community of developers can form the base for a healthy and living eco system around a language.

The options discussed above sound like a clever and excellent way to
1. open up the way to throw old crap overboard and fix things, giving a fresh breath to the language. NOT calling it ColdFusion / CFML might indeed help a lot - especially int the lines of attracting new developers. Let's get rid of the "Coldfusion stigma"...
2. define a clear and future-proof way to offer (not force) the best backwards compatibility to ColdFusion / Railo for all of us having to operate legacy code for the years to come. In my eyes this is a must have in order not loose the user base (or what's let of it anyway).

But even making Lucee attractive for "fresh" developers by modernizing the language (by dropping backwards compatibility), not naming it CFML or ColdFuson etc leaves the biggest part of the job still undone: Getting the word out and people to join the Lucee community. I think this will be the toughest part which needs a good plan and a lot of hands / mouths to spread the word.

Altogether: I'm much more confident in having a future doing what we did with Railo over the last years than I was a few weeks ago.
Looking forward to what is to come here..

Best regards,
Christian Meis

[Sean Corfield]

On Feb 6, 2015, at 12:07 PM, Michael Offner <mic...@lucee.org> wrote:
> See it like c and c++, you still can compile c code with a c++ compiler.

That’s not actually true. C++ is not a pure superset of C. There are some constructs that are valid in C but invalid in C++.

[mmm mmm]

I think cfml in itself is considered a scipting language.

had the same attitude when it came to cfscript, I would cringe when looking at code examples or tutorials that were in cfscript, or just move on to something that was shown in tags only.
So trust me when I tell you, as a hobbyist cfml' er, cfscript is much, much easier than it appears, especially with railo/lucee where many tags can be done in cfscript by dropping the <cf />

http://www.getrailo.org/index.cfm/whats-up/railo-40-released/features/tags-in-cfscript/

nowadays I cringe when I see cftags,
give yourself a week or two and I bet you change your mind about cfscript.

[Michael Offner]

Yeah, but who says that this will not be the  case with a .lucee, <cfoutput query...> will be valid in cfml but for sure not in .lucee.

Micha

--
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/6600E10D-902F-4633-B347-10C790BEC748%40corfield.org.

[Sean Herrala]

What about this?:

filename.lu - application logic (lucee app code/resource file available to any of the 3 file types below) - script

filename.lu.cee - haml/erb-like templating

filename.lu.cfc - railo/cf legacy component (could optionally extend filename.lu by convention) - tags or script

filename.lu.cfm - railo/cf legacy template (could optionally include filename.lu by convention) - tags or script

-S

[Adam Cameron]

On 7 February 2015 at 08:49, Michael Offner <mic...@lucee.org> wrote:

Yeah, but who says that this will not be the  case with a .lucee, <cfoutput query...> will be valid in cfml but for sure not in .lucee.

Thank god for that.

-- 

Adam 

[Adam Cameron]

On Thursday, 5 February 2015 21:58:35 UTC, Micha wrote:

ACF compatibility

ACF compatibility is still very important for Lucee in my opinion. today you can decide between being compatible and having it the right way with settings in the admin, that is not really handy!

But we you think about this:

Take as example a DVD player *, part of the DVD specification is that they must be able to play CDs, so every DVD player can also play CDs, means every DVD player is also a CD compatible.

Only the medium you use makes the difference, you don't have to change hundreds of setting in your DVD player to play a CD.

So what could be the medium for Lucee, that is very simple, the medium are templates (.cfc,.cfm).

What if Lucee acts different depending on the file extension.

So all templates with .cfm and .cfc extensions are still handled the old way, but files with the extension .lucee are handled in a modern way. this gives you the opportunity to still use your old code but you can extend it with new one and you have no confuguration nightmare anymore!

My position on this: http://blog.adamcameron.me/2015/02/lucee-does-its-future-include-cfml.html

-- 

Adam 

[Francesco Pepe]

Probably the extension name is not so important. I like the idea of a new scripting language that can also support old cfm/cfc syntax. However the point here is to make a more valuable site, that explain what lucee is and prompt some line of code.

From a marketing point of view the lucee.org site is not of much value, beacuse it's a simple five page site with poor informations. A good start will be add some basic info on syntax, some old "Hello world" example and a section with all functions. I know this is a huge task but we must provide more information to new developers. In the past we had railodocs.org that provided a lot of info, probably it's a good starting point. Of course most functions will be available on lucee so the porting should be simple. And the community could help to add some value in the comment, like on the php site.

So if we strip out all the tag based function, people will not think "Oh, another server that supports CFML tag", but will think about lucee as a new scripting language for the JVM. The fact that cfml tag are supported might be a benefit.

[Tanner Bachman]

Hi Micha,

I appreciate your post above...it's lays to rest some of my questions...thanks!

You mentioned (in a following post) that <cfoutput query...> wouldn't look like that in .lucee.  Could you post a little example of what the equivalent would look like in .lucee...the new version of that code?  I'm not looking for the whole turkey dinner here...just a taste.

Thanks,

Tanner Bachman

[Sean Herrala]

The exact extension may not be the first priority, but having an organized set of extensions that clearly denote each file's meaning can be, at least if we're talking about gaining traction and moving forward rather than continued battlefield triage.

"The fact that cfml tag are supported might be a benefit."

I don't know if it was on purpose or not, but you hit a key point.  The tags should be *supported*.  Supported, as in 'those old CFML tags will work with this engine'.  soapbox {  In my utopic vision, CFML -- the tags -- need to be based on what we have been calling cfscript and should now call lucee.  Tags shouldn't be crammed into pseudo-cfscript form; selected script functions should be exposed in secondary fashion as tags.  And 'cfscript' should be a subset/interface exposed by lucee.  'lucee' should be the name of the 'native' form of interfacing with the engine, which can be advertised as being backward-compatible / having legacy support of "ColdFusion", "CFML", and "cfscript".  .cfm, .cfml, and .cfc extensions should be supported and still function as they currently do.  For the tags, that's easy.  For script, I've seen mention of a versioning/naming parameter.  I don't even know if we need that...if it's script in <cfscript> tags, meaning it's a .cfm/.cfml/.cfc, it's legacy cfscript support.  If it's a script-only .cfc, it's legacy cfscript support.  If it's 'native' lucee, it's not wrapped in tags...it's in a file that's not .cfm/.cfml/.cfc, not inside tags.  It's either a script-only file with a new extension, or it's a (new) templating language file with a new extension. }

Then you'll have something that existing CF/Railo/BD people feel comfortable moving their applications to, with the benefit of having the rest of lucee's power available to them in the same engine should they choose to employ it...kinda the same way we've been able to interface with Java with various CF engines.

I proposed this in the 'outsider' thread, but I'm enamored with it, so if you're still reading, here goes:

whateverfile.lu - where pure lucee code goes.  think of it like a script-only CFC (the best kind!), but in lucee.

whateverfile.lu.cee - for output/templating engine language, like erb or haml.

whateverfile.lu.cfc - for legacy mode components in CFML and cfscript, but optionally extending whateverfile.lu via naming convention for access to its methods and attributes (optional)

whateverfile.lu.cfm/cfml - for legacy mode templates in CFML and cfscript, but optionally including whateverfile.lu via naming convention for access to its methods and attributes (optional)

whateverfile.cfm/.cfml/.cfc - pure legacy mode CFML and cfscript - so existing applications can be dropped in.

This would modernize but keep compatibility.  It needs the modernization to bring in and retain people with other language options, and it needs the compatibility to be a feasible alternative for people without other language options (whether because of circumstance or choice).  For the modernization to catch on, words/abbreviations/conventions like 'ColdFusion', 'CFML', '<cf' 'cfscript', and 'Railo' should be slotted in the 'legacy' group when mentioned, and 'lucee' and its modern conventions should be spoken about without referring to the legacy stuff unless legacy users are the target audience.

Ok Micha, good luck with all that! ;)

-Sean

[andreas]

I am also an old style classic cfml coder since the 90ies (like some others here), using really old cfml tags. My old CFML now works with Railo thanks to its classic support, but now I really don't know its future with Lucee anymore. It really looks to me that the focus is shifting towards a new language from now on, shifting away from CFML. By the way, I still use a lot of <cfoutput query>.

Even if it is being said:  CFML will mainly work and be supported with .cfm on Lucee, now I know the teams focus will be on a new type of LuceeScripting- or LuceeMarkupLanguage.... so on the long run I understand that I'll have to recode my stuff into some sort of LuceeML just to be on the safe side.

Do Lucee will attract new developers? Some for sure, but I will have to rethink switching to ACF or even BlueDragon over Lucee. Why not Lucee?

Just a little example is the history of Railos documentation: There was a documentation in Railo about Tags and Functions etc. But it was very rarelly updated, rarelly complete, and  poor in content. And it even was offline or not working for a period of time... Yeah... Most of the time I had to dig into ACFs documentation to look for functions and tag attributes for railo, I even looked in Fortas CFs books. And how will that be with Lucee? If Lucees docs will be like Railos, that will be a very tough start to attract new developers. ACF docs complemented Railos a lot and that gap will have to be filled.

Another example was the installation: I remember when I've tried to install Railo for the first time... it was 3.x on a WIN machine with IIS, and there wasn't any installers or docs about it. It was a real pain to make Railo work. Fortunately there was an outside blog post that someone of the railo community made and linked to. And even with Railo 4.x it is still a pain making it work on WIN and IIS.

From my side, I will rethink our decision, and may be switching back to ACF, or even switch to BlueDragon, because what I was looking for was classic CFML, not a new LUCEEML. And  that focus seemed to have changed on the old-Railo-new-Lucee-Development-Team now, and from my perspective the risk of cfml support being switched off in lucee in future with a sudden announcement  has risen a lot... and that was not what I was looking about when I've jumped on Railo.

The sudden anouncement that Railo stopped its development, and now is Lucee feels like a bomb thrown into what was giving me real confidence in the future of CFML.

--

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/CAFwR%2BKcL_zM33dBH9jWUzAs4btywZd9kxJzm4o%3D5T8ZW1LhL_A%40mail.gmail.com.

[Sean Corfield]

On Feb 7, 2015, at 11:38 AM, andreas <andreas...@gmail.com> wrote:
> From my side, I will rethink our decision, and may be switching back to ACF, or even switch to BlueDragon, because what I was looking for was classic CFML, not a new LUCEEML.

If you want guaranteed support for classic CFML then by all means pay your money to Adobe - and make sure you take out an enterprise support contract since that's the only "long term" support they offer - but I will ask: what do you plan to do when Adobe drop ColdFusion due to insufficient license revenue? As more and more companies - and developers - migrate away from ColdFusion, that day WILL come.

As for BlueDragon, they've long since given up any pretense of staying current with ACF or Railo and have repeatedly stated that compatibility is not a priority for them. Their development also seemed to have stalled, last time I looked, as Railo had recently.

The evolutionary potential offered by Lucee isn't going to be the right choice for some people or some companies...

[Michael Offner]

Coldfusion has a long history and you can see that in the syntax.

Cfoutput query is a perfect example, the first version of coldfusion was only about reading data from a datasource, so it had only a couple of tags, including cfquery and cfoutput*.

At that time the syntax has made sense, but then cfloop was indroduced, at that time they should define that cfoutput no longer makes loop, only cfloop should, but they didn't for backward compatibility...

That cfoutput does makes loop makes no sense at all, we have cfloop for that and what is even worse, cfloop and cfoutput works not exact the same way (see group attrs).

So cfoutput like it works today only makes sense if you know the history.

An other example is that arrays in acf are "passed by value", that is absolutely useless, the reason for this is*, in the beginning arrays was stored as string list (see all the list functions cf still has) and strings are handled by value. Even the technology behind it has completely changed, it still simulates that old behavior, only to be backward compatible. That is maybe also the reason arrays are starting with index 1.

This are 2 examples of many for stupidity to be backward compatible, but ther are also samples where cf acts strange for no reason.

CFM based custom tags are a good example for this, with CFM based custom tags allaire indroduced the possibility to have a local scope. So the variables scope inside a custom tag is local and to access the callers variables scope you call  "caller.whatever", so the variables scope acts like a stack. Then with cf5 macromedia indroduced script functions and at least I was expecting that they use of course the same concept for functions, but sadly this was not the case, they indroduced "var" and a complete different concept to handle local scopes, a hidden scope you can't touch directly and you can only set new variables before any working code and of course no stack of parent scopes. But of course Adobe then decided to make it even more complicated and add the "local" scope, my personal hell, I have written testcases for this scope and believe me that scope is completely strange. They did backward compatibility with that scope that the scope ended with no logic at all. Things like this:

var local=structNew();

local.whatever=1;

This does not produce the key local in the local scope, no this line is simply IGNORED!

Problem here is nobody was ever thinking about the bigger picture, there was no language design behind all this decision for sure, to be honest I think that the guys added script functions at macromedia was not even aware of the scope concept in custom tags.

When paramount does a new Star Trek movie they always have fans involved in the making, because they see logial failures in the story paramount people do not, macromedia and Adobe clearly didn't that. That is why community involvement is very important in cases like this.

So what should a .lucee do better in all this cases.

- ditch cfoutput-query, it is useless

- lucee is already passing arrays by ref, so no need to change here

- ditch cfm based custom tags, we have support for  component based custom tags

- ditch "var" ( I know people love var, I do it as well, but it makes now sense, the "local" scope is the one following the logic of the language)

- ditch all the bullshit the local scope does for backward compatibility.

- if we already on this topic, ditch the argument scope, we only need one local scope for functions.

- ditch the variables scope in components and make the this scope  private by default.

- ditch application.cfm of course.

- ditch dot notation upper case

- scope cascading to strict

- .... And lot more

What we should keep

I know may say Dutch query objects and tags in general, but I disagree on this, they are still handy in some situations.

Micha

P.s. All this popped into my mind while writing, so please don't see that this is curved into to stone...

* forgive me when this is not a 100% accurate, this is not first hand, I never used cf1.

--

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/fa1fa9df-cbc1-4fa6-a8b3-fe1889b1ca92%40googlegroups.com.

[Sean Corfield]

I agree with nearly everything you say except…

On Feb 7, 2015, at 12:28 PM, Michael Offner <mic...@lucee.org> wrote:
> - ditch "var" ( I know people love var, I do it as well, but it makes now sense, the "local" scope is the one following the logic of the language)

I think "local" scope is wrong - using "var" is much more like other languages. If you’re going to ditch something here, ditch "local" scope instead - and ditch a lot of the other scope nonsense that CFML provides to "help" lazy developers…

> - ditch all the bullshit the local scope does for backward compatibility.
> - if we already on this topic, ditch the argument scope, we only need one local scope for functions.
> - ditch the variables scope in components and make the this scope private by default.

…yes, yes, and yes...

> - scope cascading to strict

…and yes.

> I know may say Dutch query objects and tags in general, but I disagree on this, they are still handy in some situations.

I wish query objects were a lot more like arrays of structs - that would make a lot of things easier.

[Kai Koenig]

Hey all,

I agree with most, of the list, but the following:

> - ditch cfm based custom tags, we have support for component based custom tags

I understand the scoping issue that exist with tag-based custom tags, however I think they are extremely useful for views, if used appropriately (e.g. not as a replacement for business logic modularisation as everyone started to do in CF 3,4,5) Component-based custom tags always seemed a weird concept to me because they force me to abstract view creation/management into a cfc.

I use CFML based custom tags a lot for creating certain types of wrappers around CFML/HTML markup and I think they have a valid place in the language.

> - ditch "var" ( I know people love var, I do it as well, but it makes now sense, the "local" scope is the one following the logic of the language)

I side with Sean on this one, if ditching anything, ditch local. Var is at least a concept people are familiar with from other languages.

> What we should keep
> I know may say Dutch query objects and tags in general, but I disagree on this, they are still handy in some situations

Fully agreed. Query objects are the core piece of a lot of applications and from my point of view one of the draw cards of a language abstraction like CFML/Lucee is. Also the tags - don’t ditch them. If you were to drop everything that makes CFML just for the sake of being different, people would justifiably say: Why don’t we write JS or Java or … right away?

Cheers
Kai