Based upon a cursory glance at one of Charlie Arehart's blogs, I wanted to know what version of Ext.js shipped with CF11 (based upon a description in the blog, I tracked down the location of the files for Ext.js and got my answer.) CF11 (released April 2014) shipped with Ext.js v3.1 (v3.0 released July 2009).
The current version of Ext.js is (I believe) 6.1.x. I cannot currently find which version of Ext.js ships with CF2018, but I suspect it isn't Ext.js v6.1.x.
It's not just Ext.js, either. As I understand it, Solr (Lucene) is also versions behind.
Which begs the question: Why is ACF behind in supporting library versions? (TSIA)
^ _ ^
This is a big thing we discussed back in alpha. I personally think CF supporting such things as cfwindow, cfchart, whatever is doomed to fail compared to third party projects that could wrap the same libraries and stay up to date. Adopting any of those tags is a bad idea, but that is my opinion, and was not a popular one. Solr is a different beast since it would be under licensing. I'd imagine it is hard to stay up to date, but I'd imagine they should/could.
I avoid things like CFFORM (and all related child tags) and CFCHART, but CFWINDOW I kind of like. Almost never use it, though.
And I suppose that one could install a separate Lucene/Solr server, but then there's the cost - paying for something that the CF license already covered just to have an up-to-date version.
And I agree. They should stay up-to-date.
^ _ ^
Solr is free and open-source. And you can actually install Solr and point CF to it, as far as I can tell. You don't have to be using CF's version. But again, if you're simply using the built-in CF functionality to interact with it, you're not going to get much out of upgrading it.
Dave Watts, Fig Leaf Software
Wolf, I know you'll want Adobe's answer, but let me offer what I can. (And while I was writing this, I see Nick and you have already added a couple more comments.)
First, according to the version number shown in the comments at the top of the ext.js file found in CF2016's AND CF2018's \cfusion\wwwroot\cf_scripts\scripts\ajax\ext\source\core\core folder, the version for both is indeed just 3.1.0. So it would seem it is unchanged.
The next question is whether CF is really "using" this. Since it's buried in that folder (which does come with CF), we can assume that it does. But before someone would say "so this old crappy stuff is underlying CF's various old crappy UI elements", well, no, that's not so, it seems.
You can see mention of it in blogs about the installer then, and more specifically in the bottom of the deprecated features page (ColdFusion Help | Deprecated Features ).
Now granted, this refers to the YUI (and spry) libraries as having been removed (and that could be added back, in a different \cf_scripts\scripts\ajax\yui folder (so a sibling to but not the same as the ext folder referred to above).
So the point there is that Adobe is already deprecating and declaring "not supported" the YUI library which they say underlies the various CFML JS-based UI tags, discussed on that page.
So finally, we come back to your question about ext. Well, it seems that that is NOT used by these UI tags, and as such Adobe didn't seem to feel the need to remove that ext library when removing these tags (and the YUI library). So the next question would be "why is ext still there". Does anyone know? I've never dug in to find out what may refer back to them (and since CF is not open source, we can't easily "know"). We can hope Adobe may tell us.
But then, even if somehow technically CF no longer "uses" that library, it's a reasonable point to argue that it should be removed, so that it does not remain there as something that someone people COULD try to use (whether as coders or somehow as bad guys). That said, just because these JS libraries WERE there in that scripts folder did not mean that CFers should presume that they COULD use them directly. I never really studies the licensing docs in those files to see if that was prohibited.
And I doubt really that the ext libraries could be used "for ill" against CF itself, but still your point remains: if Adobe DOES use the library, why is it not updated? And if they do NOT, then why does it remain there, not updated?
Hope that's helpful regarding your question, but again clearly you need to hear from Adobe. Just offering this to you or other readers in the meantime.
It's always good to read your responses. I never know what I'm going to learn! And thank you for the details that you provide.
I guess when I started this thread that I was sub-consciously kind of hoping that someone from Adobe would see it and respond with some kind of explanation (or excuse). At least to let Adobe know that at least one user has noticed the discrepancy. But it was also to let other users know, in case they did not already know, how ACF is lagging behind with support libraries.
In my honest opinion, Allaire created a wonderful thing when it published CF. And I think that MacroMedia furthered that wonderful thing and advanced it most adequately. And I firmly believe that Adobe is slowly destroying ACF (I will not say that Adobe is destroying ColdFusion - Lucee is helping to preserve what CF is and can be.) I sincerely wish that Adobe had not subsumed MM, or that MM had sold CF to another company before being swallowed by Adobe.
I have witnessed a complete lack of drive to improve (or FIX) aspects of ACF, despite what any ACF Blog entry states to the contrary. And I believe that Adobe slowly, quietly removing libraries like YUI and Ext instead of moving to newer versions is further evidence that Adobe is truly trying to destroy ACF, even though many coders have complained quite loudly about their effectiveness.
But I digress. I'm not the one in control; merely one who (currently) uses the product.
Thank you, again, for your insight.
^ _ ^
I'd suggest that removing these libraries and focusing efforts on the core problems CF is meant to solve was actually a huge win for CF developers, and shows the commitment to making a great language.
I think it's perfectly natural to expect CF to be behind in supporting third-party libraries. Every one that's used in CF has to be tested, and those libraries can change pretty frequently. And if you're solely using them through CF's exposed functionality, why bother with upgrading them?
Dave Watts, Fig Leaf Software
It's a very old blog post but CF once came with a version of CKEditor that allowed for certain attacks: https://www.petefreitag.com/item/704.cfm
I'd say it's important to know what Adobe delivers and keep your setup up to date.
I agree, but I think rich-text editors are very likely to have security vulnerabilities, and would want to expose them to access via untrusted networks regardless. Most of the third-party libraries included by CF don't really fall into this category, and I think it's more important for Adobe to make sure they ship a working product than to make sure they're all using the latest versions. If that means that I'm using an older version of Solr out of the box, I can live with that.
Dave Watts, Fig Leaf Software
There was this thread some times back: ExtJS 4.1 Licence Adobe ColdFusion 2016
The original poster never explains where he got version 4 from.
Sencha - the company behind ExtJS - has changed their licensing model repeatedly over the years. Adobe - I assume - never licensed a version after a later model and therefore still comes with a 3.x release.