Re: renderHead() / wicket:head page / component order
Le 31/07/2012 08:33, Emond Papegaaij a écrit : But one more question though : why rendering wicket:head (in the markup file) contributions before renderHead() (in the java file) contributions ? With these things you just have to make a decision. Both orders are equally valid. You use wicket:head for minor adjustments in styling, others use wicket:head to contribute the css files and do the adjustments in renderHead. The idea was, that with this order, it is always possible to override any static wicket:head contribution from the Java code. Personally, I try to avoid wicket:head as much as possible and render everything from renderHead. This gives you the most flexibility. Right :) Many thanks for all your answers ! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: renderHead() / wicket:head page / component order
On Monday 30 July 2012 18:18:46 Pierre Goiffon wrote:
But one more question though : why rendering wicket:head (in the markup
file) contributions before renderHead() (in the java file) contributions ?
Seems to me that what you'll put in wicket:head will certainly be some
king of static code, like the css in my problem (so like this :
.myclass{ padding: 0;} or $(document).ready(function(){
$(#login).focus();});). This code could need some library (JQuery for
exemple), and you'll serve that resource using a ResourceReference so
using renderHead() right ? If wicket:head is served before renderHead()
then you'll have a problem...
With these things you just have to make a decision. Both orders are equally
valid. You use wicket:head for minor adjustments in styling, others use
wicket:head to contribute the css files and do the adjustments in renderHead.
The idea was, that with this order, it is always possible to override any
static wicket:head contribution from the Java code. Personally, I try to avoid
wicket:head as much as possible and render everything from renderHead. This
gives you the most flexibility.
Best regards,
Emond
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: renderHead() / wicket:head page / component order
Hello,
Wicket 6 final won't take long.
Good to know !
I'm not sure about the Wicket 1.5 ordering, but in Wicket 6, header items are
rendered child-first in the component hierarchy. For every component,
wicket:head is rendered first, followed by the header contributions in the
Java code. Within a component's class hierarchy, rendering starts at the base
class (as long as you put the super call at the top).
(...)
You seem to be confusing class inheritance with the component hierarchy. There
is no component hierarchy between pages, only class inhertance. Header items
are rendered top-down in the class inheritance chain. The reason that you will
need PriorityHeaderItem for the resource from page A, is that you contribute
it from Java, and it will therefore end up after the wicket:head
contributions.
Well understood for the rendering order in both cases (components
hierarchy and class inheritance), thanks thanks to your very complete
summary !
But one more question though : why rendering wicket:head (in the markup
file) contributions before renderHead() (in the java file) contributions ?
Seems to me that what you'll put in wicket:head will certainly be some
king of static code, like the css in my problem (so like this :
.myclass{ padding: 0;} or $(document).ready(function(){
$(#login).focus();});). This code could need some library (JQuery for
exemple), and you'll serve that resource using a ResourceReference so
using renderHead() right ? If wicket:head is served before renderHead()
then you'll have a problem...
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: renderHead() / wicket:head page / component order
Le 26/07/2012 20:54, Martin Grigorov a écrit : Another question : can you confirm me there are no equivalent in Wicket 1.5 for the Wicket 6 CssContentHeaderItem https://github.com/apache/wicket/blob/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/markup/html/internal/HeaderResponse.java#L59 Thanks Martin, I shouldn't have missed that :/ It's a correct workaround for my specific problem with a hierarchy of 3 pages ! When serving the css in page B and C with IHeaderResponse#renderCSS() they are correctly inserted after the main css that is added in renderhead() method in page A. Plus B and C are inserted in the correct order. When serving the static css of page B and C with render:head as it used to be, they are served in the correct order (B then C) but before the page A main CSS. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: renderHead() / wicket:head page / component order
Hi Pierre, First of all, I strongly recommend you do not use a different HeaderRenderStrategy. It is likely to get removed in future versions of Wicket and might break libraries that depend on the normal HeaderRenderStrategy. Second, I suggest you use Wicket 6, because consistent resource ordering in Wicket 1.5 is nearly impossible. HeaderResponseTest in Wicket 6 gives a good demonstration of the order of resources. It shows that normal resources are rendered child-first, starting at the root of the class inheritance hierarchy. If you change nothing, the order will be B, C, A (A is last, because its header contribution is via renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and you should be done. On Tuesday 24 July 2012 16:24:59 Pierre Goiffon wrote: 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 ? In Wicket 1.5, different contributions to the header render in different ways and the order may not be what you'd expect it to be. The intention was to render child-first, but that proved difficult to implement, therefore header rendering has undergone major refactoring in 6. In Wicket 6, all headers are rendered child-first, except PriorityHeaderItems, which are rendered parent- first. 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. I'm not sure how this is in Wicket 1.5, but for Wicket 6, the second point is not correct. Moving the call to super.renderHead to the end of the method only changes the order between super- and subclass header items (the items for the superclass are inserted at the location of the super call). wicket:head is rendered child-first (not parent first), just as all other header items. Best regards, Emond - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: renderHead() / wicket:head page / component order
Hi Pierre, First of all, I strongly recommend you do not use a different HeaderRenderStrategy. It is likely to get removed in future versions of Wicket and might break libraries that depend on the normal HeaderRenderStrategy. Second, I suggest you use Wicket 6, because consistent resource ordering in Wicket 1.5 is nearly impossible. HeaderResponseTest in Wicket 6 gives a good demonstration of the order of resources. It shows that normal resources are rendered child-first, starting at the root of the class inheritance hierarchy. If you change nothing, the order will be B, C, A (A is last, because its header contribution is via renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and you should be done. On Tuesday 24 July 2012 16:24:59 Pierre Goiffon wrote: 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 ? In Wicket 1.5, different contributions to the header render in different ways and the order may not be what you'd expect it to be. The intention was to render child-first, but that proved difficult to implement, therefore header rendering has undergone major refactoring in 6. In Wicket 6, all headers are rendered child-first, except PriorityHeaderItems, which are rendered parent- first. 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. I'm not sure how this is in Wicket 1.5, but for Wicket 6, the second point is not correct. Moving the call to super.renderHead to the end of the method only changes the order between super- and subclass header items (the items for the superclass are inserted at the location of the super call). wicket:head is rendered child-first (not parent first), just as all other header items. Best regards, Emond Resent my mail, because the first one seem to have gotten lost somewhere. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: renderHead() / wicket:head page / component order
Le 26/07/2012 10:29, Emond Papegaaij a écrit : Hi Pierre, Hi Edmond, thanks for your answer ! First of all, I strongly recommend you do not use a different HeaderRenderStrategy. Yes, Martin made it very clear that ParentFirstHeaderRenderStrategy is deprecated. Second, I suggest you use Wicket 6, because consistent resource ordering in Wicket 1.5 is nearly impossible. Reading this made me smile : we use Wicket for a while now, and upgrading major versions was almost always painfull. The most difficult time we add was with the migration to 1.5... So I don't think just a few week after fixing our first version using Wicket 1.5 and still having to deal with bugs related to the migration, my team would agreed to upgrade to Wicket 6, that is still in beta stage :) For now on we dealt with the resource order problem mainly using a custom implementation of AbstractResourceDependentResourceReference. HeaderResponseTest in Wicket 6 gives a good demonstration of the order of resources. It shows that normal resources are rendered child-first, starting at the root of the class inheritance hierarchy. If you change nothing, the order will be B, C, A (A is last, because its header contribution is via renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and you should be done. Where can I find this HeaderResponseTest class ? I don't have it in the wicket-core 6.0.0-beta3 avalaible via Maven ? Is it this one : http://svn.apache.org/repos/asf/wicket/trunk/wicket-core/src/test/java/org/apache/wicket/markup/html/internal/HeaderResponseTest.java In Wicket 1.5 if I do nothing, resources contributed in renderHead() would be rendered in this order : C, B, A. I'm surprised the order would be B, C, A in Wicket 6 ? Why so ? In my exemple I need to define 2 priorities, because the css that was in the B page wicket:head needs to be before the one in page C, and the css linked in page A must be the first resource to be rendered. Could PriorityHeaderItem answer this need ? In Wicket 6, all headers are rendered child-first, except PriorityHeaderItems, which are rendered parent- first. I see that in the PriorityHeaderItem Javadoc. Does that means if I add a PriorityHeaderItem in page A, and another in page B, the one in page A (parent page) will be rendered before page B (child page) ? Another question : can you confirm me there are no equivalent in Wicket 1.5 for the Wicket 6 CssContentHeaderItem ? Said otherwise, in Wicket 1.5 can I serve content in java directly in the head ? I don't want every css contributions to be added with link tags and makes the browsers do one more download... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: renderHead() / wicket:head page / component order
On Thu, Jul 26, 2012 at 8:26 PM, Pierre Goiffon pierre.goif...@interview-efm.com wrote: Le 26/07/2012 10:29, Emond Papegaaij a écrit : Hi Pierre, Hi Edmond, thanks for your answer ! First of all, I strongly recommend you do not use a different HeaderRenderStrategy. Yes, Martin made it very clear that ParentFirstHeaderRenderStrategy is deprecated. Second, I suggest you use Wicket 6, because consistent resource ordering in Wicket 1.5 is nearly impossible. Reading this made me smile : we use Wicket for a while now, and upgrading major versions was almost always painfull. The most difficult time we add was with the migration to 1.5... So I don't think just a few week after fixing our first version using Wicket 1.5 and still having to deal with bugs related to the migration, my team would agreed to upgrade to Wicket 6, that is still in beta stage :) For now on we dealt with the resource order problem mainly using a custom implementation of AbstractResourceDependentResourceReference. HeaderResponseTest in Wicket 6 gives a good demonstration of the order of resources. It shows that normal resources are rendered child-first, starting at the root of the class inheritance hierarchy. If you change nothing, the order will be B, C, A (A is last, because its header contribution is via renderHead). To move A to the front, you wrap it in a PriorityHeaderItem, and you should be done. Where can I find this HeaderResponseTest class ? I don't have it in the wicket-core 6.0.0-beta3 avalaible via Maven ? Is it this one : http://svn.apache.org/repos/asf/wicket/trunk/wicket-core/src/test/java/org/apache/wicket/markup/html/internal/HeaderResponseTest.java In Wicket 1.5 if I do nothing, resources contributed in renderHead() would be rendered in this order : C, B, A. I'm surprised the order would be B, C, A in Wicket 6 ? Why so ? In my exemple I need to define 2 priorities, because the css that was in the B page wicket:head needs to be before the one in page C, and the css linked in page A must be the first resource to be rendered. Could PriorityHeaderItem answer this need ? In Wicket 6, all headers are rendered child-first, except PriorityHeaderItems, which are rendered parent- first. I see that in the PriorityHeaderItem Javadoc. Does that means if I add a PriorityHeaderItem in page A, and another in page B, the one in page A (parent page) will be rendered before page B (child page) ? Another question : can you confirm me there are no equivalent in Wicket 1.5 for the Wicket 6 CssContentHeaderItem ? Said otherwise, in Wicket 1.5 can I serve content in java directly in the head ? I don't want every css contributions to be added with link tags and makes the browsers do one more download... https://github.com/apache/wicket/blob/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/markup/html/internal/HeaderResponse.java#L59 - 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
Re: renderHead() / wicket:head page / component order
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:heads 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
Re: renderHead() / wicket:head page / component order
I'll let Emond to answer you.
On Tue, Jul 24, 2012 at 5:24 PM, Pierre Goiffon
pierre.goif...@interview-efm.com 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:heads 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
--
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
Re: renderHead() / wicket:head page / component order
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:heads 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
Re: renderHead() / wicket:head page / component order
Hi Pierre, 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. On Mon, Jul 9, 2012 at 5:16 PM, Pierre Goiffon pierre.goif...@interview-efm.com wrote: Hi, 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(), and reading https://issues.apache.org/jira/browse/WICKET-4000 I understand the reason of this choice : to be able to replace a parent contribution. But this is a big problem when you deal with css, because in your supages / panels / components you will insert specific properties that are meant to override global ones defined in the page... and to do so the css properties in the subpage / panel / component must be inserted in the head AFTER the page css declaration. 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 The only solution I see with wicket 1.5 is to create css files for the properties in page B and page C and adds them in each renderHead() using an implementation of AbstractResourceDependentResourceReference. This is just a nightmare, and impacts also the user (3 css files to download instead of 1 !). Are there any mean to do better ? If not, as I think we need both to render in the header before or after the parent, maybe there should be a method for each order ? Like renderHeadBefore() / renderHeadAfter() ? - 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
Re: renderHead() / wicket:head page / component order
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 !
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 !
- 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 ?
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).
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
renderHead() / wicket:head page / component order
Hi, 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(), and reading https://issues.apache.org/jira/browse/WICKET-4000 I understand the reason of this choice : to be able to replace a parent contribution. But this is a big problem when you deal with css, because in your supages / panels / components you will insert specific properties that are meant to override global ones defined in the page... and to do so the css properties in the subpage / panel / component must be inserted in the head AFTER the page css declaration. 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 The only solution I see with wicket 1.5 is to create css files for the properties in page B and page C and adds them in each renderHead() using an implementation of AbstractResourceDependentResourceReference. This is just a nightmare, and impacts also the user (3 css files to download instead of 1 !). Are there any mean to do better ? If not, as I think we need both to render in the header before or after the parent, maybe there should be a method for each order ? Like renderHeadBefore() / renderHeadAfter() ? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
