renderHead() / wicket:head page / component order

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

renderHead() / wicket:head page / component order

Pierre Goiffon
Hi,

We recently upgrade to Wicket 1.5. One of the major concern during that
migration was to deal with the new order of the header render strategy.
I see this is defined in AbstractHeaderRenderStrategy#get(), and reading
https://issues.apache.org/jira/browse/WICKET-4000 I understand the
reason of this choice : to be able to replace a parent contribution.

But this is a big problem when you deal with css, because in your
supages / panels / components you will insert specific properties that
are meant to override global ones defined in the page... and to do so
the css properties in the subpage / panel / component must be inserted
in the head AFTER the page css declaration.

For exemple I am just dealing with a problem in a page hierarchy like
the one below :
pageA : adds mycss.css using renderHead and a ResourceReference
pageB : adds 6 lines of css to change the behavior in wicket:head
pageC : adds 1 line of css to override a margin in wicket:head

The only solution I see with wicket 1.5 is to create css files for the
properties in page B and page C and adds them in each renderHead() using
an implementation of AbstractResourceDependentResourceReference.
This is just a nightmare, and impacts also the user (3 css files to
download instead of 1 !).

Are there any mean to do better ?
If not, as I think we need both to render in the header before or after
the parent, maybe there should be a method for each order ? Like
renderHeadBefore() / renderHeadAfter() ?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Martin Grigorov-4
Hi Pierre,

There are some improvements in this area in Wicket 6.
Please read http://wicketinaction.com/2012/07/wicket-6-resource-management/
for more information. Pay attention to PriorityHeaderItem and setting
custom header item comparator. Header contributions from <wicket:head>
are represented with org.apache.wicket.markup.head.PageHeaderItem.

On Mon, Jul 9, 2012 at 5:16 PM, Pierre Goiffon
<[hidden email]> wrote:

> Hi,
>
> We recently upgrade to Wicket 1.5. One of the major concern during that
> migration was to deal with the new order of the header render strategy.
> I see this is defined in AbstractHeaderRenderStrategy#get(), and reading
> https://issues.apache.org/jira/browse/WICKET-4000 I understand the
> reason of this choice : to be able to replace a parent contribution.
>
> But this is a big problem when you deal with css, because in your
> supages / panels / components you will insert specific properties that
> are meant to override global ones defined in the page... and to do so
> the css properties in the subpage / panel / component must be inserted
> in the head AFTER the page css declaration.
>
> For exemple I am just dealing with a problem in a page hierarchy like
> the one below :
> pageA : adds mycss.css using renderHead and a ResourceReference
> pageB : adds 6 lines of css to change the behavior in wicket:head
> pageC : adds 1 line of css to override a margin in wicket:head
>
> The only solution I see with wicket 1.5 is to create css files for the
> properties in page B and page C and adds them in each renderHead() using
> an implementation of AbstractResourceDependentResourceReference.
> This is just a nightmare, and impacts also the user (3 css files to
> download instead of 1 !).
>
> Are there any mean to do better ?
> If not, as I think we need both to render in the header before or after
> the parent, maybe there should be a method for each order ? Like
> renderHeadBefore() / renderHeadAfter() ?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Pierre Goiffon
 >> We recently upgrade to Wicket 1.5. One of the major concern during that
 >> migration was to deal with the new order of the header render strategy.
 >> I see this is defined in AbstractHeaderRenderStrategy#get()
(...)
 >> For exemple I am just dealing with a problem in a page hierarchy like
 >> the one below :
 >> pageA : adds mycss.css using renderHead and a ResourceReference
 >> pageB : adds 6 lines of css to change the behavior in wicket:head
 >> pageC : adds 1 line of css to override a margin in wicket:head

> There are some improvements in this area in Wicket 6.
> Please read http://wicketinaction.com/2012/07/wicket-6-resource-management/
> for more information. Pay attention to PriorityHeaderItem and setting
> custom header item comparator. Header contributions from <wicket:head>
> are represented with org.apache.wicket.markup.head.PageHeaderItem.

Thanks very mutch Martin, very interesting !
Your blog have a lots of very nice posts like this one, I'm going to
read lots of them really carefully ! I'm very happy to find such a
resource as documentation is not the strongest Wicket highlight !

Getting back to my concern...

