WEll, that allows projects to get rid of stuff that it doesn’t need right?
If less and less people are using something , it can atrophy and die nicely
rather than loitering and taking up space in the sever.
I take your point, but it seems to me the spreadsheet extension wasn’t
dying “nicely”. Coming from ACF where that functionality just worked,
I expected the same as promised by the Railo Docs. What I found was a
bit of a mess. That’s what I mean by “maintenance”. Not just the code
but the docs as well, so it’s clear what’s core and what’s up to you
to sort out.
I’m still puzzled that SpreadSheetX() was never supported “natively”
by Railo yet was, given that the ease of server -> client
data output was what attracted me and so many others to CFML in the
Then the extension needs to be re-designed so it’s server wide not just
context wide. This is not a problem with extensions, it’s a problem with
I didn’t realise extensions could be server-wide. Good to understand, thanks.
Will there be a way of ensuring “core extensions” (if that isn’t an
oxymoron) - I mean those like ORM, Search, images - are kept in sync
as Lucee develops?
Kept in sync how?
Presumably via tests to ensure they continue to work whenever a new
Lucee core is released. And updated docs.
Different projects might have their own lifespans. For
example Database drivers are coming OUT of the core and becoming extensions
that are installed in the core as they will upgrade at their own pace
So “core extension” isn’t an oxymoron. Sounds good.
This is great for spreadsheets for example as those are integrations with
external systems that have their own lifecycle (Office 360 for example)
Not sure what you you want? But Lucee is providing all that you seem to
Ideally I would have wanted Lucee to support spreadsheets out of the
box just like ACF or failing that have an extension that worked in the
latest release. (BTW, It wasn’t just the extension mechanism that
broke, there were also issues with the null support added in 4.x.)
But I understand that’s not everyone’s priority and the point of
modularity is to allow folks to take responsibility for their own
priorities. It just needs to be clear what’s core and supported across
releases and where you’re on your own.
I would say that extensions (in the Lucee config) be something like:
This would mean that when you start a Lucee server it would then auto update
the spreadsheet extension to 1.0.0, then upgrade it and deploy it to a
specific web context.
What do you think?
Fine, as long as the extension keeps working with new Lucee releases.
Or is removed if interest falls off (and the removal is clearly
documented). Or there’s a clear warning that the extension is 3rd
party and not Lucee’s responsibility.
Julian.On 3 February 2015 at 09:48, Mark Drew <@Mark_Drew> wrote: