Best practice for building wicket components
Uwe Schaefer 
Sunday, 16th of August 2009 at 08:57:16 AMi just sent this bit to the list
[while this is] valid with about any wicket component that uses a JS lib, i´m making the jQuery case here:
as it is a good practice to add functions (aka plugins) to the jQuery object, including the jQuery script more than once in a page is not only useless waste of bandwidth and lowers user experience, but does severel harm (last wins).
so adding your component to a page potentially breaks most of the nice other components that relied on plugins loaded before your (bundled) jQuery script.
duh!
there is only one way out, i think. as we all know that wicket is clever enough to sort out duplicate header contributors, we should make use of them!
so, what we could do instead of bundling jquery with every damn component whould be to just express the dependency to it.
i suggest to use wicketstuff-core/jslibraries in order to have a common ground to create these header contributors.so instead of
Java | copy | ?
you could simply put
Java | copy | ?
into your component, and make our lifes much easier.<advertisment>
a good side effect is to give the user of your component a chance to use a CDN instead of a bundled version to optimize loadtime
</advertisment>
what do you think? is there another way to accomplish that goal? is it too much of a drag to keep track of any JS lib release out there?
Hi Uwe,
your posting brought the jslib project to my attention – thanks.
Do we have an agreement among Wicketeers already whether this is the ultimate solution for javascript dependency management?
Your solution looks very sophisticated, although I’d rather not keep all js libraries bundled in one project – your Library enum clearly violates the open/closed principle.
And I’d never let my application reference js files from other servers (as a user I keep google and yahoo blocked via noScript) – at least you offer the LocalProvider.
Any plans to tidy up other projects in wicket-stuff? We now have contradictory solutions for all sorts of js (scriptaculous, prototype, …).
Sven
unfortunately, no. by the time at apachecon 08 i tried to get some direction, but unfortunately everyone shook their heads and said: we had this discussion before, noone would like to maintain such a thing…
kudos (as well as blame
) to Jeremy, who did the original stuff – i just did that CDN aspect on top.
actually, i think the dependency resolution could be improved, or (and this might be much of work and needs a bunch of thought) be delegated to maven.
i see your point – and i´d be glad to contribute to something more open. just currently i did not make up my mind of how to organize this. the point is, it has to be at a prominent place to attract component authors to actually use it. in fact i don´t even think it should be wicketstuff-core – from my pov it should be a top level wicket project.
i see. i´d prefer that for speed/parallelization, but if you´re in a slowly/eventually connected environment, don´t want to rely on someone else´s server or prefer to not talk to google due to privacy reasons, this is up to you as an application developer.
JSLib.setOverrideProviders(LocalProvider.DEFAULT)
however: consolidation after discussion as well as any architectural change is highly welcome. i just don´t know how to best get to an widely accepted agreement.
Looking at JQueryBehavior from wicketstuff jquery project, you can see that in the method renderHead, it checks if the script is already in the page header.
Is this another way of doing that.
Hi Eyal, thanks for the hint.
to me, this code looks rather unfortunate. did you ever try
Pattern ohDear = Pattern.compile(".*\\< .*script.*src=\".*jquery.*\\.js\"\\>.*", Pattern.DOTALL);
System.out.println(ohDear.matcher("<script src=\"http://somehost/myjquerytools.js\">").matches());
System.out.println(ohDear.matcher("<script src=\"http://somehost/i-like-jquery-and-mootools-too/myfunkyscript.js\">").matches());
both return true! –
that means, that whatever script i added there, that had jquery in its url will make your jquery not being added?
to me, this seems barely working, and i don´t think, that something like that tackles the problem from the right angle
++1
If we ever want to have a standard on how to include js libraries in Wicket, we should better have wicket-jslib instead of wicketstuff-jslib. The implementation issues are secondary.
I’d gladly request removal of my wicketstuff-prototype project if this helps matter.
Sven
Another thought:
Perhaps we could just have a skeleton project in wicket-core and library dependent projects in wicketstuff? E.g.
wicket-js
wicketstuff-prototype
wicketstuff-jquery
..
We could move most of jslib’s stable code into wicket-js and leave wicket core developers unattended from updates to the js libraries.