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.
ā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.
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.
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.
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.
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"ā¢ 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 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"ā¢ 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.
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.
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"ā¢ 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 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.
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?
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.
Mark, unless Iām misunderstanding shouldnāt the second āservlet-nameā in
the āservlet-mappingā section be āLuceeServletā and not āCFMLServletā?
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)
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).
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.
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).
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.
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
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