Changes from 2.0 to 2.1 (Wicket 1.3.x):

• Annotation-based Mounting of Resources
• [WMR-7] Failure to load resources if this library is provided in a parent classloader
• [WMR-9] Make it possible to define some sort of order in the way files are included in the overall file
• [WMR-10] wicketstuff-merged-resources does not compile; missing jetty plugin artifact
• and a few minor bug fixes and performance improvements: See full FishEye Activity report

(Note: [WMR-12] and [WMR-14] already went into 2.2-SNAPSHOT)

Changes for 3.0 (Wicket 1.4.x):

• Annotation-based Mounting of Resources
• [WMR-6] Compatibility to wicket 1.4
• [WMR-7] Failure to load resources if this library is provided in a parent classloader
• [WMR-9] Make it possible to define some sort of order in the way files are included in the overall file
• [WMR-10] wicketstuff-merged-resources does not compile; missing jetty plugin artifact
• [WMR-12] Allow CSS media to be specified in ResourceMount, and honored by build()
• [WMR-14] Error detection for adding CSS and JavaScript resources to ResourceMount
• and a few minor bug fixes and performance improvements: See full FishEye Activity report

Downloads:

• wicketstuff-merged-resources 2.1: Jar Sources
• wicketstuff-merged-resources 3.0: Jar Sources

@JsContribution
@CssContribution(media = "print")
@ResourceContribution(value = "accept.png", path = "/img/accept.png")
public class PanelOne extends Panel {
 
    public PanelOne(String id) {
        super(id);
        // ...
    }
}

The example above mounts and merges PanelOne.js (default is simple name of class + “.js”) into all.js (another default) and PanelOne-print.css into print.css which will be included with scope print. Additionally, accept.png will be mounted to /img/accept.png (as path starts with a ‘/’) which makes it easy to use from css files.

There’s not much left for this to work. All it takes is a single method call in your Application’s init code:

ResourceMount.mountAnnotatedPackageResources("/files", "com.example.components", this, mount);

In this example, all components in package com.example.components (including sub-packages) will be scanned for annotations. If not defined otherwise, all resources will be merged into single files for JS (/files/all.js) and all CSS media types (/files/all.css, /files/screen.css, /files/print.css, …).

As an added benefit, you’ll get all the other features of wicketstuff-merged-resources:

• merging of multiple files into one for less HTTP requests
• adding of versions to resource paths for aggressive caching
• pre-processing of resources (e.g. replacing colors in CSS files)
• optionally uploading them to Amazon Cloudfront (well, at least you can expect this feature soon – we are using it already)

So you will speed up rendering of your pages while simplifying and reducing your code (there’s no need to merge, mount or add HeaderContributors manually anymore)!

Further instructions are available on wicketstfuff-merged-resources’ page on Wicket Stuff Wiki.

(This new feature is mainly based on the idea and code of Jörn Zaefferer – Tanks!)

The main class now is ResourceMount which replaces the deprecated ResourceMountHelper (already removed in trunk version). Mounting is now much simpler. Just see this example:

ResourceMount mount = new ResourceMount()
.setResourceVersionProvider(new RevisionVersionProvider())
.setPath("/style/all.css")
.addResourceSpecsMatchingSuffix(PanelOne.class, ComponentB.class, MyForm.class)
.mount(this);

Note that you still use the resources as you are used to, e.g.

add(HeaderContributor.forCss(MyForm.class, "MyForm.css"));
add(HeaderContributor.forJavaScript(MyForm.class, "MyForm.js"));

This example simply mounts PanelOne.css, ComponentB.css and MyForm.css into a single file at /style/all.css (the suffix “.css” is determined from the path – “/style/all.js” would mount all “.js” files). Additionally, the RevisionVersionProvider is used to determine which version to append (you may implement your own IResourceVersionProvider that best fits your environment). For example, the merged file may be mounted at /style/all-42.css (while still being available at /style/all.css through a permanent redirect).

While ResourceMount tries to autodetect most properties of the merged resource (e.g. style, locale, compression) it comes with a ton of customization options. For instance, it’s possible to use a custom IRequestTargetUrlCodingStrategy. Doesn’t that sound interesting to you? Well, we used this option to upload all resources to Amazon Simple Storage Service/CloudFront in order to transparently leverage Amazon’s CDN by simply mounting them in our applications (Isn’t that awesome? Stay tuned for another blog post. Donating might speed things up though).

Jörn Zaefferer suggested adding wicketstuff-annotations-like mounting of (merged) resources using annotations, which will hopefully be added in a later version. In the meantime, I may provide Jörn’s solution for those interested (Jörn, you don’t mind, do you?) – just leave a message.

Additional feature include CSS compression using Yahoo’s YUI Compressor and resource preprocessing. The later is particularly interesting, as you might implement things like replacing colors in CSS files or add internationalization from .properties files to JS files – just implement the IResourcePreProcessor interface (or use StringResourcePreProcessor if your only dealing with Strings).

I think I’ve mentioned the most important features now. Just see wicketstuff-merged-resources in WicketStuff’s Wiki for more (and possibly up-to-date) documentation. If you have any questions, don’t hesitate to post a comment! It you’re grateful, don’t hesitate to donate!

public final Object writeReplace() throws ObjectStreamException {
  if (isTransient(this)) {
    return this;
  } else {
    return new ReplaceHolder(getClass(), getId());
  }
}

The ReplaceHolder – isn’t it a lovely name? – is responsible for replacing itself with the persistent object we didn’t want to serialize before:

public static final class ReplaceHolder implements Serializable {
 
  private static final long serialVersionUID = 1L;
 
  private final String _entityName;
  private final Serializable _id;
 
  public ReplaceHolder(final Class entity, final Serializable id) {
    _entityName = entity.getName();
    _id = id;
  }
 
  public Serializable getId() {
    return _id;
  }
 
  @SuppressWarnings("unchecked")
  public Class getEntity() throws ClassNotFoundException {
    return (Class) Class.forName(_entityName);
  }
 
  public final Object readResolve() throws ObjectStreamException {
    try {
      return loadEntity(getEntity(), getId());
    } catch (final ClassNotFoundException e) {
      throw new InvalidClassException(_entityName, e.getClass().getSimpleName() + ": " + e.getMessage());
    }
  }
}

And that’s it. Well, not completely, but see the attached .java file for details.

There is only one thing Wicket developers have to be aware of. Objects aren’t serialized between requests – don’t confuse it with model detaching. If I remember correctly, there is always one page kept detached but un-serialized. So if one would like to use the serialization, one has to make sure, that the objects are already serialized as soon as the models are detached. For this purpose, I implemented a special Model, that serializes its object on detach:

public void detach() {
  if (_object != null) {
    try {
      final ByteArrayOutputStream bs = new ByteArrayOutputStream();
      new ObjectOutputStream(bs).writeObject(_object);
      _bytes = bs.toByteArray();
      _object = null;
    } catch (final IOException e) {
      throw new WicketRuntimeException(e);
    }
  }
}

You might say that this feels like a hack – at least that’s what I think of it But it works perfectly, especially for complex forms where you add persistent objects to transient ones. Furthermore, you make sure that you’ll never serialize a huge persistent object graph into your Wicket session, which definetely is a Bad Thing ™.

EDIT: This blogger is thirsty! Please buy him a beer:

If it comes to new posts, We have a lot of ideas but not enough time to elaborate them all. Some ideas are:

• An easy to use Wicket component for advanced Google Analytics (Outgoing link tracking, search tracking, AJAX events tracking, user defined variables, …)
• Faster batch indexing for Compass
• Managing Subversion user access privileges with Drupal – and probably how to move to Wordpress afterwards
• Wicket Blueprint integration
• How to apply some on-site SEO with a little help of Wicket
• Unleashing the full power of Wicket with Cometd using wicketstuff-dojo-1.1 and loose coupling of components.

If you particulary like one of the ideas post a wish in the comments – and think about enforcing your wish with a donation:

Pages often depend on entities – e.g. a Customer or a product and as those pages should be bookmarkable as well, there has to be a unique way to tell the page which entity to use. As entities either don’t have unique names or one wants to avoid having an (database) index over the name column, the index-ID is for most applications the way to go. As it’s usually undesireable to expose the database ID of an entity in the URL, it has to be encoded and decoded somehow to get from myshop.com/customer/12 to myshop.com/customer/ea34cff … or something like that.

Using a custom Url-mounting strategy makes it a breeze:

