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-

> > 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,

To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to