On Fri, Nov 5, 2010 at 7:11 PM, Jeremy Thomerson <[email protected]> wrote: > 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.
my point was that the two are not equivalent behavior wise. so what happens if some component in a library needs to output the js into head, and your application rewrites it into foot. you are breaking encapsulation. > 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. sure, fine by me. > 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. seems this is the wrong place to do it. if you have dependencies then dont expose a resource reference, instead encapsulate them in a behavior or in a static helper like new JQueryReferences().add(iheaderresponse) -igor > > -- > Jeremy Thomerson > http://wickettraining.com > *Need a CMS for Wicket? Use Brix! http://brixcms.org* >
