You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jeremy Thomerson <je...@wickettraining.com> on 2010/12/18 06:56:36 UTC
[DISCUSS 1.5] Rename IHeaderResponse to IResourceResponse (or similar)?
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
<je...@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
> <je...@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 <mg...@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 <al...@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.
>>
>
Re: [DISCUSS 1.5] Rename IHeaderResponse to IResourceResponse (or similar)?
Posted by Martin Grigorov <mg...@apache.org>.
about the new name : IResourceContribution ?
about the application:
it is ready - it shows resource grouping (i.e. serving several resources in
one http request) and filtering (load .css in <head> and .js after </body>).
I have a question though: the application uses jquery which has nice MIT
license, do we need to add something like
"apache-wicket-1.4.15/licenses/yahoo-license.txt" for it ?
On Mon, Dec 20, 2010 at 11:35 PM, Jeremy Thomerson <
jeremy@wickettraining.com> wrote:
> Will do. It will be a couple of days.
>
> On Mon, Dec 20, 2010 at 4:28 PM, Martin Grigorov
> <ma...@gmail.com> wrote:
> > Can you add demo of contribution to the footer in the new example
> application?
> >
> > "Jeremy Thomerson" <je...@wickettraining.com> wrote:
> >
> >>On Sat, Dec 18, 2010 at 8:25 AM, Jeremy Thomerson
> >><je...@wickettraining.com> wrote:
> >>> On Sat, Dec 18, 2010 at 2:27 AM, Juergen Donnerstag
> >>> <ju...@gmail.com> wrote:
> >>>> 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
> >>>
> >>> Agreed. I just haven't thought of a great name for it.
> >>> IAmGoingToRenderYourStuffSomewhereResponse seemed a little unwieldy,
> >>> and it was the best I had at the time. :)
> >>>
> >>> Perhaps IResourceContributions (to replace IHeaderResponse) and
> >>> IResourceContributor (to replace IHeaderContributor) and
> >>> contributeResources (to replace renderHead of IHeaderContributor)?
> >>
> >>Anybody else have an opinion on this? Good ideas for names? Strong
> >>feelings to "just leave it alone"?
> >>
> >>--
> >>Jeremy Thomerson
> >>http://wickettraining.com
> >>Need a CMS for Wicket? Use Brix! http://brixcms.org
> >
> > --
> > Sent from my mobile phone. Please excuse my brevity.
> >
>
>
>
> --
> Jeremy Thomerson
> http://wickettraining.com
> Need a CMS for Wicket? Use Brix! http://brixcms.org
>
Re: [DISCUSS 1.5] Rename IHeaderResponse to IResourceResponse (or similar)?
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Will do. It will be a couple of days.
On Mon, Dec 20, 2010 at 4:28 PM, Martin Grigorov
<ma...@gmail.com> wrote:
> Can you add demo of contribution to the footer in the new example application?
>
> "Jeremy Thomerson" <je...@wickettraining.com> wrote:
>
>>On Sat, Dec 18, 2010 at 8:25 AM, Jeremy Thomerson
>><je...@wickettraining.com> wrote:
>>> On Sat, Dec 18, 2010 at 2:27 AM, Juergen Donnerstag
>>> <ju...@gmail.com> wrote:
>>>> 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
>>>
>>> Agreed. I just haven't thought of a great name for it.
>>> IAmGoingToRenderYourStuffSomewhereResponse seemed a little unwieldy,
>>> and it was the best I had at the time. :)
>>>
>>> Perhaps IResourceContributions (to replace IHeaderResponse) and
>>> IResourceContributor (to replace IHeaderContributor) and
>>> contributeResources (to replace renderHead of IHeaderContributor)?
>>
>>Anybody else have an opinion on this? Good ideas for names? Strong
>>feelings to "just leave it alone"?
>>
>>--
>>Jeremy Thomerson
>>http://wickettraining.com
>>Need a CMS for Wicket? Use Brix! http://brixcms.org
>
> --
> Sent from my mobile phone. Please excuse my brevity.
>
--
Jeremy Thomerson
http://wickettraining.com
Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: [DISCUSS 1.5] Rename IHeaderResponse to IResourceResponse (or similar)?
Posted by Martin Grigorov <ma...@gmail.com>.
Can you add demo of contribution to the footer in the new example application?
"Jeremy Thomerson" <je...@wickettraining.com> wrote:
>On Sat, Dec 18, 2010 at 8:25 AM, Jeremy Thomerson
><je...@wickettraining.com> wrote:
>> On Sat, Dec 18, 2010 at 2:27 AM, Juergen Donnerstag
>> <ju...@gmail.com> wrote:
>>> 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
>>
>> Agreed. I just haven't thought of a great name for it.
>> IAmGoingToRenderYourStuffSomewhereResponse seemed a little unwieldy,
>> and it was the best I had at the time. :)
>>
>> Perhaps IResourceContributions (to replace IHeaderResponse) and
>> IResourceContributor (to replace IHeaderContributor) and
>> contributeResources (to replace renderHead of IHeaderContributor)?
>
>Anybody else have an opinion on this? Good ideas for names? Strong
>feelings to "just leave it alone"?
>
>--
>Jeremy Thomerson
>http://wickettraining.com
>Need a CMS for Wicket? Use Brix! http://brixcms.org
--
Sent from my mobile phone. Please excuse my brevity.
Re: [DISCUSS 1.5] Rename IHeaderResponse to IResourceResponse (or similar)?
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Sat, Dec 18, 2010 at 8:25 AM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> On Sat, Dec 18, 2010 at 2:27 AM, Juergen Donnerstag
> <ju...@gmail.com> wrote:
>> 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
>
> Agreed. I just haven't thought of a great name for it.
> IAmGoingToRenderYourStuffSomewhereResponse seemed a little unwieldy,
> and it was the best I had at the time. :)
>
> Perhaps IResourceContributions (to replace IHeaderResponse) and
> IResourceContributor (to replace IHeaderContributor) and
> contributeResources (to replace renderHead of IHeaderContributor)?
Anybody else have an opinion on this? Good ideas for names? Strong
feelings to "just leave it alone"?
--
Jeremy Thomerson
http://wickettraining.com
Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: [DISCUSS 1.5] Rename IHeaderResponse to IResourceResponse (or similar)?
Posted by tetsuo <ro...@gmail.com>.
Unless you can think of a spectacularly better name, I think you
should just keep IHeaderResponse.
Tetsuo
On Sat, Dec 18, 2010 at 12:25 PM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> On Sat, Dec 18, 2010 at 2:27 AM, Juergen Donnerstag
> <ju...@gmail.com> wrote:
>> 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
>
> Agreed. I just haven't thought of a great name for it.
> IAmGoingToRenderYourStuffSomewhereResponse seemed a little unwieldy,
> and it was the best I had at the time. :)
>
> Perhaps IResourceContributions (to replace IHeaderResponse) and
> IResourceContributor (to replace IHeaderContributor) and
> contributeResources (to replace renderHead of IHeaderContributor)?
>
> --
> Jeremy Thomerson
> http://wickettraining.com
> Need a CMS for Wicket? Use Brix! http://brixcms.org
>
Re: [DISCUSS 1.5] Rename IHeaderResponse to IResourceResponse (or similar)?
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Sat, Dec 18, 2010 at 2:27 AM, Juergen Donnerstag
<ju...@gmail.com> wrote:
> 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
Agreed. I just haven't thought of a great name for it.
IAmGoingToRenderYourStuffSomewhereResponse seemed a little unwieldy,
and it was the best I had at the time. :)
Perhaps IResourceContributions (to replace IHeaderResponse) and
IResourceContributor (to replace IHeaderContributor) and
contributeResources (to replace renderHead of IHeaderContributor)?
--
Jeremy Thomerson
http://wickettraining.com
Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: [DISCUSS 1.5] Rename IHeaderResponse to IResourceResponse (or similar)?
Posted by Martijn Dashorst <ma...@gmail.com>.
On Sat, Dec 18, 2010 at 9:27 AM, Juergen Donnerstag
<ju...@gmail.com> wrote:
> 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
ImNotGoingInTheBodyRespone :)
Martijn
Re: [DISCUSS 1.5] Rename IHeaderResponse to IResourceResponse (or similar)?
Posted by Juergen Donnerstag <ju...@gmail.com>.
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
<je...@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
> <je...@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
>> <je...@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 <mg...@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 <al...@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.
>>>
>>
>