You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (JIRA)" <ji...@apache.org> on 2010/11/05 12:13:46 UTC
[jira] Created: (WICKET-3149) Merge DecoratingHeaderResponse to
trunk
Merge DecoratingHeaderResponse to trunk
---------------------------------------
Key: WICKET-3149
URL: https://issues.apache.org/jira/browse/WICKET-3149
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.5-M2.1
Reporter: Martin Grigorov
Assignee: Jeremy Thomerson
Merge changes about DecoratingHeaderResponse to trunk.
Related SVN commits:
1030625
1031154
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (WICKET-3149) Merge DecoratingHeaderResponse to trunk
Posted by Martin Grigorov <mg...@apache.org>.
I would like to freeze new features development for Wicket 1.5 and move this
feature to 1.6.
I like the feature and I understand how important it is but I also I would
like to release 1.5 as soon as possible.
I just migrated our application to 1.5 (it is relatively big) and I'll
report/debug problems if we decide to add this feature, but as I said
already - I prefer to postpone it.
On Tue, Nov 9, 2010 at 12:34 AM, mbrictson <ma...@55minutes.com> wrote:
>
> Hi Jeremy,
>
> My company has spent quite a bit of time working through the issues of
> resource merging and dependency resolution in Wicket, specifically with
> JavaScript, so I thought I could add my two cents to this discussion.
>
>
> jeremy@wickettraining.com wrote:
> >
> > An IHeaderResponse that aggregates resources into a single http request.
> >
>
> I've used wicketstuff-merged-resources for this purpose, and it works well.
> But upgrading it to support Wicket 1.5 looks like it will be a daunting
> task. If you could add an elegant way to support this feature within Wicket
> 1.5 itself (or at least make it easier to accomplish), that would be
> extremely helpful.
>
>
>
> > ONE: Header/footer splitting.
> >
>
> I agree with Igor that the responsibility of contributing to the header or
> the footer belongs to the component developer. This feature would be very
> much appreciated.
>
>
>
> > 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.
> >
>
> +1
>
>
>
> > TWO: the ability to configure resource reference dependencies within your
> > app.
> >
>
> While resource merging is a deployment concern and therefore makes sense to
> configure at the application level, I think resource reference dependencies
> are a concern best left to the component author. I agree with Igor that the
> component should be responsible for calling code to resolve dependencies to
> obtain resource references (he suggested a behavior or static helper
> method;
> I use the former), and then add those references to the header response (or
> footer as the case may be).
>
> I've actually implemented a fairly complete solution for resolving
> JavaScript dependencies along these lines. If you're curious, please email
> me directly and I can share the code with you (it's Apache v2 licensed).
>
> --
> Matt
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Re-jira-Commented-WICKET-3149-Merge-DecoratingHeaderResponse-to-trunk-tp3029081p3032848.html
> Sent from the Forum for Wicket Core developers mailing list archive at
> Nabble.com.
>
Re: [jira] Commented: (WICKET-3149) Merge DecoratingHeaderResponse
to trunk
Posted by mbrictson <ma...@55minutes.com>.
Hi Jeremy,
My company has spent quite a bit of time working through the issues of
resource merging and dependency resolution in Wicket, specifically with
JavaScript, so I thought I could add my two cents to this discussion.
jeremy@wickettraining.com wrote:
>
> An IHeaderResponse that aggregates resources into a single http request.
>
I've used wicketstuff-merged-resources for this purpose, and it works well.
But upgrading it to support Wicket 1.5 looks like it will be a daunting
task. If you could add an elegant way to support this feature within Wicket
1.5 itself (or at least make it easier to accomplish), that would be
extremely helpful.
> ONE: Header/footer splitting.
>
I agree with Igor that the responsibility of contributing to the header or
the footer belongs to the component developer. This feature would be very
much appreciated.
> 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.
>
+1
> TWO: the ability to configure resource reference dependencies within your
> app.
>
While resource merging is a deployment concern and therefore makes sense to
configure at the application level, I think resource reference dependencies
are a concern best left to the component author. I agree with Igor that the
component should be responsible for calling code to resolve dependencies to
obtain resource references (he suggested a behavior or static helper method;
I use the former), and then add those references to the header response (or
footer as the case may be).
I've actually implemented a fairly complete solution for resolving
JavaScript dependencies along these lines. If you're curious, please email
me directly and I can share the code with you (it's Apache v2 licensed).
--
Matt
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Re-jira-Commented-WICKET-3149-Merge-DecoratingHeaderResponse-to-trunk-tp3029081p3032848.html
Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: [jira] Commented: (WICKET-3149) Merge DecoratingHeaderResponse to trunk
Posted by Igor Vaynberg <ig...@gmail.com>.
On Fri, Nov 5, 2010 at 7:11 PM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> On Fri, Nov 5, 2010 at 1:35 PM, Martin Grigorov <mg...@apache.org>wrote:
>
>> On Fri, Nov 5, 2010 at 7:43 PM, Jeremy Thomerson
>> <je...@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*
>
Re: [jira] Commented: (WICKET-3149) Merge DecoratingHeaderResponse to trunk
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Fri, Nov 5, 2010 at 1:35 PM, Martin Grigorov <mg...@apache.org>wrote:
> On Fri, Nov 5, 2010 at 7:43 PM, Jeremy Thomerson
> <je...@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*
Re: [jira] Commented: (WICKET-3149) Merge DecoratingHeaderResponse to trunk
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Nov 5, 2010 at 7:43 PM, Jeremy Thomerson
<je...@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.
>
> Jeremy Thomerson
> http://wickettraining.com
> -- sent from my "smart" phone, so please excuse spelling, formatting, or
> compiler errors
>
> On Nov 5, 2010 12:10 PM, "Igor Vaynberg (JIRA)" <ji...@apache.org> wrote:
>
>
> [
>
> https://issues.apache.org/jira/browse/WICKET-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928687#action_12928687
> ]
>
> Igor Vaynberg commented on WICKET-3149:
> ---------------------------------------
>
> is this something we really want in 1.5.
>
> the only plausable usecase stated for this was to be able to redirect
> javascript to just before the closing body tag. but, this is dangerous to
> do
> transparently as some you want in the head and some you want at the end. i
> think we should build proper support for this and make the choice explicit
> to the developer via new methods on iheaderresponse.
>
> > Merge DecoratingHeaderResponse to trunk
> > ---------------------------------------
> >
> > Key: WICKET-3149
> > URL: https://issues.apache.org/jira/browse/WICKET-3149
> > Project: Wicket
> > Issue Type: Improvement
> > Components: wicket
> > Affects Versions: 1.5-M2.1
> > Reporter: Martin Grigorov
> > Assignee: Jeremy Thomerson
> >
> > Merge changes about DecoratingHeaderResponse to trunk.
> > Related SVN commits:
> > 1030625
> > 1031154
> > 1031432
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
Re: [jira] Commented: (WICKET-3149) Merge DecoratingHeaderResponse to trunk
Posted by Igor Vaynberg <ig...@gmail.com>.
what are the other usecases?
-igor
On Fri, Nov 5, 2010 at 10:43 AM, Jeremy Thomerson
<je...@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.
>
> Jeremy Thomerson
> http://wickettraining.com
> -- sent from my "smart" phone, so please excuse spelling, formatting, or
> compiler errors
>
> On Nov 5, 2010 12:10 PM, "Igor Vaynberg (JIRA)" <ji...@apache.org> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/WICKET-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928687#action_12928687]
>
> Igor Vaynberg commented on WICKET-3149:
> ---------------------------------------
>
> is this something we really want in 1.5.
>
> the only plausable usecase stated for this was to be able to redirect
> javascript to just before the closing body tag. but, this is dangerous to do
> transparently as some you want in the head and some you want at the end. i
> think we should build proper support for this and make the choice explicit
> to the developer via new methods on iheaderresponse.
>
>> Merge DecoratingHeaderResponse to trunk
>> ---------------------------------------
>>
>> Key: WICKET-3149
>> URL: https://issues.apache.org/jira/browse/WICKET-3149
>> Project: Wicket
>> Issue Type: Improvement
>> Components: wicket
>> Affects Versions: 1.5-M2.1
>> Reporter: Martin Grigorov
>> Assignee: Jeremy Thomerson
>>
>> Merge changes about DecoratingHeaderResponse to trunk.
>> Related SVN commits:
>> 1030625
>> 1031154
>> 1031432
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
Re: [jira] Commented: (WICKET-3149) Merge DecoratingHeaderResponse to trunk
Posted by Jeremy Thomerson <je...@wickettraining.com>.
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.
Jeremy Thomerson
http://wickettraining.com
-- sent from my "smart" phone, so please excuse spelling, formatting, or
compiler errors
On Nov 5, 2010 12:10 PM, "Igor Vaynberg (JIRA)" <ji...@apache.org> wrote:
[
https://issues.apache.org/jira/browse/WICKET-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928687#action_12928687]
Igor Vaynberg commented on WICKET-3149:
---------------------------------------
is this something we really want in 1.5.
the only plausable usecase stated for this was to be able to redirect
javascript to just before the closing body tag. but, this is dangerous to do
transparently as some you want in the head and some you want at the end. i
think we should build proper support for this and make the choice explicit
to the developer via new methods on iheaderresponse.
> Merge DecoratingHeaderResponse to trunk
> ---------------------------------------
>
> Key: WICKET-3149
> URL: https://issues.apache.org/jira/browse/WICKET-3149
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.5-M2.1
> Reporter: Martin Grigorov
> Assignee: Jeremy Thomerson
>
> Merge changes about DecoratingHeaderResponse to trunk.
> Related SVN commits:
> 1030625
> 1031154
> 1031432
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3149) Merge DecoratingHeaderResponse to
trunk
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931669#action_12931669 ]
Hudson commented on WICKET-3149:
--------------------------------
Integrated in Apache Wicket 1.5.x #507 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/507/])
> Merge DecoratingHeaderResponse to trunk
> ---------------------------------------
>
> Key: WICKET-3149
> URL: https://issues.apache.org/jira/browse/WICKET-3149
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.5-M2.1
> Reporter: Martin Grigorov
> Assignee: Jeremy Thomerson
> Fix For: 1.5-M4
>
>
> Merge changes about DecoratingHeaderResponse to trunk.
> Related SVN commits:
> 1030625
> 1031154
> 1031432
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3149) Merge DecoratingHeaderResponse to
trunk
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928687#action_12928687 ]
Igor Vaynberg commented on WICKET-3149:
---------------------------------------
is this something we really want in 1.5.
the only plausable usecase stated for this was to be able to redirect javascript to just before the closing body tag. but, this is dangerous to do transparently as some you want in the head and some you want at the end. i think we should build proper support for this and make the choice explicit to the developer via new methods on iheaderresponse.
> Merge DecoratingHeaderResponse to trunk
> ---------------------------------------
>
> Key: WICKET-3149
> URL: https://issues.apache.org/jira/browse/WICKET-3149
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.5-M2.1
> Reporter: Martin Grigorov
> Assignee: Jeremy Thomerson
>
> Merge changes about DecoratingHeaderResponse to trunk.
> Related SVN commits:
> 1030625
> 1031154
> 1031432
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-3149) Merge DecoratingHeaderResponse to
trunk
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Grigorov updated WICKET-3149:
------------------------------------
Description:
Merge changes about DecoratingHeaderResponse to trunk.
Related SVN commits:
1030625
1031154
1031432
was:
Merge changes about DecoratingHeaderResponse to trunk.
Related SVN commits:
1030625
1031154
> Merge DecoratingHeaderResponse to trunk
> ---------------------------------------
>
> Key: WICKET-3149
> URL: https://issues.apache.org/jira/browse/WICKET-3149
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.5-M2.1
> Reporter: Martin Grigorov
> Assignee: Jeremy Thomerson
>
> Merge changes about DecoratingHeaderResponse to trunk.
> Related SVN commits:
> 1030625
> 1031154
> 1031432
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-3149) Merge DecoratingHeaderResponse to
trunk
Posted by "Jeremy Thomerson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Thomerson closed WICKET-3149.
------------------------------------
Resolution: Fixed
Fix Version/s: 1.5-M4
> Merge DecoratingHeaderResponse to trunk
> ---------------------------------------
>
> Key: WICKET-3149
> URL: https://issues.apache.org/jira/browse/WICKET-3149
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.5-M2.1
> Reporter: Martin Grigorov
> Assignee: Jeremy Thomerson
> Fix For: 1.5-M4
>
>
> Merge changes about DecoratingHeaderResponse to trunk.
> Related SVN commits:
> 1030625
> 1031154
> 1031432
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.