ok you can get the resource from the sharedResources with the key the that the ISharedResourceRequestTarget.getResourceKey() gives you And then you have the Resource object where you can ask if it is cachable or not. You can just ask for the resource from the SharedResources it will be in there at the time it comes to the WRCS.encode() But that doesn't mean that the byte[] behind the Resource have to be loaded that is done when the Stream is asked for. The Resource itself is just a shallow container.
johan On 11/6/07, Ate Douma <[EMAIL PROTECTED]> wrote: > > 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 > >> > >> > > > >
