How to determine if a Resource truly is static or cacheable?

[Ate Douma <at...@douma.nu>]

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

Re: How to determine if a Resource truly is static or cacheable?

[Johan Compagner <jc...@gmail.com>]

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 <at...@douma.nu> 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 <at...@douma.nu> 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 <at...@douma.nu> 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 <at...@douma.nu> 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
> >>>>>>
> >>>>>>
> >>
> >
>
>

Re: How to determine if a Resource truly is static or cacheable?

[Ate Douma <at...@douma.nu>]

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 <at...@douma.nu> 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 <at...@douma.nu> 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 <at...@douma.nu> 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
>>>>>>
>>>>>>
>>
> 

Re: How to determine if a Resource truly is static or cacheable?

[Johan Compagner <jc...@gmail.com>]

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 <at...@douma.nu> 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 <at...@douma.nu> 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 <at...@douma.nu> 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
> >>>>
> >>>>
> >>
> >
>
>

Re: How to determine if a Resource truly is static or cacheable?

[Ate Douma <at...@douma.nu>]

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 <at...@douma.nu> 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 <at...@douma.nu> 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
>>>>
>>>>
>>
> 

Re: How to determine if a Resource truly is static or cacheable?

[Johan Compagner <jc...@gmail.com>]

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 <at...@douma.nu> 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 <at...@douma.nu> 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
> >>
> >>
> >
>
>

Re: How to determine if a Resource truly is static or cacheable?

[Ate Douma <at...@douma.nu>]

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 <at...@douma.nu> 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
>>
>>
> 

Re: How to determine if a Resource truly is static or cacheable?

[Johan Compagner <jc...@gmail.com>]

Ate,

So you want to know if more then one url is the same Resource?

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?
after a resource reference is binded you just can get the Resource
(getResource()) method and that one
can tell you if it is cachable.

johan



On 11/6/07, Ate Douma <at...@douma.nu> 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
>
>