CODEWITHSUNDEEP
javacachingwicketcache-control
George Armhold
George Armhold

Reputation: 31074

Wicket: proper caching of CSS resources

We just moved from GWT to Wicket 1.4. While very happy in general, we still have a bit of a learning curve for certain things that GWT made simple. One of those things is resource caching.

How can I configure our app's resources (CSS in particular) so that they aren't downloaded with each page request?

We're seeing some flickering on certain page elements because the styles aren't being applied immediately, presumably because the style sheets are being downloaded each time. I traced through our logs and indeed, I'm seeing requests for the stylesheets on nearly every page request.

We're referencing the CSS directly in our HTML files like so:

    <link href="/css/ag.screen.css" rel="stylesheet" type="text/css">
    <link href="/css/ag.base.css" rel="stylesheet" type="text/css">

I'm not sure it matters, but all our pages are mounted with IndexedParamUrlCodingStrategy, as we need them to be both bookmarkable and have particular URL structures.

I tried implementing what Stefan Fußenegger suggests in his blog (i.e. referencing the CSS via a header contribution rather than in the HTML directly), but that didn't seem to help (I tried checking the headers with "curl -I").

Is there a standard way of setting Cache-Control or Expiration headers for resources in Wicket 1.4? Is it worth moving to Wicket 1.5 for this? (I'm hesitant to do so because it's not officially released yet).

Edit: I just gave 1.5 another try, but the lack of documentation is really a roadblock at this point. IndexedParamUrlCodingStrategy and related classes are are gone, and the migration guide has almost nothing to say about it.

Edit 2: I just noticed something very odd- when I arrive at one of my pages either by directly entering the URL, or by clicking a BookmarkablePageLink, the resources referenced on that page (CSS, images, etc) seem to get cached (I see no requests for them in my logs). But if I arrive at the same page via a form submission, all of the resources are downloaded again. Why does a form submission cause resources referenced on the page to be re-downloaded?

Upvotes: 0

Views: 1938

Answers (4)

Peter
Peter

Reputation: 1

You get fingerprints on resources out-of-the-box. The strategy for creating cache fingerprints can be modified or altered quite easily.

There's more information at the Wicket wiki page about how resource caching works in 1.5.

Upvotes: 0

martin-g
martin-g

Reputation: 17533

To manage the headers of non-Wicket resources you can use plain Servlet Filter that is listed before WicketFilter in your web.xml. Just check the request Url and if the file extension is .css/.js/... then just set the cache headers in the response. About **UrlCodingStrategies in Wicket 1.5 read http://wicketinaction.com/2011/07/wicket-1-5-request-mapper/ and the next two articles. I hope it will be more clear for you.

Upvotes: 0

Cedric Gatay
Cedric Gatay

Reputation: 1583

I had the same need as you, the need to cache resource client side the more I can.

For now I am stuck under 1.4.x and I found a solution that suits me. I use the great library Stefan Fußenegger wrote and he made available here. Implementation is pretty straightforward, I use a StaticResourceVersionProvider in production mode. I had no issues so far (rock solid for my clients for now).

Don't hesitate if you need details on how I use this solution.

Upvotes: 1

martin-g
martin-g

Reputation: 17533

Since you are moving to Wicket I'd recommend you to use 1.5RC4.2. Looking at the bug reports about this RC I think the next one may be 1.5.0Final. About caching see this wiki page: https://cwiki.apache.org/WICKET/caching-in-wicket-15.html. It is about 1.5 but it also says what are the differences against 1.4.

Upvotes: 1

Related Questions