public abstract class IndexedIdEncryptingUrlCodingStrategy extends LowercaseOnlyIndexedUrlEncodingStrategy {
 
private final int[] _encryptedParams;
// serverroot is e.g. http://www.mypage.com - required for 301 redirects in baseclass
public IndexedIdEncryptingUrlCodingStrategy(final String mountPath, final String serverRoot, final Class bookmarkablePageClass, final int... encryptedParmas) {
super(mountPath, serverRoot, bookmarkablePageClass);
_encryptedParams = encryptedParmas;
}
 
public IndexedIdEncryptingUrlCodingStrategy(final String mountPath, final String serverRoot, final Class bookmarkablePageClass, final String pageMapName, final int... encryptedParmas) {
super(mountPath, serverRoot, bookmarkablePageClass);
_encryptedParams = encryptedParmas;
}
 
@SuppressWarnings("unchecked")
@Override
protected void appendParameters(final AppendingStringBuffer url, final Map params) {
for (final int index : _encryptedParams) {
final String indexStr = Integer.toString(index);
final Object val = params.get(indexStr);
if (val != null && val instanceof Integer) {
params.put(indexStr, encodeId((Integer) val));
}
}
super.appendParameters(url, params);
}
 
@Override
protected ValueMap onDecodeParameters(final String urlFragment, final ValueMap urlParameters) {
 
for (final int index : _encryptedParams) {
final String indexStr = Integer.toString(index);
final Object val = urlParameters.get(indexStr);
if (val != null && val instanceof String) {
urlParameters.put(indexStr, decodeId((String) val));
}
}
 
return urlParameters;
}
 
protected int[] getEncryptedParams() {
return _encryptedParams;
}
 
protected abstract String encodeId(Integer val);
 
protected abstract Integer decodeId(String val);
 
}

This class’s baseclass is used for SEO only: it just checks if there are only lowercase letters in the URL and does a 301 redirect to the lowercase variant of the page if not.
Why lowercase only: The first of the Ten SEO Commandments (if there was such a thing) is: “Thou shalt only have one URL per page” – and for bots http://www.myshop.com/customer/Foobar and http://www.myshop.com/customer/fOoBar are two different URLs – which is a bad thing as far as duplicate content is concerned. Well, it could also be uppercase only or camelcase only – but lowercase makes it easier to read for humans and is also easier to implement than camelcase.

Then just mount the page like that:

mount(new IndexedIdEncryptingUrlCodingStrategy("/customer", "http://www.mypage.com", HomePage.class, "id"));

and construct the page params like that:

final PageParameters params = new PageParameters();
params.add("id", myEntity.getId());
 
// add e.g. a link
add(new BookmarkablePageLink("link", HomePage.class, params));

Download the files:
IndexedIdEncryptingUrlCodingStrategy.java
LowercaseOnlyIndexedUrlEncodingStrategy.java

In my next post I’ll get a bit more into Wicket & SEO: Show a more SEO way to encode URLs, how to deal with the JSESSIONID and how to apply the code shown today on a Page. Stay tuned – and consider subscribing

PS: If “thou convet my code”: the code is public domain, feel free to do whatever you like to do with it. If you have any suggestions or implement enhancements, just post them in the comments.

Normally, you do this by either putting everything on one panel or by passing a reference of the list panel to the form panel.

public SearchBoxPanel(String id, SearchResultPanel results) {
_results = results;
// snip
}
 
public void onSubmit(AjaxRequestTarget target) {
_results.setQuery(getQuery()); // or use the same model ;)
target.add(_results);
}

Now, we would like to add a nice and shiny “Did you mean” panel to our search page. So what can we do? We could add another reference to the search box panel by refactoring it. However, nobody likes refactoring existing components over and over again. One would rather like to write components flexible enough from the beginning. Here, the observer pattern – or loose coupling – comes in handy, my hard-rocking amigos:

public SearchPage() {
_search = new SearchBoxPanel("search");
_didYouMean = new DidYouMeanPanel("didYouMean");
_results = new SearchResultsPanel("results");
_search.addObserver(_didYouMean);
_search.addObserver(_results);
// snip
}
 
// SearchBoxPanel class
public void addObserver(IAjaxObserver observer) {
_observers.add(observer);
}
 
public void onSubmit(AjaxRequestTarget target) {
// snip
for (IAjaxObserver observer : _observers) {
observer.notifyAjaxUpdate(target);
}
}

But let’s take this a step further. Wouldn’t it be cool, if simply adding a new component to the page would be sufficient? Yeah, just adding it, no magic or voodoo involved. It really can be that easy! One just has to realize that all components are already connected through the page. Dispatching events to all children of a page can therefore be as simple as visiting all components of a page:

