Add a jQuery helper to the the MODX core?

Quote from: BobRay at Jul 12, 2015, 03:18 PM

How about just adding a jquery_source System Setting? That way all extras on a site would have at least the option of using the same version without MODX having to parse the source to do a version check, and developers can choose their own method of loading jQuery.

We could do that but it seems weird that MODX would have a native jQuery setting when the core and default Manager don't use jQuery at all.

Quote from: BobRay at Jul 12, 2015, 03:18 PM

I've read that window.jQuery throws an undefined error in some versions of IE, but I've never tested it. If that's true, (typeof jQuery != 'undefined') might be a better choice.

The syntax is derived from HTML5 Boilerplate 4 and I believe it should support at least back to IE 6.

It's not pretty, but using regClientHTMLBlock does solve the problem of loading multiple versions or instances of jQuery. This technique of feature detection followed by document.write, could also be used to conditionally load any other common plugin or framework.

Based on the responses of OpenGeek and others (here and on Twitter), I think this issue is "pining for the fjords (i.e. dead). OpenGeek, btw, thinks that no MODX extra should be dependent on jQuery or any other library.

Using regClientHTMLBlock is an interesting solution, but I doubt if we could get enough extra developers to use it to make much of a difference. Having a jquery_source System Setting in the core might have worked, since it also adds some convenience, but clearly it's not going to happen because there's a feeling that it would encourage the use of jQuery.

My personal view is that people *will* be using jQuery and we might as well make it easy for them to use it in a more efficient way, but I don't feel strongly about it.

A developer can always have his own system settings, or even a ClientConfig setting if he wants.

Right, but the issue I was addressing was the problem of multiple extra developers each loading a different version of jQuery.

I'd be curious to know just how many versions of jQuery are in my browser cache right now.

at least, a sentence on 'how to integrate jQuery' in a section for 'best practices for developers' at rtfm ,might be usefull.

A manager extra (i.e.CMPs and custom TVs) should use jQuery noConflict inside to bypass any jQuery version issues. Frontend extras should have a setting to disable register jQuery and other package library files. [ed. note: Jako last edited this post 11 years, 3 months ago.]

I feel the next MODX major release should not be dependent on one "manager" and the API should not be dependent on any libraries such as ExtJS. Personally, I don't agree that Extra developers should be told what front end libraries to use and not use. That's not creative freedom.

Quote from: BobRay at Jul 15, 2015, 03:17 PM

OpenGeek, btw, thinks that no MODX extra should be dependent on jQuery or any other library.

I'm all for VanillaJS but are we not considering ExtJS a library or is that the one exception? Redactor.js is dependent on jQuery so Redactor for MODX is too. There's absolutely no way around that. Jan's Markdown Editor rightfully uses Ace. ContentBlocks uses some stuff. Lots of Extras use libraries and with good reason.

VanillaJS would help solve so many problems and help put creative freedom into the manager itself. Within the manager(s) use whatever libraries you want. AngularJS, React, VanillaJS, whatever. This would allow MODX to take the clean "VanillaJS" stance without limiting or defining what Extra developers have in their toolkit. With the API traced back to VanillaJS, Extras should be compatible within any manager theme whereas currently many are dependent on MODXExt. The next API could suggest or offer some sort of way to prevent libraries loading more than once along with VanillaJS code samples of how to communicate with the REST API. These code samples, being standard, could of course be translate to any other library.

Quote from: Jako at Jul 16, 2015, 06:46 AM

A manager extra (i.e.CMPs and custom TVs) should use jQuery noConflict inside to bypass any jQuery version issues. Frontend extras should have a setting to disable register jQuery and other package library files.

Agreed. Unfortunately it hasn't been as easy as it sounds to implement. For example, with Redactor we use jQuery.noConflict() to free up the $ for other libraries. Problem I'm running into is if jQuery was already loaded by another plugin, but that plugin uses noConflict also. In these cases we are having to load jQuery again just before we use it. In other words, I haven't even been able to get the ugly regClientHTMLBlock trick I suggested to work correctly yet
[ed. note: dinocorn last edited this post 11 years, 3 months ago.]

Each extra needs another jQuery noConflict closure i.e. as in Image+ https://github.com/Jako/ImagePlus/commit/8b70d9bb61cec130efb56ba66c6b9adc486cfb85

The problem with VanillaJS is that you have to do all your own tests for legacy browser compatibility, unless you're willing to have the site fail to work (often in ugly ways) for the many visitors still using older browser versions.

@BobRay - indeed, in a few years of researching the advantages/disadvantages of JQuery (in particular) over vanilla JS the main advantage I've found is that it does all the relevant compatibility checks and provides necessary fallbacks for you. You can often do a given task in a very similar number of lines of code, but the checks and fallbacks can double that in many cases. For one or two simple Javascript effects that only need one or two function checks, vanilla may be a bit smaller and faster, but for a seriously Javascript-heavy page, the "bloat" of the JQuery (or similar) library becomes well worth the overhead costs.