I’ve been updating the documentation with details of unsupported tags and I personally think there are a few that the TAG should consider putting forward for adding support for to Lucee. Most of the unsupported tags are rubbish UI stuff, so that is no problem, however the few I think support should be added for are:
cfhtmltopdf
cfhtmltopdfitem
cfimapfilter
cfNTauthenticate
cfoauth
cfpdfform
cfpdfformparam
cfpdfsubform
cfspreadsheet
cfwebsocket
Now I must admit I have not personally used all these and someone else might say their is no point in X or Y because they are actually rubbish and not worth having, like the UI tags, hence posting here as an idea first.
There’s a spreadsheet extension that was used with Railo. It should probably be updated to work with Lucee but I don’t see that as core functionality – and even if it was, using a spreadsheet object with member functions would be the way to go there.
I’d say most of these should be objects / member functions if they’re added at all (and I’d be against all of them, to be honest: these are exactly the sort of things that should be community-maintained extensions, in my opinion).
@seancorfield I understand and completely agree with your point-of-view in a lot of ways, but these tend to be the tags that most people seem to ask about on the Google Group when looking to convert a project from ACF to Lucee, so adding them would more be for compatibility and easy of transition than anything else in my view.
I suppose you could say the same about the missing UI tags, like cftooltip, but then these are far easier to replace with something else like a jQuery plugin then something like the PDF or spreadsheet functions are.
Given that it’s relatively easy for the community to add cftags to Lucee, perhaps these would be good open source projects?
Part of my push back here is that some of these – particularly the PDF-related stuff – would be a huge amount of work and the folks who rely on them in ACF would want them to be 100% compatible with ACF in order to migrate their code… and I think that would be a terrible waste of LAS time and resources since they wouldn’t move the language forward at all.
I can see WebSockets being a worthwhile addition but, frankly, the ACF approach with the cftag is awful and, again, much like the dreadful UI tags, there are much better ways to implement this, with only minimal additions to the engine itself.
And I should also say that if folks are that heavily reliant on the cftags for PDF etc then they should continue to pay Adobe for that sort of stuff… Adobe being the PDF company after all (even tho’, of course, ACF’s PDF integration is mostly based on non-Adobe FOSS libraries anyway!).
I have been messing around with cfpdfform tax using iTest and had a bit of
a look at pdfbox, but did not get very far with it.
I am not sure about licensing of iText; but as I understand it, it can not
be bundled and redistributed. I think pdf box can.
Also, I have been hang back on releasing my work am was waiting to see how
extensions will work in Lucee 5 - I should follow that up again; would
appreciate any links to point me in the right direction.
Of your list, the only one that I’d see worthwhile implementing in the LAS core would be cfimapfilter. The main reason being that all the mail-related functionality is already in there anyway.
Everything PDF (form)-related should not be implemented by LAS. If people really want it, they need to step up and build extension - or they should pay LAS or a LAS member or some third party to build it for them.
cfoauth never should have been part of ACF in the first place, cfwebsocket is useful, but as @seancorfield said, the implementation is not great.
in fact would love to see a provider introduced as an extension also, and an OpenID Connect implementation, would love to see OpenID Connect implemented also in CF.
cfhtmltopdf probably is not needed explicitly as cfdocument serves much the same purpose. Upgrading cfdocument would probably be a wiser use of the time - then cfhtmltopdf could be easily implemented by calling cfdocument.
If open office / libre office integration were enabled then adding cfspreedsheet and other office related tags would be trivial. Maybe even a new object OfficeDocument could be created with assorted methods to extract text, graphics and other data directly from, or otherwise manipulate, assorted types of office documents.
dawesi:
in fact would love to see a provider introduced as an extension also,
and an OpenID Connect implementation, would love to see OpenID Connect
implemented also in CF.
There’s an open source library that implements OpenID reasonably well; although, getting it to work with specific implementations by this or that vendor can require some tweaking. If it were a built in tag, it would be harder to customize for specific cases. The library can be found at openid.riaforge.org.
There’s a big difference between OpenID and OpenID connect (oAuth2).
The differences are trivial in most cases and as for OpenID connect pretty much all implementations are the same.
As also with scribe-java oAuth2 library on GitHub, shows how a generic approach can be used for this kind of thing.
NodeJS has a toolkit called passport that proves this approach also : http://passportjs.org/ As for this not being useful in a languge toolkit as an core extension, you better tell the millions of downloaders of passport.
People can build as an extension whatever they want. PassportJS is not part of NodeJS, it’s a separate project - a node module.
Should oAuth or OpenID or whatever else be in ACF: no, it shouldn’t.
Should oAuth or OpenID or whatever else be in the Lucee core: no, it shouldn’t.
Should oAuth or OpenID or whatever else be as Lucee “core extension” (provided by LAS): no, it shouldn’t.
Should some third party or the community write an extension for oAuth or OpenID or whatever else auth support for Lucee: absolutely.
After speaking with yourself and various people this week at CFCamp about this I agree, just think we need to give the community guidance on what will be supported by LAS as a “core” extension and what needs to be community driven.
Obviously the community can come up with any extension they like but in terms of ACF compat extensions, like cfhtmltopdf or cfspreadsheet, I strongly believe LAS needs to provide this list.
Also, a central place for all these extensions to live, be searchable, easily installable, etc… is something else that either LAS needs to arrange and provide or task a community group to do. Before adding this thread I had no idea there was a already a Lucee cfspreadsheet extension available out there. Can’t say I had particularly looked, but if there was a central location I would be inclined to review it regularly for new additions and would probably have then come across it.
I agree, @andrew, LAS (through the TAG) needs to provide guidance re what the demarkation line(s) are where the community is expected to build certain features if they want it.
I think you should join the next TAG meeting (I’ve put a discussion re the PDF features on the agenda already).
If I recall correctly, Railo extensions had a vetting process before extensions were added to the official ‘store’
There was also talk of paid for community extensions.
I am guessing that will be on the Luce TAG agenda as well?
Whilst it can be ‘costly’ to vet all extensions, have ‘bad’ extensions in the store would reflect badly on Lucee even though they did not create it.
So maybe some sort of ‘status’ on extensions - like approved by Lucee.
Another option would be a voting / comments from the community (and number of downloads)
