I understand that IHeaderResponse is no longer accurate, but IResourceResponse IMO would simply be wrong: it's not a response to a resource. It contributes to a specific section of a response such as Header or Footer
Juergen On Sat, Dec 18, 2010 at 6:56 AM, Jeremy Thomerson <jer...@wickettraining.com> wrote: > With the information in the previous message (below), does anyone > think that we should rename IHeaderResponse (and renderHead) in 1.5 to > something like IResourceResponse (and renderResources)? You now have > the ability to separate resources into the footer implicitly. Of > course, this would have to be done carefully since some components > could be broken by not knowing that their JS was going into the footer > (although it probably reflects poorly on the component if it breaks by > this). > > Best regards, > > -- > Jeremy Thomerson > http://wickettraining.com > Need a CMS for Wicket? Use Brix! http://brixcms.org > > > On Fri, Dec 17, 2010 at 11:53 PM, 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 >>> >>> 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. >>> >> >
