On Fri, Nov 5, 2010 at 1:35 PM, Martin Grigorov <[email protected]>wrote:
> On Fri, Nov 5, 2010 at 7:43 PM, Jeremy Thomerson > <[email protected]>wrote: > > > Yes, we want this in trunk. There are other use cases. I'm working on a > > bunch of other stuff related to this that will be checked in in the next > > few > > days. > > > Please create a ticket and describe the idea. > > I will, but I have a bunch of it ready to commit. The main thing that I want to get in is this: An IHeaderResponse that aggregates resources into a single http request. If you break your css/js into a bunch of small files, this saves you a bunch of small http requests. The servlet or shared resource to aggregate these (not yet written - all the rest of the requirements [grouping, rendering group, etc] are written) can respond with a 304 if the resources have not changed. The other things that I have implemented, and have an example created for are this: ONE: Header/footer splitting. Yes, I understand that some folks won't want this to happen invisibly. But, if you separate the header and footer into two things (as has been suggested before), where developers must either call headerResponse.foo or footerResponse.foo, what happens if you don't want your app to do that? Library developers must decide which to call. You should be able to do this as a configurable thing - which is what I'm committing. That way, developers call headerResponse.foo - and then you decide where it goes. NOTE: after committing this, I had planned to start a discussion about renaming IHeaderContributor / IHeaderResponse to IResourceContributor / IResourceResponse in trunk / 1.5 so that it is more generic since now users can decide where they want things. TWO: the ability to configure resource reference dependencies within your app. So, you could configure that a.css depends on b.css and c.css, and your developer doesn't have to call renderCSSReference for each one, in the correct order. They say renderCssReference(a.css), and your decorating header response looks up the dependencies and orders them in the correct depth-first order. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
