Hi Dan,
Thanks for the example.
On Mar 24, 2013, at 7:26 PM, Dan Retzlaff dretzl...@gmail.com wrote:
Re: duplicate/conflicting contributions, Wicket automatically de-dups
header contributions. See HeaderItem#getRenderTokens(). Since Wicket itself
pulls in JQuery, your app's use of it should
I've managed to avoid dealing with multiple versions of jQuery on the same
page. That sounds like a Bad Idea, and probably not necessary since in my
experience jQuery does a good job being backwards compatible. But if you
really must, http://api.jquery.com/jQuery.noConflict/ may be your ticket.
Hallo,
I understand that potentially things could be overridden at a lower child.
Although,
you can have the same in the opposite direction. Same counts for bugs, but the
beauty would be the flexibility I would say.
On top of that, I am wondering how others use it than in combination with
We add a site-wide IHeaderContributor in Application#init()
using getHeaderContributorListenerCollection(). Our initial implementation
used wicket:head contributions as you do. This became difficult to
maintain when we had multiple top-level pages. (Your site has only one
top-level page?) We also
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
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
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
