I can’t remember how many participants I got in that survey, but I think it
was about 50-odd. So not statistically significant, really.
I’m not sure the best approach to the cross-compat, to be honest. On one
hand it’d be nice if a third party project worked on at least the currently
supported releases of “all” the engines (well: OK, I just mean Lucee and
CF. No-one should care about OpenBD). However at the same time I don’t
believe in coding to a lowest common denominator either. One thing I have
done in the past is to isolate code which leverages platform specific code
out into a clearly separate “DMZ” sort of area of my app, and written
platform-specific implementations of that code as needs must. “Needs must”
is the key here: I’d say if one was a member of the Lucee community and
writing an app / module / extension for use on Lucee, I’d code it for
Lucee. I’d try to be aware of areas that the CFML might diverge, and not
paint myself into any corners, but equally I might not bother writing a
ColdFusion-compat version. If someone comes along later and wants a
CF-compat version: they can write those bits.
As for CFML language compliance… there’s nothing to be compliant with.
Adobe never bothered releasing a spec (they are too incoherent in their
approach to the language for that, I think), so the best one can do is to
keep an eye on what they release when they release it. This is made worse
by the fact Adobe don’t really do that in return with (formerly) Railo, so
we have situations wherein Railo added a feature first, then Adobe has
added the same functionality but slightly differently. Jerks. This helps
TBH Railo had been the innovators in CFML for the coupla years leading up
to the fork, and I’d expect Lucee to continue this. Personally I think they
should not bother trying to hamstring themselves by staying ColdFusion
compatible unless it fits with their own agenda. If people need CF
compatibility that Lucee doesn’t provide, I wonder if there’ scope for
people to easily plug replacement function / method / tag implementations
in to emulate the diverent behaviour? Perhaps that’s something Lucee should
strive for, rather than to try to maintain compatibility themselves.
Especially if it’s at the expense of the direction they want to go.–
On 3 February 2015 at 19:16, Risto <@Risto> wrote:
It does. Thanks Adam. I also like the idea of package managers, extensions
and such. I also look forward to an even bigger community of extensions and
functionality which will probably happen because of this.
Thanks for the links as that was going to be my next question for you:) I
agree with you for the most part except a few of your modules that I think
should be core.
How many people participated in your Coldfusion Modularisation survey?
What are your thoughts on CFML compatibility between engines? (Maybe I
should join your blog and ask there instead)
I ask because this will be a common dilemma for people that actually
create,open source or sell CFML applications.
An example could be Slatwall or Mura. If you create a CFML application
shouldn’t it run on a CFML engine of similar versions? If a CFML app
doesn’t run on CFML server do you have a right to call it a CFML engine?
Are you fine with just saying the requirement is “Lucee only with these
extensions installed” even though it’s CFML but won’t run on other engines?
What about people that have invested in ACF and don’t want to change? Is
the answer to create another version of your app to run specifically on ACF
even though your app is CFML? Is the option to lose them as a customer
because they won’t switch engines?
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an
email to email@example.com.
To post to this group, send email to firstname.lastname@example.org.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.