Extension maintenance (was Suggestion: Upgrade on cfimage)

dev google-group-archive
1

Based on my experience with spreadsheets, I’m less enthusiastic about
the extension concept than I was.

Basically the spreadsheet functionality broke when Railo moved on and
the extension didn’t. No-one’s fault, it’s just what happened.

Plus it’s not DRY: it meant duplicating a bunch of code in each web context.

Having said that, I do like the idea of modularity in principle for
the greater good of a lean core. But I tend to prefer standalone
libraries available “as a service” to avoid the duplication. That’s
what I’ve ended up doing with spreadsheets:

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?

Cheers
Julian.On 3 February 2015 at 09:16, Michael Offner <@Michael_Offner> wrote:

In Lucee 5 images are already moved to an extension.
Like the search, orm and other stuff as well.

2

Based on my experience with spreadsheets, I’m less enthusiastic about
the extension concept than I was.

Basically the spreadsheet functionality broke when Railo moved on and
the extension didn’t. No-one’s fault, it’s just what happened.
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.

Plus it’s not DRY: it meant duplicating a bunch of code in each web context.
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 THAT extension.

Having said that, I do like the idea of modularity in principle for
the greater good of a lean core. But I tend to prefer standalone
libraries available “as a service” to avoid the duplication. That’s
what I’ve ended up doing with spreadsheets:
GitHub - cfsimplicity/spreadsheet-cfml: Standalone library for working with spreadsheets in CFML https://github.com/cfsimplicity/railo-spreadsheet

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

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 want?

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?

MD

3

…

Kept in sync how?

Presumably via tests to ensure they continue to work whenever a new
Lucee core is released. And updated docs.

This is exactly the solution, and one of the two main goals of
cfmlprojects, which are providing a place for CFML-related artifacts,
and providing a matrix of what works with what. We’d need an AI to
automatically update docs though (beyond API docs-- there’s a nice
colddoc script for that), and an AI that smart could probably write the
code for us, and where’s the fun in that?

The scripts I mentioned in the other thread make testing much easier,
and allow for automatically running the extension/framework/whathaveyou
tests against the latest version, without having the authors or the
Lucee engineers having to do anything.

The idea is that we can be running our “snapshot” versions of Lucee
against the plethora of existing CFML code that’s out there, and nip
many potential bugs in the butt-- it’s like free tests for Lucee, and
free tests for the packages… win win!

:DenOn 02/03/2015 03:34 AM, Julian Halliwell wrote:

On 3 February 2015 at 09:48, Mark Drew <@Mark_Drew> wrote:

4

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
first place.

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
THAT extension.

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)

Good point.

Not sure what you you want? But Lucee is providing all that you seem to
want?

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.

Cheers
Julian.On 3 February 2015 at 09:48, Mark Drew <@Mark_Drew> wrote: