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 require programmatic switches to conditionally
include various third-party analytics and customer support "chat" widget.
This is most easy accomplished for us at the application level. Here is a
snippet of this global decorator to give you an idea.
@Override
public void renderHead(IHeaderResponse response) {
response.render(StringHeaderItem.forString(
"<link rel=\"shortcut icon\" type=\"image/vnd.microsoft.icon\"
href=\"/images/favicon.ico\"/>");
response.render(JavaScriptHeaderItem.forReference(
Application.get().getJavaScriptLibrarySettings().getJQueryReference()));
response.render(Assets.BOOTSTRAP_JS);
response.render(Assets.GLOBAL_JS);
I agree with the point that each component should make its dependencies
clear in its renderHead(), but our jQuery and Bootstrap dependencies are so
pervasive that we got lazy. It makes our components less reusable across
different apps, but that is not an immediate concern for us.
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 be configured
through IJavaScriptLibrarySettings as shown here.
Dan
On Sun, Mar 24, 2013 at 10:29 AM, Harrie Hazewinkel
<[email protected]>wrote:
> 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
> jQuery.
> Typically, jQuery has some element specific javascript and css, but rely
> on the
> common jQuery (file jqeury-min.js). If now all is driven from the lower
> childs you
> cannot place the common jQuery in the toplevel page from which all pages
> inherit
> and if a lower child adds the common jQuery you may end up with multiple
> (potentailly even different versions as well).
>
> Therefore, I am curious how most people use it with jQuery as I would say
> adding a single line in the html from which pages inherit from is way
> easier then
> putting a this in Java code.
>
>
> I understand the point of view that you may try to avoid a ParentFHRS, but
> disagree that core-developers make such a choice for others. So
> deprecating it
> sounds not the way to go for me, it reduces maybe the burden of
> maintaining it
> by core developers, but for sure also reduces the flexibility of using
> Wicket.
>
>
>
> Harrie
> [email protected]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