PriorityHeaderItem is a nice answer to serve the most generic resources
(in my exemple, mycss.css) : clean and simple.
Looking at the Wicket 6 classes in your sample project
(https://github.com/martin-g/blogs/tree/master/wicket6-resource-management)
I also see a CssContentHeaderItem that allows to add CSS without adding
a link and an extra resource to download for the UAs : cool !

But as a developper I still see some issues :
- It's not very convenient to write static css in the Java code instead
of simply leave it in the html file in a wicket:head block. In prev 1.5
version it was a very simple way to add static client side code !
- Just using a PriorityHeaderItem wouldn't be enough, cause I need the
header contribution to be in the order A / B / C. I would need to write
a custom comparator... And it wouldn't be that nice because in my case
page A and page B are in a different project than page C - this latter
is the only one to be in the same project as the wicket application
class. The custom comparator would also certainly become quite unusable,
dealing with too many specific cases ?

For the 1.5 branch a simple solution I see would be to let the
IHeaderRenderStrategy be defined by the Wicket application class. So
every one would be able to choose what is his most wanted preference :
be able to override parent renderHead() methods
(ChildFirstHeaderRenderStrategy), or have a very simple mean to insert
cascading client side static code (ParentFirstHeaderRenderStrategy).

I you use a ParentFirstHeaderRenderStrategy and still need to override a
parent renderHead() in a specific component, you could still move the
parent code to an overridable method right ? Like :

parentClass {
        public void renderHeader(..) {
                doStuff();
        }

        public void doStuff() {
                ...
        }
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Martin Grigorov-4
Hi,

On Tue, Jul 10, 2012 at 12:18 PM, Pierre Goiffon
<[hidden email]> wrote:

>  >> We recently upgrade to Wicket 1.5. One of the major concern during that
>  >> migration was to deal with the new order of the header render strategy.
>  >> I see this is defined in AbstractHeaderRenderStrategy#get()
> (...)
>  >> For exemple I am just dealing with a problem in a page hierarchy like
>  >> the one below :
>  >> pageA : adds mycss.css using renderHead and a ResourceReference
>  >> pageB : adds 6 lines of css to change the behavior in wicket:head
>  >> pageC : adds 1 line of css to override a margin in wicket:head
>
>> There are some improvements in this area in Wicket 6.
>> Please read http://wicketinaction.com/2012/07/wicket-6-resource-management/
>> for more information. Pay attention to PriorityHeaderItem and setting
>> custom header item comparator. Header contributions from <wicket:head>
>> are represented with org.apache.wicket.markup.head.PageHeaderItem.
>
> Thanks very mutch Martin, very interesting !
> Your blog have a lots of very nice posts like this one, I'm going to
> read lots of them really carefully ! I'm very happy to find such a
> resource as documentation is not the strongest Wicket highlight !
>
> Getting back to my concern...
>
> PriorityHeaderItem is a nice answer to serve the most generic resources
> (in my exemple, mycss.css) : clean and simple.
> Looking at the Wicket 6 classes in your sample project
> (https://github.com/martin-g/blogs/tree/master/wicket6-resource-management)
> I also see a CssContentHeaderItem that allows to add CSS without adding
> a link and an extra resource to download for the UAs : cool !

That is possible since Wicket 1.2+

>
> But as a developper I still see some issues :
> - It's not very convenient to write static css in the Java code instead
> of simply leave it in the html file in a wicket:head block. In prev 1.5
> version it was a very simple way to add static client side code !

In Wicket 6 this is still valid. The only change is the order in which
the content in <wicket:head>s found in base/sub page, base/sub panels
is rendered.
The order is now consistent - no matter if you contribute the CSS via
markup (<head> or <wicket:head>) or via code (in .java).

> - Just using a PriorityHeaderItem wouldn't be enough, cause I need the
> header contribution to be in the order A / B / C. I would need to write
> a custom comparator... And it wouldn't be that nice because in my case
> page A and page B are in a different project than page C - this latter
> is the only one to be in the same project as the wicket application
> class. The custom comparator would also certainly become quite unusable,
> dealing with too many specific cases ?

If you cannot manage that in your own code then I see no way Wicket to
manage it in general way for all users...

Wicket defines two simple rules:
1) component-first contribution - if you use a library that provides
Wicket components (e.g. WiQuery) then the components will contribute
first and then your page. This way you have the last word what CSS
rules to apply. I.e. you can override WiQuery's default CSS rules.
2) child-component contributes after its parent - when you use
#renderHead(IHeaderResponse) you are in control to call
super.renderHead() at the top  of the method body or at the bottom.
Most of the time developers put it at the top. You don't have the
control for that for <wicket:head> though. Here Wicket contributes
first the parent's markup and then the child's one.

>
> For the 1.5 branch a simple solution I see would be to let the
> IHeaderRenderStrategy be defined by the Wicket application class. So
> every one would be able to choose what is his most wanted preference :
> be able to override parent renderHead() methods
> (ChildFirstHeaderRenderStrategy), or have a very simple mean to insert
> cascading client side static code (ParentFirstHeaderRenderStrategy).


In org.apache.wicket.markup.renderStrategy.AbstractHeaderRenderStrategy#get()
method there is intentionally "hard" way to switch the header
contribution strategy. It uses a system property named
'Wicket_HeaderRenderStrategy' which value may be the fully qualified
name of the strategy to use.
org.apache.wicket.markup.renderStrategy.ParentFirstHeaderRenderStrategy
is the one that has been used in Wicket 1.4- and is considered
deprecated.
So you can set this system property in your MyApp#init() but I cannot
guarantee for how long it will work.

>
> I you use a ParentFirstHeaderRenderStrategy and still need to override a
> parent renderHead() in a specific component, you could still move the
> parent code to an overridable method right ? Like :
>
> parentClass {
>         public void renderHeader(..) {
>                 doStuff();
>         }
>
>         public void doStuff() {
>                 ...
>         }
> }
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Pierre Goiffon
Hello !

Le 22/07/2012 21:39, Martin Grigorov a écrit :

>>>> For exemple I am just dealing with a problem in a page hierarchy like
>>>> the one below :
>>>> pageA : adds mycss.css using renderHead and a ResourceReference
>>>> pageB : adds 6 lines of css to change the behavior in wicket:head
>>>> pageC : adds 1 line of css to override a margin in wicket:head
>>
>> But as a developper I still see some issues :
>> - It's not very convenient to write static css in the Java code instead
>> of simply leave it in the html file in a wicket:head block. In prev 1.5
>> version it was a very simple way to add static client side code !
>
> In Wicket 6 this is still valid. The only change is the order in which
> the content in <wicket:head>s found in base/sub page, base/sub panels
> is rendered.
> The order is now consistent - no matter if you contribute the CSS via
> markup (<head> or <wicket:head>) or via code (in .java).

I didn't understand your statement ? Particularly "the order is now
consistent".

My problem was originally about the delivery order of wicket:head
contributions that was changed in wicket 1.5.
Reading your statement I understand wicket:head do still render parent
first in Wicket 1.5 but in Wicket 6 renders child first, like the other
Java way (renderHead() right ?), so I guess I don't understand well what
you wrote ?

> Wicket defines two simple rules:
> 1) component-first contribution - if you use a library that provides
> Wicket components (e.g. WiQuery) then the components will contribute
> first and then your page. This way you have the last word what CSS
> rules to apply. I.e. you can override WiQuery's default CSS rules.
> 2) child-component contributes after its parent - when you use
> #renderHead(IHeaderResponse) you are in control to call
> super.renderHead() at the top  of the method body or at the bottom.
> Most of the time developers put it at the top. You don't have the
> control for that for <wicket:head> though. Here Wicket contributes
> first the parent's markup and then the child's one.

