Outsider perspective

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

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.

Thanks!

~Brad

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"™ 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

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.

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.

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"™ 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?

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

Dave

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

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.

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).

Sean Corfield

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

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

Bear in mind that LuceeServlet DOESNT EXIST yet.

MD

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

If I ruled, […]

People would revolt.

Well, people are revolting already. Both meanings.

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