Hi,
On Thu, Mar 21, 2013 at 10:51 AM, Harrie Hazewinkel <[email protected]>wrote: > Hello, > > > After the upgrade to 6.x I found that the order of the headers were > reverse compared to 1.5. > This caused the com.googlecode.wicket.jquery.ui.form.datepicker.DatePicker > to fail as it did not > wanted to display the popup to pick the date in a panel. The problem was > that it depended on > common jquery that was added in a parent page. Then by using the > ParentFirstHeaderRenderStrategy > this worked again and NO other code changes were needed. > This is the use case that we see as a bad practice - a component depends on some resource but it expects that someone else will contribute it. This component is not reusable without the additional prerequisites. With ChildFirstHRS the component contributes all that it needs. The page that contains this component can override these contributions. I.e. your application may use third party components and your pages can override what these third party components contribute. With ParentFirstHRS it is the opposite - whatever you try to contribute _may_ be overridden by some third party component. In this case you will most probably have to extend the 3rd party component just to change its settings/contributions, _if_ this is possible. > > But speaking of a general usecase, I see that you can then simply follow > the page structure and panel > structure as how also the page inheritance goes and the panel inheritance > as well. Common things go > in the parent page or panel and only specifics go into the page or panel > itself. > > Also what I found was that html header elements like 'title' were not > place in the beginning of the > header anymore (which I believe is nicer to have it before javascript > includes). A title element I mostly > added in the base page of my application of which all other pages > inherited from. > > > Although, I do not understand why wicket developers (and I assume you mean > the core developers and > not those developers using the framework) do not like a parent first > strategy, I simply would say…. > Wicket is modular and pluggable in many ways. Why would wicket developers > force this to there users by > not allowing it? Given the framework supports this almost already, leave > this as a choice to the users to > select it as what would be the best for them. > > Of course, a default implementation can be the preferred way of the wicket > developers, but allowing users > there own choice. > Generally we are trying to expose such things as settings. But in this case we try to avoid bug reports for ParentFHRS. It is considered deprecated but it is still there for cases like yours where some bigger refactoring is needed before being able to switch ot ChildFHRS. > > > > Harrie > > > On Mar 21, 2013, at 9:20 AM, Martin Grigorov <[email protected]> wrote: > > > 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 < > [email protected]>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 > >> [email protected] > >> > >> > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > > > -- > > Martin Grigorov > > jWeekend > > Training, Consulting, Development > > http://jWeekend.com <http://jweekend.com/> > > Harrie > [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com <http://jweekend.com/>