public abstract class AjaxUpdateEvent implements IClusterable {
private final Component _source;
private final AjaxRequestTarget _target;
 
public AjaxUpdateEvent(final Component source,
final AjaxRequestTarget target) {
_source = source;
_target = target;
}
 
public Component getSource(){ return _source; }
public AjaxRequestTarget getTarget() { return _target; }
 
public final void fire() {
getSource().getPage().visitChildren(new NotifyVisitor(this));
}
 
public static interface IAjaxUpdateListener extends IClusterable {
public void notifyAjaxUpdate(final AjaxUpdateEvent event);
}
 
private static final class NotifyVisitor implements IVisitor {
private final AjaxUpdateEvent _event;
 
public NotifyVisitor(final AjaxUpdateEvent event) {
_event = event;
}
 
public Object component(final Component component) {
if (component instanceof IAjaxUpdateListener) {
((IAjaxUpdateListener) component).notifyAjaxUpdate(_event);
}
return IVisitor.CONTINUE_TRAVERSAL;
}
}
}

Now, all you have to do in your SearchBoxPanel is this:

public void onSubmit(AjaxRequestTarget target) {
// snip
new SearchEvent(this, target).fire();
}

Your “Did you mean” panel could look like this:

public class DidYouMeanPanel extends Panel implements IAjaxUpdateListeners {
 
public void notifyAjaxUpdateListeners(AjaxUpdateEvent event) {
if (event instanceof SearchEvent) {
setModel(event.getSource().getModel());
event.getTarget().addComponent(this);
}
}
 
}

Simple, isn’t it? I’m currently playing around with some ideas on using this event mechanism together with wicketstuff-push (or rather the upcoming release of wicketstuff-dojo-1.1 with integrated wicketstuff-push powers – Should be out this or next week. I’m working on it, I swear!). This could be a really powerful and easy to use programming model for cometd-based applications.

Now download the code and enjoy updating loosely coupled Wicket components

Now that I spent some time on configuring client-side caching and resource versioning for aggressive caching, I am going to finalize this series with an article on merging of resources and some code that you can easily use right away to speed-up your own applications in minutes.

Merging several (e.g JS) files into a single, monolithic file is an efficient way of reducing the number of HTTP requests. In theory it’s quite simple: just copy and paste all files together and you’re done. But no, sorry, it’s not that easy. If you do so, you’ll run in a bunch of new problems:

• Resources won’t live next to their owning components, therefore
• Existing HeaderContributor.forCss(…) and .forJs(..) will stop working
• Any component will come with that big file, which makes reusing components less enjoyable.

These are the cons of merging resources – but the cons you’ll smile at after reading this tutorial. (If you have other points to add, feel free to use the comment form at the bottom)

It is possible to merge resources without changing the resources themselves and without changing any code of the components they belong to. All it takes is some mount-magic, that will look like this:

protected void init() {
mountMergedSharedResource("style", "all.css",
new Class[] {PanelOne.class, ComponentB.class, MyForm.class},
new String[] {"PanelOne.css", "ComponentB.css", "MyForm.css" });
}

This code will mount a resource at /style/all-[version].css (e.g. /css/all-1234.css) that has all the contents that would normally be at /resources/my.package.PanelOne/PanelOne.css, /resources/another.package.ComponentB/ComponentB.css” and /resources/yes.another.package.MyForm/MyForm.css.

Of course, the usual way of referencing resources from a component will keep working:

add(HeaderContributor.forCss(PanelOne.class, "PanelOne.css"));
add(HeaderContributor.forCss(ComponentB.class, "ComponentB.css"));
add(HeaderContributor.forCss(MyForm.class, "MyForm.css"));

Each header contributor will lead to this style sheet reference (of course only one, regardless of the number of added header contributors for those resources):

<link rel="stylesheet" type="text/css" href="css/all-1234.css" />

But what happens behind the scenes? I implemented a MergedResourceStream that aggregates the contents of any number of ResourceStreams into a normal Java String, i.e. the contents of all resources will be kept in memory. I implemented four different types of merged resources

• MergedResource
  any file type, will be served uncompressed
• CompressedMergedResource
  any file type, will be served compressed
• CompressedMergedJsResource
  JavaScript files, will be served compressed and stripped using Wicket’s built in JavascriptStripper.stripCommentsAndWhitespace(..)
• CompressedMergedCssResource
  CSS files, will be served compressed and stripped using YUI Compressor.

Okay, now here is the code for all my loyal – aren’t you? – readers: merged-resources.tar.gz

