Too many MooTools.js calls in differing locations

Hi; It seems as though every developer has their own favorite place to locate MooTools.js (and other common .js files) so that I see no less than six different versions of MooTools.js, in six different folder locations and some times different versions are called by different snippets at the same time (i.e. QuickEdit is from /assets/modules/quick_edit/javascript/mootools.js and AjaxSearch is from ’manager/media/script/mootools/mootools.js’;).
It’s a mess.
This could be eliminated if everyone would use /assets/js for common/generic .js files. It makes good sense to have .js files that are particular to a specific snippet or module reside in the folder of that name for ease of updating, but common use .js files should go in /assets/js.
What do you think?
Hal D

One of the important features about MODx is the ability to allow web developers to use whatever libraries they want to produce the front-end web site they are trying to achieve. As a MODx component developer, that means you have to choose a library, even a specific version of that library, to code against and produce an add-on. When new versions of these libraries come out, you have to make some choices depending on your use of the libraries that may be common across the components you’ve chosen to deploy. Do I upgrade components on page xx where component a and b that currently use javascript library x.1? Are there upgrades to both components that make use of the new x.2 version of the library? If a but not b has an upgrade, can I handle modifying component b to use x.2, or should I wait until both utilize the same common library version?

There are no easy answers in this regard, and I do not see a way to automate mitigation of these issues within the framework, at least not at this point. There are simply too many potential ways to include js libraries via MODx, and so ultimately, it’s up to the site administrator to decide if and when to upgrade a site based on these factors in conjunction with their knowledge of the site.

That said, once 0.9.6 comes out, all of the add-ons distributed with the core should be using the common 1.0 version of mootools in the manager/media/script/mootools directory. The 0.9.6 RC1 version currently available does not reflect this yet.

Jason; The problem with free-style .js are the conflicts that occur when different snippets call differing versions of the same javascript. I understand what you are saying vis-a-vis not wanting to use the latest version of a library, because it might break some code. The problem is only going to get worse over time unless developers make a commitment to maintain compatibility with up-to-date libraries. MODx requiring taht developers uses
Thanks for the thoughts,
HalD

Quote from: OpenGeek at Mar 18, 2007, 01:09 PM

That said, once 0.9.6 comes out, all of the add-ons distributed with the core should be using the common 1.0 version of mootools in the manager/media/script/mootools directory. The 0.9.6 RC1 version currently available does not reflect this yet.

Does that mean that they have a copy of the library in /assets folder or will there be /manager... link in the page source? I would suggest to have the scripts under /assets somewhere and not in /manager..

I’ll second Doze on that. I would think that only javascript related to the operation of MODx should be in Manager/media/scripts/ and all other javascript in assets/js/ - including QuickEdit js .
Cheers,
HalD

I totally agree that the js libraries used to render the front-end pages should reside in the appropriate assets directory, and not in the manager. This kind of dependency is problematic any way you slice it, but part of the problem is that the template variable widgets used to present output on the front-end, depend on these scripts in the manager. I have a vision of how to solve it, but it will require some of the changes coming in 0.9.7 to do it properly.

Opengeek
One thing the MODx core developers can do is MANDATE where add-on developers will put things like javascript files. Doing your own thing is ok some places, but MODx has a right and duty to say where developers will put files. Remember how chaotic Window$ became in versions up to win98 because M$ allowed developers to duplicate .dlls and put them all over the place, and so on. It got to where you didn’t know which .dll was doing what. It’s getting that way in MODx with .js files.
Thanks for considering,
HalD