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
