Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
see http://www.nabble.com/Multiple-JS-libraray-inclusions-tf4285036.html
No doubt this is a complicated issue, so maybe we should start small and see what shakes out. Currently, the only real conflict is wicket-datetime and wicket-contrib-yui loading duplicate or incompatible versions from different locations, resulting in multiple script refs in a page.
A lot of good ideas were tossed around in the above thread, and the only one I really didn't like is the shared jar (eg, wicket-yui). I realize that it solves the problem, but i would like to see more developer control. Also, say there is no one maintaining wicket-contrib-yui. Then it will become the responsibility of a core dev to upgrade the wicket-stuff project. An upgrade to the yui libs will also require a much higher degree of coordination between stuff and core then there has been historically. I think ultimately this will be a source of frustration. It will also hinder the stuff project from being more experimental, which is one of its missions. Also, there might be libs that wicket can not host because of license incompatibilities.
I liked igor's idea of having a JavascriptLibraryReference with a common id, and Eelco's idea of having some sort of registry. The Application class can have a JavascriptLibrarySettings object that will maintain a mapping of common id (regex) to class which will be the root for loading the library. The JavascriptLibraryReference can access this when generating the url. This leaves the problem of how to resolve priority when both wicket-datetime and wicket-contrib-yui want to register different roots for the same common id. This will probably require some kind of PriorityResolverStrategy with a sensible default, like defering to the wicket-core project.
Hopefully these mumblings will inspire some comments postive and negative. If the idea is given any kind of nod, I will try to find some time to work up a patch.