Consider upgrading to Wicket 1.5. There are a lot of improvements
about that - see
org.apache.wicket.request.resource.caching.IResourceCachingStrategy.


On Tue, Jul 12, 2011 at 2:52 AM, Todd Nine <t...@spidertracks.com> wrote:
> Hi guys,
>  We've just finished our first wicket app using wicket 1.4.17.
>
> Everything works well, but we get a lot of resource requests for resource
> that rarely change.  I've read a few blogs on the subject, and this one is
> the closest to what I want to do, however it's not quite right.
>
>
> http://techblog.molindo.at/2008/08/wicket-interface-speed-up-caching-resources-forever.html
>
>
> This explicitly calls the code to wrap the resource, I don't want our
> developers to have to do this.  We have several templates that use wicket's
> autolinking feature, so I would like them to be able to use it as well.
>
>
> Here's what I currently have.
>
>
> A Custom resource loader that is simply a wrapper and delegates to
> WebApplicationPath for resource loading.
>
> Once the resource is loaded, if it ends in .js, .css, or .png an SHA sum is
> calculated on the file contents.    I then want to create a mount path in
> the format of <original file>_sha256.<original extension>
>
>
> I also then need to wrap the created resource with an expiration time of now
> + 1 month.  This way, our images can be cached completely on the client.  In
> the event the file changes, the sha256 sum will change, and hence so will
> the file name's url, forcing the client to re-download the new content.
>
> Any thoughts on how I can do this?  I'd prefer to only do it once the first
> time the resource is loaded, but I can only seem to override the
> ResourceFinder using the above logic,  which does not give me access to the
> created ResourceReference itself with wicket expiration and other
> properties.
>
> I thought about using a listener, but this requires the mapping to happen
> with each request, which seems very inefficient since it will only change at
> deploy time.
>
> Any help would be greatly appreciated, I'm at a bit of a loss on this one.
>
> Thanks,
> Todd
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to