Outsider perspective

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 .

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.

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.

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
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! :wink:

-Sean

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.

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

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

I agree on much of what you’re saying Micha. However like Sean pointed
out I too would keep var, and ditch local. I’d also keep the arguments
scope. Why would you not want that?

First it is time consuming and confusing with no real benefit.

Micha

+1 keep var, ditch local.

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.

+111111111111111111

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

YES YES YES

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.

You mentioned (in a following post) that 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.

Yes please kill <cfoutput group=""> what a mess that tag makes.

Andrew Penhorwood