Hi,Since the thread on multiple <wicket:child/> support is insanely long I'm going to try make a clear and concise summary of what has been proposed and what the arguments for and against were. Bear with me. :-)
1. What is proposed?Currently Wicket supports *merging* of markup on a base page with markup on an a page which extends it through the <wicket:child/> and <wicket:extend/> tags. When the child page is rendered, the markup of the base page is used, but the <wicket:child>...</wicket:child> part is *replaced* by what is between the <wicket:extend>...</wicket:extend> part in the child page (thus *merging* the two). Currently only 1 child part is allowed in the base page and only 1 extend part in allowed in the child page.
The request is to allow multiple such parts to be replaced during the murge. To know which part must be replaced with which, it is proposed that the above tags have an id attribute to match them pair by pair.
As Chris Colman aptly put it: the *only* thing being requested is to remove the limitation of n=1 pairs and to allow n>1 pairs of parts to replaced during the merge.
NOTE:This has been called markup inheritance (as suggested by the names child and extend), but in the thread has also been compared to abstract methods and implementing them. I recommend not using any analogies to confuse matters and just seeing it for what it is, a relaxation of the constraint that n=1 during merge.
NOTE 2:A patch by Stefan Fussenegger which implements this feature request has been submitted to the Wicket JIRA. In his patch he used different tags names, but the behavior for the case n=1 is exactly that of the current feature.
2. Is <wicket:child/> even necessary?No, it's a convenience feature. You can get the same effect by making a BasePage.html, BasePage.java, ChildPage.java, ChildPanel.java and ChildPanel.html, and using an abstract method or onBeforeRender (see the thread). If you don't like child/extend, you don't have to use it.
3. Arguments *for* the change.It is (very) convenient (same reason as for the current child/extend) and does not change how current Wicket applications work (i.e., it is 100% backward compatible). Only when you *add* an extra identifier attribute and put in multiple child/extends pairs, are you using the new feature. If you don't like it, you don't have to use it.
4. Arguments *against* the change.
I saw only a few arguments against the change:
a) It can already be done using
- wicket panels/fragments + abstract methods
- wicket panels/fragments + onBeginRender
Apart from the obvious problems with the above methods (calling an
overridable method from the constructor or extra IMHO non-intuitive
boilerplate code), I do not see how this is an argument against just
*removing an arbitrary restriction* on <wicket:child />.
b) No more extra tags! We already have enough tags in Wicket! In principle, no extra tags required; there is *no* collision with the current <wicket:child> and <wicket:extend> tags. But if it is done with other tags (I would suggest deprecating child/extend in the next version of wicket then), you don't have to use these extra tags.
c) It creates a mess: all the components contained in any of the extend parts are added to the child page in the constructor: this can cause name collisions and a huge number of components to be added, which is bad.
But I do not see the difference between this and any other normal page where you use components. A bunch of them are added to the page itself, and another bunch are separated into components. It is up to the developer to choose how to do this.
A (real world) demonstration of the two different *use cases*, namely the reason why you would use a panel for one and a wicket/child for another, can be seen on the following page I recently built:
http://www.denherdervarga.com/programmaOn the left there is a menu, in the center the content, on the right some context information for the page.
The center (the content) is a clear use case of the current child/extend.The left is a panel, implemented with an abstract method getMenu(String id) on the base class. The MainMenu panel is reused across pages, and can change (in the admin section of the site the getMenu() method is overriden to return a completely different AdminMenu).
The right is currently a <wicket:fragment> with an abstract method on the base page. *But this a case where I would have preferred another child/extend.* The fact that the content is on the right is *PURE LAYOUT*. If I had chosen another layout where it was at the bottom of the content, it would have been *in* the content part. I would have had to add all the top level components to the page in the constructor, and I would have had to make sure that no wicket:id collisions occurred, *IN EXACTLY THE SAME WAY* as with multiple child/extends. Futhermore, there is no point in making a panel out of it, because it is specific to this page, and I'll *never* reuse it. Finally, in this (specific) case there is not even a wicket component in it, so if there would have been multiple child/extends, I could have done it with *zero* java code!
5) Conclusion
In conclusion, the proposed change:
- is useful
- does not have to be used if you don't like it
- is 100% backwards compatible
- it introduces no new tags (if using child/extends)
I also do not see any real issues. This is purely about merging markup
when rendering, I think the analogies between this and OO concepts in
Java are clouding the issue!
Regards, Sebastiaan
smime.p7s
Description: S/MIME Cryptographic Signature
