Mako template should output JS/CSS in order of plugin dependency
Closed this issue · 11 comments
Does girder order the pluginJs list correctly? If so, wouldn't we just have to remove the special case if plugin != 'minerva'?
@jbeezley girder/girder#1186 fixes that I believe, @mgrauer?
minerva does not use plugin.min.js, so some kind of directory globing may be necessary to ensure all js files are included - of course those minerva js files need to be included in their own order, so actually the problem is a little more complex.
I can't recall if there was a particular reason that we don't use the standard plugin.min.js mechanism here. If not, we could simplify many of the local building/testing complications by doing so.
That mako template is looking a bit scraggly.
I'm hopeful we could clean it up a bit, following Girder's recent renaming. Girder also sorts plugin JS in dependency order since very recent, as @danlamanna said. We'd get both of these on Girder v1.4.2. We could always peg to a Girder master SHA to get it sooner, but I have a feeling 1.4.2 is near.
minerva.min.js was chosen at the time Minerva was started because the Girder Gruntfile looks in web_client for plugin client side resources and then serves them in Girder (we have the Girder Admin page stuff related to the Minerva Girder plugin in web_client). That would be a big additional set of resources to serve if you didn't have Minerva enabled, if we included all of the Minerva webapp in plugin.min.js. More importantly, if we included the rest of the Minerva client side code (the web app stuff that lives in web_external), Girder wouldn't serve Minerva's 3rd party dependencies, so that would break and cause errors in Girder.
I haven't actually tried the following, but here's a proposal for the revised mako template
libs.min.js => girder.ext.min.js
geo.ext.min.js => minerva.ext.min.js [0]
jquery.gridster.js => /dev/null
jquery-ui.min.js => minerva.ext.min.js [1]
geo.min.js => minerva.ext.min.js [2]
app.min.js => girder.app.min.js
papaparse.min.js => minerva.ext.min.js [3]
jsonpath.min.js => minerva.ext.min.js [4]
minerva.min.js => minerva.app.min.js
main.min.js => minerva.main.min.js
then order is
girder.ext.min.js
girder.app.min.js
minerva.ext.min.js
for plugin in pluginJs:
if plugin != minerva
plugin.min.js
else
minerva.app.min.js
minerva.main.min.js
jquery.gridster.js => /dev/null
QFT
That would be a big additional set of resources to serve if you didn't have Minerva enabled.
Correct me if I'm wrong, but I don't think any of the plugin's resources are included by girder if it is not enabled.
Also,
Girder wouldn't serve Minerva's 3rd party dependencies, so that would break and cause errors in Girder.
Does the girder interface need Minerva's 3rd party deps? If so, I think a better solution would be to create another plugin that contains just those resources (as is mentioned here).
Ah, you are correct, they are only served if the plugin is enabled. Girder grabs the list of enabled plugins from its settings collection, then serves their JS in dependency order.
The Girder interface I don't think needs those 3rd party deps. It just does whatever geonames stuff you set up long ago.
What I was trying to say is, if Minerva's plugin.min.js included the stuff in web_external, which depends on Minerva's 3rd party deps, since those 3rd party deps aren't served by Girder, when Minerva was enabled in Girder, that would break.
I'm fine with changing this around, just trying to recall the reason for this separate minerva.min.js .
I see what you mean. In general, my preference would be to work with Girder's infrastructure and improve it where necessary.