Hi,
On Tue, Jul 10, 2012 at 12:18 PM, Pierre Goiffon
<pierre.goif...@interview-efm.com> wrote:
> >> We recently upgrade to Wicket 1.5. One of the major concern during that
> >> migration was to deal with the new order of the header render strategy.
> >> I see this is defined in AbstractHeaderRenderStrategy#get()
> (...)
> >> For exemple I am just dealing with a problem in a page hierarchy like
> >> the one below :
> >> pageA : adds mycss.css using renderHead and a ResourceReference
> >> pageB : adds 6 lines of css to change the behavior in wicket:head
> >> pageC : adds 1 line of css to override a margin in wicket:head
>
>> There are some improvements in this area in Wicket 6.
>> Please read http://wicketinaction.com/2012/07/wicket-6-resource-management/
>> for more information. Pay attention to PriorityHeaderItem and setting
>> custom header item comparator. Header contributions from <wicket:head>
>> are represented with org.apache.wicket.markup.head.PageHeaderItem.
>
> Thanks very mutch Martin, very interesting !
> Your blog have a lots of very nice posts like this one, I'm going to
> read lots of them really carefully ! I'm very happy to find such a
> resource as documentation is not the strongest Wicket highlight !
>
> Getting back to my concern...
>
> PriorityHeaderItem is a nice answer to serve the most generic resources
> (in my exemple, mycss.css) : clean and simple.
> Looking at the Wicket 6 classes in your sample project
> (https://github.com/martin-g/blogs/tree/master/wicket6-resource-management)
> I also see a CssContentHeaderItem that allows to add CSS without adding
> a link and an extra resource to download for the UAs : cool !
That is possible since Wicket 1.2+
>
> But as a developper I still see some issues :
> - It's not very convenient to write static css in the Java code instead
> of simply leave it in the html file in a wicket:head block. In prev 1.5
> version it was a very simple way to add static client side code !
In Wicket 6 this is still valid. The only change is the order in which
the content in <wicket:head>s found in base/sub page, base/sub panels
is rendered.
The order is now consistent - no matter if you contribute the CSS via
markup (<head> or <wicket:head>) or via code (in .java).
> - Just using a PriorityHeaderItem wouldn't be enough, cause I need the
> header contribution to be in the order A / B / C. I would need to write
> a custom comparator... And it wouldn't be that nice because in my case
> page A and page B are in a different project than page C - this latter
> is the only one to be in the same project as the wicket application
> class. The custom comparator would also certainly become quite unusable,
> dealing with too many specific cases ?
If you cannot manage that in your own code then I see no way Wicket to
manage it in general way for all users...
Wicket defines two simple rules:
1) component-first contribution - if you use a library that provides
Wicket components (e.g. WiQuery) then the components will contribute
first and then your page. This way you have the last word what CSS
rules to apply. I.e. you can override WiQuery's default CSS rules.
2) child-component contributes after its parent - when you use
#renderHead(IHeaderResponse) you are in control to call
super.renderHead() at the top of the method body or at the bottom.
Most of the time developers put it at the top. You don't have the
control for that for <wicket:head> though. Here Wicket contributes
first the parent's markup and then the child's one.
>
> For the 1.5 branch a simple solution I see would be to let the
> IHeaderRenderStrategy be defined by the Wicket application class. So
> every one would be able to choose what is his most wanted preference :
> be able to override parent renderHead() methods
> (ChildFirstHeaderRenderStrategy), or have a very simple mean to insert
> cascading client side static code (ParentFirstHeaderRenderStrategy).
In org.apache.wicket.markup.renderStrategy.AbstractHeaderRenderStrategy#get()
method there is intentionally "hard" way to switch the header
contribution strategy. It uses a system property named
'Wicket_HeaderRenderStrategy' which value may be the fully qualified
name of the strategy to use.
org.apache.wicket.markup.renderStrategy.ParentFirstHeaderRenderStrategy
is the one that has been used in Wicket 1.4- and is considered
deprecated.
So you can set this system property in your MyApp#init() but I cannot
guarantee for how long it will work.
>
> I you use a ParentFirstHeaderRenderStrategy and still need to override a
> parent renderHead() in a specific component, you could still move the
> parent code to an overridable method right ? Like :
>
> parentClass {
> public void renderHeader(..) {
> doStuff();
> }
>
> public void doStuff() {
> ...
> }
> }
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
