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