When you define a simple page strategy like in my problem, you could
have static css overrides and wants to deal with it in the css order,
that means most specific last. And those css overrides (like
".main-section { margin-top: 0;}") are quite static so wicket:head is a
perfect place for them : quick to find, quick to write, quick to modify.
Having to move them to the java file isn't that awful, but a little more
heavier. Plus in Wicket 1.5 I don't have CssContentHeaderItem so the UA
will get a css link for each contribution, and that is very bad.

We were using WiQuery in previous versions of our product, back then we
served a global css for wiquery component. I've just search how we were
dealing with WiQuery css but can't find anything. Indeed the last
WiQuery jar we used, the 1.2.3 version, don't contains any .css file ?
Anyway we have lots of shared components, but we do have a common
abstract class for each application, and so we are able to serve a
common css file.

> In org.apache.wicket.markup.renderStrategy.AbstractHeaderRenderStrategy#get()
> method there is intentionally "hard" way to switch the header
> contribution strategy. It uses a system property named
> 'Wicket_HeaderRenderStrategy' which value may be the fully qualified
> name of the strategy to use.
> org.apache.wicket.markup.renderStrategy.ParentFirstHeaderRenderStrategy
> is the one that has been used in Wicket 1.4- and is considered
> deprecated.
> So you can set this system property in your MyApp#init() but I cannot
> guarantee for how long it will work.

