As Martin mentioned, I added a way for you to "decorate" all header responses in an application. 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...: response.renderCSSReference(new GroupedAndOrderedResourceReference(ResourceGroup.GLOBAL, 0, HomePage.class, "footer.css")); response.renderCSSReference(new GroupedAndOrderedResourceReference(ResourceGroup.GLOBAL, 0, HomePage.class, "header.css")); // example of something that may be in this single application: response.renderCSSReference(new GroupedAndOrderedResourceReference(ResourceGroup.APPLICATION, 0, HomePage.class, "app.css")); 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. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org > On Thu, Dec 16, 2010 at 4:36 AM, Martin Grigorov <mgrigo...@apache.org> wrote: >> >> I believe the latest changes by Jeremy added functionality for this. >> Jeremy can you please explain how the >> new org.apache.wicket.markup.html.IHeaderResponseDecorator can be used (is >> being used by your customer) ? >> >> On Wed, Dec 15, 2010 at 9:05 PM, Alex Objelean <alex.objel...@gmail.com> >> wrote: >>> >>> Though this topic is quite old, I think it is still actual. Since the 1.5 >>> release is not far away, did anybody thought if the (at least) js resource >>> merging should occur? >>> >>> This is very useful when you have a page with a large number of components, >>> each loading a large number of small resources. Having a single resource (js >>> and/or css) as a result of page rendering could have a dramatic page loading >>> time improvement. >>> >>> Thanks! >>> Alex Objelean >>> -- >>> View this message in context: >>> http://apache-wicket.1842946.n4.nabble.com/Wicket-resources-css-js-and-images-tp1868800p3089781.html >>> Sent from the Users forum mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
