But if they are not targetted with a ResourceReference then they won't get that url
Yes i know that the SharedResourceRequestTarget also does the lazy registering but he has to do that because urls can be out there, generated previous server start. So yes a resource doesn't have to be there yet because the url was generated by a previous server instance. johan On 11/7/07, Ate Douma <[EMAIL PROTECTED]> wrote: > > Johan Compagner wrote: > > 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. > Cool, so that covers the ResourceReference. > > But not all cacheable Resources are targetted using a ResourceReference. > If I look at SharedResourceRequestTarget.respond(RequestCycle) there is > additional handling for lazy registering a shared PackageResource. > My question is: do I need to do the same when SharedResources.get( > ISharedResourceRequestTarget.getResourceKey()) == null? > > Regards, > > Ate > > > > > 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 > >>>>>> > >>>>>> > >> > > > >
