I'll let Emond to answer you. On Tue, Jul 24, 2012 at 5:24 PM, Pierre Goiffon <[email protected]> wrote: > 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: [email protected] > For additional commands, e-mail: [email protected] >
-- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
