readering strategy of the 'head' section

[Harrie Hazewinkel <hh...@gmail.com>]

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
hhazewinkel@gmail.com





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: readering strategy of the 'head' section

[Dan Retzlaff <dr...@gmail.com>]

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.

On Sun, Mar 24, 2013 at 11:22 PM, Harrie Hazewinkel
<hh...@gmail.com>wrote:

> Hi Dan,
>
> Thanks for the example.
>
> On Mar 24, 2013, at 7:26 PM, Dan Retzlaff <dr...@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 be configured
> > through IJavaScriptLibrarySettings as shown here.
>
> Is that still the case when you have components that use different
> versions of
> jQuery, because the components come from different libraries?
> Guess not, but will give it a try.
>
>
>
>
> Harrie
> hhazewinkel@gmail.com
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: readering strategy of the 'head' section

[Harrie Hazewinkel <hh...@gmail.com>]

Hi Dan,

Thanks for the example.

On Mar 24, 2013, at 7:26 PM, Dan Retzlaff <dr...@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 be configured
> through IJavaScriptLibrarySettings as shown here.

Is that still the case when you have components that use different versions of
jQuery, because the components come from different libraries?
Guess not, but will give it a try.




Harrie
hhazewinkel@gmail.com





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: readering strategy of the 'head' section

[Dan Retzlaff <dr...@gmail.com>]

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
<hh...@gmail.com>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
> hhazewinkel@gmail.com
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: readering strategy of the 'head' section

[Harrie Hazewinkel <hh...@gmail.com>]

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
hhazewinkel@gmail.com





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: readering strategy of the 'head' section

[Martin Grigorov <mg...@apache.org>]

Hi,


On Thu, Mar 21, 2013 at 10:51 AM, Harrie Hazewinkel
<hh...@gmail.com>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 <mg...@apache.org> 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 <
> hhazewinkel@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
> >> hhazewinkel@gmail.com
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com <http://jweekend.com/>
>
> Harrie
> hhazewinkel@gmail.com
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


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

Re: readering strategy of the 'head' section

[Harrie Hazewinkel <hh...@gmail.com>]

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.

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.



Harrie


On Mar 21, 2013, at 9:20 AM, Martin Grigorov <mg...@apache.org> 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 <hh...@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
>> hhazewinkel@gmail.com
>> 
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>> 
>> 
> 
> 
> -- 
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com <http://jweekend.com/>

Harrie
hhazewinkel@gmail.com





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: readering strategy of the 'head' section

[Martin Grigorov <mg...@apache.org>]

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 <hh...@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
> hhazewinkel@gmail.com
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


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