Fix tools that load JQuery so they work with neo, neo-inline, and morpheus
GENERAL
TESTING
GENERAL
TESTING
Description
As we transition from the neo portal to the morpheus portal, it becomes more important to coordinate and manage the version and loading order of jquery. There are three basic patterns that will happen depending on which portal is in control of the tool:
neo-with-frames : The portal and tool load their copies of jQuery independently
neo-jsr-168: The portal loads jQuery 1.9 plus compatibilty library and the tool markup assumes jQuery is already loaded. After the tool markup, the portal adds all of its plugins to jQuery.
neo-inline (new since r311707) : The portal runs the headscripts of the tool (which might load jQuery), the tool main markup runs (may also load jQuery). After the tool markup runs, the portal unloads any version of jQuery prior to 1.9. Then the portal checks for a jQuery and is there is no jQuery present, the portal loads 1.9 and fills it with all the needed plugins for the portal to function.
morpheus: The portal runs the headscripts of the tools (which might load jQuery), the portal runs the tool body (which might load jQuery) and then the portal checks to see if there is already a JQuery 1.9 in place, and if not loads a 1.9. If there is a pre-1.9 version of jQuery, it is unloaded by the portal before the portal loads 1.9.
This is a little tricky because Portlet tools (basic lti, web content) have always been in the backgroiund document assume that jQuery is already loaded and just use it blithely in their markup. So this means that when we move the jQuery load to the end of the portal markup as is done in morpheus (a best practice for page load speed as well) - markup for JSR-168 portlets that use jQuery will start breaking
There is still a place where things fall through the cracks when the tool is using a pre-1.9 jQuery. In the unloading of that version of the pre-1.9 jQuery we probably zap the document.ready() stuff the tool wants to happen. So we still need to get the tools to use 1.9 across the board to maintain our sanity.
There wil lbe a bunch of sub-JIRAs here. Fun stuff.
As of r311707 the logic for the neo portal's use of jQuery has changed and the description above is now updated. I include the old (now obsolete) way it worked before r311707 here:
neo-inline : the portal runs the headscripts of the tool (which might load jquery), the portal loads jquery 1.9 unloading an earlier version of jQuery if necessary, the tool main markup runs (some tools load jQuery at the front of their markup rather than in the head) and then the portal completes.
As we transition from the neo portal to the morpheus portal, it becomes more important to coordinate and manage the version and loading order of jquery. There are three basic patterns that will happen depending on which portal is in control of the tool:
neo-with-frames : The portal and tool load their copies of jQuery independently
neo-jsr-168: The portal loads jQuery 1.9 plus compatibilty library and the tool markup assumes jQuery is already loaded. After the tool markup, the portal adds all of its plugins to jQuery.
neo-inline (new since r311707) : The portal runs the headscripts of the tool (which might load jQuery), the tool main markup runs (may also load jQuery). After the tool markup runs, the portal unloads any version of jQuery prior to 1.9. Then the portal checks for a jQuery and is there is no jQuery present, the portal loads 1.9 and fills it with all the needed plugins for the portal to function.
morpheus: The portal runs the headscripts of the tools (which might load jQuery), the portal runs the tool body (which might load jQuery) and then the portal checks to see if there is already a JQuery 1.9 in place, and if not loads a 1.9. If there is a pre-1.9 version of jQuery, it is unloaded by the portal before the portal loads 1.9.
This is a little tricky because Portlet tools (basic lti, web content) have always been in the backgroiund document assume that jQuery is already loaded and just use it blithely in their markup. So this means that when we move the jQuery load to the end of the portal markup as is done in morpheus (a best practice for page load speed as well) - markup for JSR-168 portlets that use jQuery will start breaking
There is still a place where things fall through the cracks when the tool is using a pre-1.9 jQuery. In the unloading of that version of the pre-1.9 jQuery we probably zap the document.ready() stuff the tool wants to happen. So we still need to get the tools to use 1.9 across the board to maintain our sanity.
There wil lbe a bunch of sub-JIRAs here. Fun stuff.