Hi Jeremy, On Sat, Dec 18, 2010 at 6:53 AM, Jeremy Thomerson <jer...@wickettraining.com > wrote:
> 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 > JavascriptFilteredIntoFooterHeaderResponse that performs the described > header / footer split. > > -- > Jeremy Thomerson > http://wickettraining.com > Need a CMS for Wicket? Use Brix! http://brixcms.org > > > On Fri, Dec 17, 2010 at 11:45 PM, Jeremy Thomerson > <jer...@wickettraining.com> wrote: > > 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 > Do you mind if we use this code for a new wicket-example application ? > > > > > 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. > I think we should create a Wiki page with this description and add an entry in migrate-to-1.5 with a link to that page. I'll do it later today or tomorrow. > > > > -- > > 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. > > >