UPDATE: commited my code to wicketstuff, get it from SVN: wicketstuff-merged-resources and wicketstuff-merged-resources-examples.

I created two projects. One is called merged-resources and can be added to your project using maven. The second one is called merged-resources-test with two simple test cases and a sample application. To add merged-resources to your project simply add the following to your list of dependencies:

<dependency>
<groupid>at.molindo.wicket</groupid>
<artifactid>merged-resources</artifactid>
<version>1.3.4-SNAPSHOT</version>
</dependency>

(Unfortunately, there’s no Maven repository available at the moment, so you’ll have to build it yourself: `mvn install`)

Here is how to use it:

protected void init() {
IResourceVersionProvider p = new RevisionVersionProvider();
ResourceMountHelper h = new ResourceMountHelper(this, p);
 
h.mountMergedSharedResource("style", "all.css", true,
new Class[] {PanelOne.class, ComponentB.class, MyForm.class},
new String[] {"PanelOne.css", "ComponentB.css", "MyForm.css" });
 
h.mountMergedSharedResource("script", "all.js", true,
new Class[] {PanelOne.class, ComponentB.class, MyForm.class},
new String[] {"PanelOne.js", "ComponentB.js", "MyForm.js" });
}

By the way, MergedResourceStream uses Wicket’s ModificationWatcher, so any changes you make at development time will be immediately available without restarting your application.

Have fun and thanks for reading!

UPDATE: There is an ongoing discussion on my “Wicket Interface Speed-Up” on Wicket’s mailing list.

In my last post, I explained how to change (i.e. increase) the time a client should cache resources like JavaScript and CSS files served by a Wicket application. In this post, I’ll show you how to cache resources for a year. Caching for a year is close enough to forever and a recommendation by W3C:

“To mark a response as “never expires,” an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future.”

Allowing users to cache resources forever is an efficient way to reduce the number of requests, server load and interface loading time (with a “primed cache”). However, aggressive caching comes a long with a major problem: cached versions of resources might be outdated but still valid for a long time. YSlow’s suggestion:

“Keep in mind, if you use a far future Expires header you have to change the component’s filename whenever the component changes. At Yahoo! we often make this step part of the build process: a version number is embedded in the component’s filename, for example, yahoo_2.0.6.js.”

While I don’t like the idea to do such stuff at build time, I do back up the idea of using version numbers. I prefer determining the version number of resources at application startup (i.e. before mounting them).

This leads to another question though: How to get a version for each resource? Using your application’s version (if you have one) might be appropriate but depends on how often you deploy new versions, as a new version will make all cached (i.e. even unchanged) resources obsolete.

As we are deploying new builds quite regularly, I am using SVN revision numbers as resource versions (e.g. all-1234.css instead of all.css). If you now reckon that the revision number isn’t available at startup, you’re certainly right … well, normally it isn’t. In order to retrieve the revision number at runtime, I introduced a simple header to all my JS and CSS files. This header (a single line) looks like this:

/* $Revision$ */

After adding this header to your files, enable the SVN keyword “Revision” (see “svn:keywords” section). After commiting, SVN will expand the above line to

/* $Revision: 1234 $ */

This line can now easily be parsed with a simple regular expression at startup;

Note: You can also configure SVN to automatically enable SVN keywords (see “Automatic Property Setting” seciton).

Now that we have a version for our resources, the Application init code looks like this:

protected void init()
{
  // snip
  mountVersionedResource("/css/", CssScope.class, "all.css");
}
 
protected ResourceReference mountVersionedResource(String prefix,
  Class scope, String path)
{
  String unversionedPath = prefix + path;
  String versionedPath = prefix + getVersionedPath(scope, path);
 
  ResourceReference ref = getResourceRef(scope, path);
  mountSharedResource(versionedPath, ref.getSharedResourceKey());
 
  // redirect all.css to all-1234.css, just to be safe
  if (!unversionedPath.equals(versionedPath))
  {
    mount(new RedirectStrategy(unversionedPath, WebPage.class,
      null, versionedPath));
  }
  return ref;
}
 
