If a sharedresourcetarget is created for a ResourceReference then the bind() is called on the ResourceReference so the Resource is created this has to be done because else the url can't be completely constructed.
But a Resource itself is just a simple constainer of data how the byte[] can be constructed for example all the fields of PackageResource is just a few strings: /** The path to the resource */ *private* *final* String absolutePath; /** The resource's *locale* */ *private* Locale locale; /** The path this resource was created with. */ *private* *final* String path; /** The scoping class, used for class loading and to determine the package. */ *private* *final* String scopeName; /** The resource's style */ *private* *final* String style; So you can get it just fine. And the resource should be there. johan On 11/7/07, Ate Douma <[EMAIL PROTECTED]> wrote: > > Johan Compagner wrote: > > 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. > Ok, sounds great, but what about lazy initialization? > Right now, WRCS.encode() only uses the resourceKey itself but doesn't > access the (possibly not yet registered) Resource. > If I look at SharedResourceRequestTarget.respond(RequestCycle), there is a > whole lot of plumbing going on to handle not yet registered Resources. > I guess I then need to duplicate/implement that same logic in WRCS then, > right? > Doable of course, but maybe that logic then better should be refactored in > a separate method so I can reuse it? > > Again, thanks for helping me out on this Johan! > > Regards, > > Ate > > > > > 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 > >>>> > >>>> > >> > > > >
