Hello !
Le 22/07/2012 21:39, Martin Grigorov a écrit :
>>>> 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
>>
>> 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).
I didn't understand your statement ? Particularly "the order is now
consistent".
My problem was originally about the delivery order of wicket:head
contributions that was changed in wicket 1.5.
Reading your statement I understand wicket:head do still render parent
first in Wicket 1.5 but in Wicket 6 renders child first, like the other
Java way (renderHead() right ?), so I guess I don't understand well what
you wrote ?
> 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.
When you define a simple page strategy like in my problem, you could
have static css overrides and wants to deal with it in the css order,
that means most specific last. And those css overrides (like
".main-section { margin-top: 0;}") are quite static so wicket:head is a
perfect place for them : quick to find, quick to write, quick to modify.
Having to move them to the java file isn't that awful, but a little more
heavier. Plus in Wicket 1.5 I don't have CssContentHeaderItem so the UA
will get a css link for each contribution, and that is very bad.
We were using WiQuery in previous versions of our product, back then we
served a global css for wiquery component. I've just search how we were
dealing with WiQuery css but can't find anything. Indeed the last
WiQuery jar we used, the 1.2.3 version, don't contains any .css file ?
Anyway we have lots of shared components, but we do have a common
abstract class for each application, and so we are able to serve a
common css file.
> 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.
Very good to know, thanks a lot !
Not sure though how to fix the property ? Is it by inserting the
following line in the application init() method :
System.setProperty("Wicket_HeaderRenderStrategy","org.apache.wicket.markup.renderStrategy.ParentFirstHeaderRenderStrategy");
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
