wicket-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Vaynberg <igor.vaynb...@gmail.com>
Subject Re: [jira] Commented: (WICKET-3149) Merge DecoratingHeaderResponse to trunk
Date Sun, 07 Nov 2010 20:43:46 GMT
On Fri, Nov 5, 2010 at 7:11 PM, Jeremy Thomerson
<jeremy@wickettraining.com> wrote:
> On Fri, Nov 5, 2010 at 1:35 PM, Martin Grigorov <mgrigorov@apache.org>wrote:
>
>> On Fri, Nov 5, 2010 at 7:43 PM, Jeremy Thomerson
>> <jeremy@wickettraining.com>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*
>

Mime
View raw message