For portlet support, shared resource urls are served in a specific way (through 
the servlet api, not the portlet api).
But because these might be component level resources, a portlet id is also encoded in their url to protect against potential url overlap when multiple instances of the same portlet are displayed on the same portal page.

So far so good, but when these resources are really static (or cacheable) the same resource might be linked/loaded multiple times for nothing, like with the standard wicket JavascriptReference for wicket-ajax.js etc.

I've been looking for a way to *safely* determine if a 
ISharedResourceRequestTarget is actually targetting such a static Resource.
But even a ResourceReference can be extended to override the newResource() 
method and then all bets are off I'm afraid, isn't it?

Is there something I'm missing here or is Wicket simply too "wicked" in that I never can safely "merge" multiple resource requests like for a proper PortletHeaderResponse implementation???

Of course, for the core Wicket framework I can pre identify the most common/used static ResourceReferences like wicket-ajax.js, but I'd rather implement a generic solution for this instead of having to fall back to a hard coded lookup table...

Regards,

Ate

Reply via email to