Very good to know, thanks a lot !

Not sure though how to fix the property ? Is it by inserting the
following line in the application init() method :
System.setProperty("Wicket_HeaderRenderStrategy","org.apache.wicket.markup.renderStrategy.ParentFirstHeaderRenderStrategy");
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Martin Grigorov-4
I'll let Emond to answer you.

On Tue, Jul 24, 2012 at 5:24 PM, Pierre Goiffon
<[hidden email]> wrote:

> Hello !
>
> Le 22/07/2012 21:39, Martin Grigorov a écrit :
>>>>> For exemple I am just dealing with a problem in a page hierarchy like
>>>>> the one below :
>>>>> pageA : adds mycss.css using renderHead and a ResourceReference
>>>>> pageB : adds 6 lines of css to change the behavior in wicket:head
>>>>> pageC : adds 1 line of css to override a margin in wicket:head
>>>
>>> But as a developper I still see some issues :
>>> - It's not very convenient to write static css in the Java code instead
>>> of simply leave it in the html file in a wicket:head block. In prev 1.5
>>> version it was a very simple way to add static client side code !
>>
>> In Wicket 6 this is still valid. The only change is the order in which
>> the content in <wicket:head>s found in base/sub page, base/sub panels
>> is rendered.
>> The order is now consistent - no matter if you contribute the CSS via
>> markup (<head> or <wicket:head>) or via code (in .java).
>
> I didn't understand your statement ? Particularly "the order is now
> consistent".
>
> My problem was originally about the delivery order of wicket:head
> contributions that was changed in wicket 1.5.
> Reading your statement I understand wicket:head do still render parent
> first in Wicket 1.5 but in Wicket 6 renders child first, like the other
> Java way (renderHead() right ?), so I guess I don't understand well what
> you wrote ?
>
>> Wicket defines two simple rules:
>> 1) component-first contribution - if you use a library that provides
>> Wicket components (e.g. WiQuery) then the components will contribute
>> first and then your page. This way you have the last word what CSS
>> rules to apply. I.e. you can override WiQuery's default CSS rules.
>> 2) child-component contributes after its parent - when you use
>> #renderHead(IHeaderResponse) you are in control to call
>> super.renderHead() at the top  of the method body or at the bottom.
>> Most of the time developers put it at the top. You don't have the
>> control for that for <wicket:head> though. Here Wicket contributes
>> first the parent's markup and then the child's one.
>
> When you define a simple page strategy like in my problem, you could
> have static css overrides and wants to deal with it in the css order,
> that means most specific last. And those css overrides (like
> ".main-section { margin-top: 0;}") are quite static so wicket:head is a
> perfect place for them : quick to find, quick to write, quick to modify.
> Having to move them to the java file isn't that awful, but a little more
> heavier. Plus in Wicket 1.5 I don't have CssContentHeaderItem so the UA
> will get a css link for each contribution, and that is very bad.
>
> We were using WiQuery in previous versions of our product, back then we
> served a global css for wiquery component. I've just search how we were
> dealing with WiQuery css but can't find anything. Indeed the last
> WiQuery jar we used, the 1.2.3 version, don't contains any .css file ?
> Anyway we have lots of shared components, but we do have a common
> abstract class for each application, and so we are able to serve a
> common css file.
>
>> In org.apache.wicket.markup.renderStrategy.AbstractHeaderRenderStrategy#get()
>> method there is intentionally "hard" way to switch the header
>> contribution strategy. It uses a system property named
>> 'Wicket_HeaderRenderStrategy' which value may be the fully qualified
>> name of the strategy to use.
>> org.apache.wicket.markup.renderStrategy.ParentFirstHeaderRenderStrategy
>> is the one that has been used in Wicket 1.4- and is considered
>> deprecated.
>> So you can set this system property in your MyApp#init() but I cannot
>> guarantee for how long it will work.
>
> Very good to know, thanks a lot !
>
> Not sure though how to fix the property ? Is it by inserting the
> following line in the application init() method :
> System.setProperty("Wicket_HeaderRenderStrategy","org.apache.wicket.markup.renderStrategy.ParentFirstHeaderRenderStrategy");
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Papegaaij
In reply to this post by Pierre Goiffon
Hi Pierre,

First of all, I strongly recommend you do not use a different
HeaderRenderStrategy. It is likely to get removed in future versions of Wicket
and might break libraries that depend on the normal HeaderRenderStrategy.
Second, I suggest you use Wicket 6, because consistent resource ordering in
Wicket 1.5 is nearly impossible.

