wicket-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Thomerson <jer...@wickettraining.com>
Subject Re: [jira] Commented: (WICKET-3149) Merge DecoratingHeaderResponse to trunk
Date Sat, 06 Nov 2010 02:11:49 GMT
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.

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*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message