private final class RedirectStrategy
  extends BookmarkablePageRequestTargetUrlCodingStrategy
{
  private final String _redirectPath;
 
  private RedirectStrategy(String mountPath, Class pageClass,
    String pageMapName, String redirectPath)
  {
    super(mountPath, pageClass, pageMapName);
    _redirectPath = redirectPath;
  }
 
  public IRequestTarget decode(final RequestParameters params)
  {
    return new RedirectRequestTarget(_redirectPath);
  }
 
  String getVersionedPath(Class scope, String path){
    // snip: removed for simplicity, i'll provide code if desired
  }
 
  protected ResourceReference getResourceRef(Class scope,String path)
  {
    ResourceReference ref;
    if (path.endsWith(".js"))
    {
      ref = new ResourceReference(scope, path)
      {
        protected Resource newResource()
        {
          return new JavascriptPackageResource(scope,path,null,null)
          {
            protected int getCacheDuration()
            {
              return CACHE_DURATION;
            }
          };
        }
      };
    } else if (path.endsWith(".css")) {
      // snip: choose appropriate resource references
    }
    ref.bind(this);
    return ref;
  }
}

Yay, now we have versioned resources that can be cached forever (well, still only for about 20 days, see WICKET-1777). And yes, you still use the resources as usual:

public MyPanel(String id)
{
  super(id);
  add(HeaderContributor.forCss(CssScope.class, "all.css"));
  // snip
}

Resulting in

UPDATE: There is an ongoing discussion on my “Wicket Interface Speed-Up” on Wicket’s mailing list.

Let’s start with a short introduction before we talk about setting Expires and Cache-Control HTTP-Headers:

By default, all WebResources are cacheable for one hour, which is defined by WebResource.getCacheDuration():

protected int getCacheDuration()
{
return 3600;
}

While one hour is nice, it would be beneficial to increase the value for resources that are known to change rarely (or never). In order to change that default to something different, one has to override this method. However, it’s not very obvious how to do that if you are used to this:

public MyPanel(String id)
{
super(id);
add(HeaderContributor.forCss(MyPanel.class, "MyPanel.css"));
// snip
}

So how to cache MyPanel.css for more than an hour? In order to answer that question it’s nice to know what happens behind the scenes. HeaderContributor.forCss(…) returns a HeaderContributor that will do the following, as soon as the head section of your HTML is rendered:

public void renderHead(IHeaderResponse response)
{
response.renderCSSReference(
new CompressedResourceReference(scope, path));
}

Okay, so we are dealing with a CompressedResourceReference. But how do ResourceReferences translate into the actual Resource? ResourceReferences will be translated into a URL using a SharedResourceRequestTarget and IRequestCodingStrategy.encode(…) (WebRequestCodingStrategy by default). The default implementation is as follows:

1. to check if the IRequestTarget is mounted
2. use ResourceReference.getSharedResourceKey() to encode a URL (those URL’s will start with “/resource”)

Every time ResourceReference.getSharedResourceKey() is called, Wicket will make sure that the resource is bound to the Application (i.e. stored in Application.getSharedResources()) and return a unique key made up of scope, path, locale and style. If the ResourceReference hasn’t been bound to the Application before, it will make sure, that Application.getSharedResources() will contain a Resource (not a ResourceReference!) by calling ResourceReference.newResource(). In the case of a CSS file, newResource() will return a CompressedPackageResource … but only if it isn’t already bound to the Application – well, you probably can’t check often enough

Okay, so now we know how ResourceReferences translate into Resources: They will be looked up in an application’s shared resources and be created if not already present. However, this check doesn’t take the type of ResourceReference into account. This means that a CompressedResourceReference needn’t translate into a CompressedPackageResource. It can also translate into anything else that has been bound before.

Therefore, the trick is to bind a shared resource to the application before it is used the first time. This can easily be done inside an Application’s init():

public void init()
{
Class scope = MyPanel.class;
String path = "MyPanel.css";
WebResource resource =
new CompressedPackageResource(scope, path, null, null)
{
protected int getCacheDuration()
{
return 3600 * 24 * 7;
}
};
getSharedResources().add(scope, path, null, null, resource);
}

Therefore, you don’t have to change any components to change the cache interval of your resources. However, it would be desirable to make the current default of one hour configurable using Application’s settings. Furthermore, it would also be nice to get control over the newResource() method, e.g. using something like Application.getResourceFactory().newResource(ResourceReference ref).

Attention: An overflow in current Wicket versions (1.3.4 and 1.4-M3 respectively) leads to wrong values for the Expires header. Cache durations greater than Integer.MAX_VALUE/1000 seconds (which is approx. 25 days) cause wrong expiry dates. (see Wicket-1777). Bugfix will be available in next versions.

UPDATE: There is an ongoing discussion on my “Wicket Interface Speed-Up” on Wicket’s mailing list.