HeaderResponseTest in Wicket 6 gives a good demonstration of the order of
resources. It shows that normal resources are rendered child-first, starting
at the root of the class inheritance hierarchy. If you change nothing, the
order will be B, C, A (A is last, because its header contribution is via
renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and
you should be done.

On Tuesday 24 July 2012 16:24:59 Pierre Goiffon wrote:

> > The order is now consistent - no matter if you contribute the CSS via
> > markup (<head> or <wicket:head>) or via code (in .java).
>
> I didn't understand your statement ? Particularly "the order is now
> consistent".
>
> My problem was originally about the delivery order of wicket:head
> contributions that was changed in wicket 1.5.
> Reading your statement I understand wicket:head do still render parent
> first in Wicket 1.5 but in Wicket 6 renders child first, like the other
> Java way (renderHead() right ?), so I guess I don't understand well what
> you wrote ?

In Wicket 1.5, different contributions to the header render in different ways
and the order may not be what you'd expect it to be. The intention was to
render child-first, but that proved difficult to implement, therefore header
rendering has undergone major refactoring in 6. In Wicket 6, all headers are
rendered child-first, except PriorityHeaderItems, which are rendered parent-
first.

> > Wicket defines two simple rules:
> > 1) component-first contribution - if you use a library that provides
> > Wicket components (e.g. WiQuery) then the components will contribute
> > first and then your page. This way you have the last word what CSS
> > rules to apply. I.e. you can override WiQuery's default CSS rules.
> > 2) child-component contributes after its parent - when you use
> > #renderHead(IHeaderResponse) you are in control to call
> > super.renderHead() at the top  of the method body or at the bottom.
> > Most of the time developers put it at the top. You don't have the
> > control for that for <wicket:head> though. Here Wicket contributes
> > first the parent's markup and then the child's one.

I'm not sure how this is in Wicket 1.5, but for Wicket 6, the second point is
not correct. Moving the call to super.renderHead to the end of the method only
changes the order between super- and subclass header items (the items for the
superclass are inserted at the location of the super call). <wicket:head> is
rendered child-first (not parent first), just as all other header items.

Best regards,
Emond

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Papegaaij
In reply to this post by Pierre Goiffon
Hi Pierre,

First of all, I strongly recommend you do not use a different
HeaderRenderStrategy. It is likely to get removed in future versions of Wicket
and might break libraries that depend on the normal HeaderRenderStrategy.
Second, I suggest you use Wicket 6, because consistent resource ordering in
Wicket 1.5 is nearly impossible.

HeaderResponseTest in Wicket 6 gives a good demonstration of the order of
resources. It shows that normal resources are rendered child-first, starting
at the root of the class inheritance hierarchy. If you change nothing, the
order will be B, C, A (A is last, because its header contribution is via
renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and
you should be done.

On Tuesday 24 July 2012 16:24:59 Pierre Goiffon wrote:

> > The order is now consistent - no matter if you contribute the CSS via
> > markup (<head> or <wicket:head>) or via code (in .java).
>
> I didn't understand your statement ? Particularly "the order is now
> consistent".
>
> My problem was originally about the delivery order of wicket:head
> contributions that was changed in wicket 1.5.
> Reading your statement I understand wicket:head do still render parent
> first in Wicket 1.5 but in Wicket 6 renders child first, like the other
> Java way (renderHead() right ?), so I guess I don't understand well what
> you wrote ?

In Wicket 1.5, different contributions to the header render in different ways
and the order may not be what you'd expect it to be. The intention was to
render child-first, but that proved difficult to implement, therefore header
rendering has undergone major refactoring in 6. In Wicket 6, all headers are
rendered child-first, except PriorityHeaderItems, which are rendered parent-
first.

> > Wicket defines two simple rules:
> > 1) component-first contribution - if you use a library that provides
> > Wicket components (e.g. WiQuery) then the components will contribute
> > first and then your page. This way you have the last word what CSS
> > rules to apply. I.e. you can override WiQuery's default CSS rules.
> > 2) child-component contributes after its parent - when you use
> > #renderHead(IHeaderResponse) you are in control to call
> > super.renderHead() at the top  of the method body or at the bottom.
> > Most of the time developers put it at the top. You don't have the
> > control for that for <wicket:head> though. Here Wicket contributes
> > first the parent's markup and then the child's one.

