Hi,

The change to use ChildFirstHeaderRenderStrategy by default was introduced
in 1.5.0. The usage of a system property to switch the strategy was
intentional - to make it harder. Wicket developers believe that
ParentFirstHeaderRenderStrategy should not be used.
But there was a bug that <wicket:head> didn't followed the rules. In 6.0
both Java and HTML contributions became more consistent.
Additionally now the application developer can promote the HeaderItems by
wrapping them in PriorityHeaderItem. Yet another way is to use
custom org.apache.wicket.settings.IResourceSettings#setHeaderItemComparator.

What is your usecase to prefer ParentFirstHeaderRenderStrategy ?






On Thu, Mar 21, 2013 at 9:55 AM, Harrie Hazewinkel <hhazewin...@gmail.com>wrote:

> Hello,
>
>
> I recently upgraded from wicket 1.5 to 6. This is mostly not a real
> problem. However,
> I believe that the complete change of the header render strategy is not
> compatible.
> This is also mentioned in various places. Wicket 1.5 may not have been
> consistent
> in for the header rendering, but why not trying to maintain some easy
> compatibility?
>
>
> As Wicket 1.5 used a parent first render strategy, I can find still ways
> that Wicket 6
> can support this. Why not supporting this in the applications settings
> either?
>
> It eases upgrades of big projects and overcomes a way that there is a lot
> of code
> to be added in Java. Wondering if more people believe a better support for
> the
> ParentFirstHeaderRenderStrategy is wished for instaed of adding renderHead
> code all over.
>
>
> Or do I miss something?
>
>
> Harrie
> hhazewin...@gmail.com
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


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

Reply via email to