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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