I'm not sure how this is in Wicket 1.5, but for Wicket 6, the second point is
not correct. Moving the call to super.renderHead to the end of the method only
changes the order between super- and subclass header items (the items for the
superclass are inserted at the location of the super call). <wicket:head> is
rendered child-first (not parent first), just as all other header items.

Best regards,
Emond

Resent my mail, because the first one seem to have gotten lost somewhere.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Pierre Goiffon
Le 26/07/2012 10:29, Emond Papegaaij a écrit :
> Hi Pierre,

Hi Edmond, thanks for your answer !

> First of all, I strongly recommend you do not use a different
> HeaderRenderStrategy.

Yes, Martin made it very clear that ParentFirstHeaderRenderStrategy is
deprecated.

> Second, I suggest you use Wicket 6, because consistent resource ordering in
> Wicket 1.5 is nearly impossible.

Reading this made me smile : we use Wicket for a while now, and
upgrading major versions was almost always painfull. The most difficult
time we add was with the migration to 1.5... So I don't think just a few
week after fixing our first version using Wicket 1.5 and still having to
deal with bugs related to the migration, my team would agreed to upgrade
to Wicket 6, that is still in beta stage :)

For now on we dealt with the resource order problem mainly using a
custom implementation of AbstractResourceDependentResourceReference.

> HeaderResponseTest in Wicket 6 gives a good demonstration of the order of
> resources. It shows that normal resources are rendered child-first, starting
> at the root of the class inheritance hierarchy. If you change nothing, the
> order will be B, C, A (A is last, because its header contribution is via
> renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and
> you should be done.

Where can I find this HeaderResponseTest class ? I don't have it in the
wicket-core 6.0.0-beta3 avalaible via Maven ?
Is it this one :
http://svn.apache.org/repos/asf/wicket/trunk/wicket-core/src/test/java/org/apache/wicket/markup/html/internal/HeaderResponseTest.java

In Wicket 1.5 if I do nothing, resources contributed in renderHead()
would be rendered in this order : C, B, A.
I'm surprised the order would be B, C, A in Wicket 6 ? Why so ?

In my exemple I need to define 2 priorities, because the css that was in
the B page wicket:head needs to be before the one in page C, and the css
linked in page A must be the first resource to be rendered. Could
PriorityHeaderItem answer this need ?

> In Wicket 6, all headers are
> rendered child-first, except PriorityHeaderItems, which are rendered parent-
> first.

I see that in the PriorityHeaderItem Javadoc. Does that means if I add a
PriorityHeaderItem in page A, and another in page B, the one in page A
(parent page) will be rendered before page B (child page) ?


Another question : can you confirm me there are no equivalent in Wicket
1.5 for the Wicket 6 CssContentHeaderItem ? Said otherwise, in Wicket
1.5 can I serve content in java directly in the head ? I don't want
every css contributions to be added with link tags and makes the
browsers do one more download...
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Martin Grigorov-4
On Thu, Jul 26, 2012 at 8:26 PM, Pierre Goiffon
<[hidden email]> wrote:

> Le 26/07/2012 10:29, Emond Papegaaij a écrit :
>> Hi Pierre,
>
> Hi Edmond, thanks for your answer !
>
>> First of all, I strongly recommend you do not use a different
>> HeaderRenderStrategy.
>
> Yes, Martin made it very clear that ParentFirstHeaderRenderStrategy is
> deprecated.
>
>> Second, I suggest you use Wicket 6, because consistent resource ordering in
>> Wicket 1.5 is nearly impossible.
>
> Reading this made me smile : we use Wicket for a while now, and
> upgrading major versions was almost always painfull. The most difficult
> time we add was with the migration to 1.5... So I don't think just a few
> week after fixing our first version using Wicket 1.5 and still having to
> deal with bugs related to the migration, my team would agreed to upgrade
> to Wicket 6, that is still in beta stage :)
>
> For now on we dealt with the resource order problem mainly using a
> custom implementation of AbstractResourceDependentResourceReference.
>
>> HeaderResponseTest in Wicket 6 gives a good demonstration of the order of
>> resources. It shows that normal resources are rendered child-first, starting
>> at the root of the class inheritance hierarchy. If you change nothing, the
>> order will be B, C, A (A is last, because its header contribution is via
>> renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and
>> you should be done.
>
> Where can I find this HeaderResponseTest class ? I don't have it in the
> wicket-core 6.0.0-beta3 avalaible via Maven ?
> Is it this one :
> http://svn.apache.org/repos/asf/wicket/trunk/wicket-core/src/test/java/org/apache/wicket/markup/html/internal/HeaderResponseTest.java
>
> In Wicket 1.5 if I do nothing, resources contributed in renderHead()
> would be rendered in this order : C, B, A.
> I'm surprised the order would be B, C, A in Wicket 6 ? Why so ?
>
> In my exemple I need to define 2 priorities, because the css that was in
> the B page wicket:head needs to be before the one in page C, and the css
> linked in page A must be the first resource to be rendered. Could
> PriorityHeaderItem answer this need ?
>
>> In Wicket 6, all headers are
>> rendered child-first, except PriorityHeaderItems, which are rendered parent-
>> first.
>
> I see that in the PriorityHeaderItem Javadoc. Does that means if I add a
> PriorityHeaderItem in page A, and another in page B, the one in page A
> (parent page) will be rendered before page B (child page) ?
>
>
> Another question : can you confirm me there are no equivalent in Wicket
> 1.5 for the Wicket 6 CssContentHeaderItem ? Said otherwise, in Wicket
> 1.5 can I serve content in java directly in the head ? I don't want
> every css contributions to be added with link tags and makes the
> browsers do one more download...

https://github.com/apache/wicket/blob/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/markup/html/internal/HeaderResponse.java#L59

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Papegaaij
In reply to this post by Pierre Goiffon
On Thursday 26 July 2012 19:26:36 Pierre Goiffon wrote:

> Le 26/07/2012 10:29, Emond Papegaaij a écrit :
> > Second, I suggest you use Wicket 6, because consistent resource ordering
> > in
> > Wicket 1.5 is nearly impossible.
>
> Reading this made me smile : we use Wicket for a while now, and
> upgrading major versions was almost always painfull. The most difficult
> time we add was with the migration to 1.5... So I don't think just a few
> week after fixing our first version using Wicket 1.5 and still having to
> deal with bugs related to the migration, my team would agreed to upgrade
> to Wicket 6, that is still in beta stage :)

