This is a copy from an email from Jeremy Thomerson to users@ mailing list at 17 Dec 2010 describing how to
use a new functionality in Wicket 1.4.14+ and 1.5+ related to resource contribution.
Subject: Wicket resources (css, js and images)?
See Application#setHeaderResponseDecorator. You can use this to create
your own IHeaderResponse and intercept all calls to render JS / CSS
references. Then, you could do smart things like keep all the
references around until the end of the request (or actually, the
renderHead traversal), and at that point, build a URL that references
an aggregate of all requested CSS / JS resources.
As Hielke mentioned, you then have problems because every page has a
different combo of resources. So, I provided
AbstractResourceAggregatingHeaderResponse that provides a framework
for grouping resource references into aggregate groups. Now, your
developer can specify groups for references. What groups you specify
are totally up to you. The idea is that you group things that will be
on every page into a group, and then the things that change on each
page into another group. So, you get to take advantage of the browser
caching for those things that are on every page. You can go further
if you'd like.
So, you could do something like the following to specify groups and
load orders (things within a certain group may still need to be loaded
before / after other things in same group).
// example of things that may be shared for all your applications
across your company, etc...:
// example of something that may be in this single application:
I've put together a working quickstart example of this. You can
download it and play with it. http://wickettraining.com/attachments/resourceaggregation.tar.gz
With some work, a standard set of aggregation groups could be defined,
and this could be rolled into core. If someone wants to spearhead
that, I would love it and do anything I can to assist.
PS - In an ideal world, you wouldn't even need to specify the groups
manually. You could have a smart algorithm that used each request to
learn what things always appear together. The algorithm would start
grouping things that commonly appear together into groups
automatically. The first few requests wouldn't really group much, but
as the requests continue, you would build better and better groups.
Also worth mentioning, there are two other example "decorating header
responses" that I committed into core for you to build on:
1 - ResourceReferenceDependencyInjectingHeaderResponse - which allows
you to create a IResourceReferenceDependencyConfigurationService which
defines dependencies for your resource references. For instance,
wicket-ajax.js depends on wicket-event.js. So, everywhere that we
render a reference to wicket-ajax.js, we must be sure that a reference
to wicket-event.js is also rendered. However, with the
ResourceReferenceDependencyInjectingHeaderResponse, you can make this
automatic. This is probably only worth the additional effort if you
have many such reference dependencies.
2 - HeaderResponseContainerFilteringHeaderResponse - allows you to
filter resource references into different "buckets". One of these
"buckets" is then rendered into the standard Wicket head location.
The others can be rendered wherever you want in the page by embedding
a HeaderResponseFilteredResponseContainer in your page. This is
useful if you want CSS to appear in the header and JS just before the
</body> tag in your app (a recommendation by UI experts to decrease
page load time). There is a default
header / footer split.