Thanks for helping out Johan!
Comments and more specific questions inline below.
Johan Compagner wrote:
Ate,
So you want to know if more then one url is the same Resource?
No :)
I see I didn't properly describe my situation, although your second guess below
comes close :)
What do you have to start with? The url?
Because an url maps directly to a Resource (not an ResourceReference)
And that Resource tells you if it is cacheable.
Or do you mean you need to know when you build the page? And you have
ResourceReferences everywhere?
When rendering a "page", especially when processing the HeaderResponse, I need to know if a WebRequestCodingStrategy.encode(RequestCycle,
ISharedResourceRequestTarget) concerns a static/stateless/cacheable Resource or a (potentially) dynamic Resource which might be different for each and every
request...
As I tried to explain: I'm trying to find a safe algorithm to prevent multiple links to the the same application scoped/static/cacheable resource for portal
pages which include more than one instance of a wicket portlet (potentially even the same).
Right now, all the ISharedResource urls generated for a portlet gets the portlet unique id encoded in it, just to make sure dynamic resources links are
targeting the correct portlet instance.
But for certain resources, like the JavascriptResourceReference for "wicket-ajax.js" this isn't needed of course and this unique portlet id should not be
encoded in the url.
after a resource reference is binded you just can get the Resource
(getResource()) method and that one
can tell you if it is cachable.
I'd rather not "get" the Resource at this stage: I guess a long list of mp3 Resources
might not be the best example to "get" just for this purpose, right?
Furthermore, if I understood it correctly, ResourceReferences can still be used for creating "dynamic" resources, e.g. resources which might deliver a different
result for each request. For (Application scope) cacheable dynamic resources, even if just short lived, I would be ok with it, as long as the proper lifetime is
set on the response headers. I just need to know how I can be sure of the referenced resourrce isn't going to be dynamic after all.
Regards,
Ate
johan
On 11/6/07, Ate Douma <[EMAIL PROTECTED]> wrote:
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