Wicket 6 final won't take long. As far as I know, no serious issues have been
reported against beta 3, which makes it the last beta. The next release will
probably be 6.0.0.

> For now on we dealt with the resource order problem mainly using a
> custom implementation of AbstractResourceDependentResourceReference.
>
> > HeaderResponseTest in Wicket 6 gives a good demonstration of the order of
> > resources. It shows that normal resources are rendered child-first,
> > starting at the root of the class inheritance hierarchy. If you change
> > nothing, the order will be B, C, A (A is last, because its header
> > contribution is via renderHead). To move A to the front, you wrap it in a
> > PriorityHeaderItem, and you should be done.
>
> Where can I find this HeaderResponseTest class ? I don't have it in the
> wicket-core 6.0.0-beta3 avalaible via Maven ?
> Is it this one :
> http://svn.apache.org/repos/asf/wicket/trunk/wicket-core/src/test/java/org/a
> pache/wicket/markup/html/internal/HeaderResponseTest.java

Wicket moved to git some time ago. The testcase I was refering to is:
https://github.com/apache/wicket/blob/master/wicket-
core/src/test/java/org/apache/wicket/markup/head/HeaderResponseTest.java
 
> In Wicket 1.5 if I do nothing, resources contributed in renderHead()
> would be rendered in this order : C, B, A.
> I'm surprised the order would be B, C, A in Wicket 6 ? Why so ?

I'm not sure about the Wicket 1.5 ordering, but in Wicket 6, header items are
rendered child-first in the component hierarchy. For every component,
<wicket:head> is rendered first, followed by the header contributions in the
Java code. Within a component's class hierarchy, rendering starts at the base
class (as long as you put the super call at the top).

> In my exemple I need to define 2 priorities, because the css that was in
> the B page wicket:head needs to be before the one in page C, and the css
> linked in page A must be the first resource to be rendered. Could
> PriorityHeaderItem answer this need ?
>
> > In Wicket 6, all headers are
> > rendered child-first, except PriorityHeaderItems, which are rendered
> > parent- first.
>
> I see that in the PriorityHeaderItem Javadoc. Does that means if I add a
> PriorityHeaderItem in page A, and another in page B, the one in page A
> (parent page) will be rendered before page B (child page) ?

You seem to be confusing class inheritance with the component hierarchy. There
is no component hierarchy between pages, only class inhertance. Header items
are rendered top-down in the class inheritance chain. The reason that you will
need PriorityHeaderItem for the resource from page A, is that you contribute
it from Java, and it will therefore end up after the wicket:head
contributions.

But all this is not relevant if you are using Wicket 1.5. In Wicket 1.5, there
are no HeaderItems. Some rendering is done via special markup containers, some
rendering is done via IHeaderResponse, some directly to the response. This is
what makes it difficult to get the order of rendered items right. Rendering
all contributions via IHeaderResponse does make it a lot easier. By default,
Wicket renders the items in the order they were added to the IHeaderResponse
(mostly child-first in the component hierarchy, starting at the base class in
the inheritance chain). It has methods to render inline css. You can also use
a decorator to collect items and sort them, this is what WiQuery does to get
javascript files in the right order.


Best regards,
Emond

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Pierre Goiffon
In reply to this post by Martin Grigorov-4
Le 26/07/2012 20:54, Martin Grigorov a écrit :
>> Another question : can you confirm me there are no equivalent in Wicket
>> 1.5 for the Wicket 6 CssContentHeaderItem
>
> https://github.com/apache/wicket/blob/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/markup/html/internal/HeaderResponse.java#L59

Thanks Martin, I shouldn't have missed that :/
It's a correct workaround for my specific problem with a hierarchy of 3
pages !

When serving the css in page B and C with IHeaderResponse#renderCSS()
they are correctly inserted after the main css that is added in
renderhead() method in page A. Plus B and C are inserted in the correct
order.

When serving the static css of page B and C with render:head as it used
to be, they are served in the correct order (B then C) but before the
page A main CSS.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Pierre Goiffon
In reply to this post by Papegaaij
Hello,

> Wicket 6 final won't take long.

Good to know !

> I'm not sure about the Wicket 1.5 ordering, but in Wicket 6, header items are
> rendered child-first in the component hierarchy. For every component,
> <wicket:head> is rendered first, followed by the header contributions in the
> Java code. Within a component's class hierarchy, rendering starts at the base
> class (as long as you put the super call at the top).
(...)
> You seem to be confusing class inheritance with the component hierarchy. There
> is no component hierarchy between pages, only class inhertance. Header items
> are rendered top-down in the class inheritance chain. The reason that you will
> need PriorityHeaderItem for the resource from page A, is that you contribute
> it from Java, and it will therefore end up after the wicket:head
> contributions.

Well understood for the rendering order in both cases (components
hierarchy and class inheritance), thanks thanks to your very complete
summary !

But one more question though : why rendering wicket:head (in the markup
file) contributions before renderHead() (in the java file) contributions ?
Seems to me that what you'll put in wicket:head will certainly be some
king of static code, like the css in my problem (so like this :
.myclass{ padding: 0;} or $(document).ready(function(){
$("#login").focus();});). This code could need some library (JQuery for
exemple), and you'll serve that resource using a ResourceReference so
using renderHead() right ? If wicket:head is served before renderHead()
then you'll have a problem...
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

Papegaaij
On Monday 30 July 2012 18:18:46 Pierre Goiffon wrote:
> But one more question though : why rendering wicket:head (in the markup
> file) contributions before renderHead() (in the java file) contributions ?
> Seems to me that what you'll put in wicket:head will certainly be some
> king of static code, like the css in my problem (so like this :
> .myclass{ padding: 0;} or $(document).ready(function(){
> $("#login").focus();});). This code could need some library (JQuery for
> exemple), and you'll serve that resource using a ResourceReference so
> using renderHead() right ? If wicket:head is served before renderHead()
> then you'll have a problem...

With these things you just have to make a decision. Both orders are equally
valid. You use wicket:head for minor adjustments in styling, others use
wicket:head to contribute the css files and do the adjustments in renderHead.
The idea was, that with this order, it is always possible to override any
static wicket:head contribution from the Java code. Personally, I try to avoid
wicket:head as much as possible and render everything from renderHead. This
gives you the most flexibility.

Best regards,
Emond

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: renderHead() / wicket:head page / component order

pgoiffon.wicket
Le 31/07/2012 08:33, Emond Papegaaij a écrit :

>> But one more question though : why rendering wicket:head (in the markup
>> file) contributions before renderHead() (in the java file) contributions ?
>
> With these things you just have to make a decision. Both orders are equally
> valid. You use wicket:head for minor adjustments in styling, others use
> wicket:head to contribute the css files and do the adjustments in renderHead.
> The idea was, that with this order, it is always possible to override any
> static wicket:head contribution from the Java code. Personally, I try to avoid
> wicket:head as much as possible and render everything from renderHead. This
> gives you the most flexibility.

Right :)

Many thanks for all your answers !

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]