[
https://issues.apache.org/jira/browse/WICKET-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071646#comment-13071646
]
Abul Fayes commented on WICKET-1134:
------------------------------------
@Juergen: I have written some simple test code to test out what you said and it
turns out you are right. Child pages that extend a base page use the same html
markup, for some reason I believed otherwise.
In that case the abstract component technique is fine and perhaps an elegant
solution. The multiple child/extend functionality I guess will not add much in
the way of extra functionality but perhaps make it clear which areas are/can be
overridden. The drawback with multiple child/extend is however that it requires
extra coding e.g. creating the extra html pages which could be many, therefore
If both approaches were available I would probably prefer the abstract
technique anyway! Plus content areas/components can be made 'optional' to
override if the getComponent method is not abstract, whereas with the multiple
child/extend this would require extra tag semantics.
I have been having fun with Wicket the past few weeks whilst going through
Wicket In Action. After reading 'Composing you pages' chapter 7, I felt that
having 1 child/extend was to restrictive for real world needs which is what led
me to search the net and find this issue. The chapter addresses this drawback
by discussing panel swapping based on link actions which is very messy if you
have many pages and also the URL does not change. The chapter could definitely
be improved by illustrating the abstract method technique.
> Multiple abstract/implement tags instead of child/extend
> --------------------------------------------------------
>
> Key: WICKET-1134
> URL: https://issues.apache.org/jira/browse/WICKET-1134
> Project: Wicket
> Issue Type: New Feature
> Components: wicket-core
> Affects Versions: 1.3.0-rc1
> Reporter: Stefan Fussenegger
> Assignee: Igor Vaynberg
> Priority: Minor
> Fix For: 1.5-M2.1
>
> Attachments: wicket-1134.patch, wicket-abstract-implement.patch
>
>
> The current implementation of wicket:child and wicket:extend only allows for
> a single extension per subpage. However, this restriction is neither mandated
> by java class hierarchy nor by any other reason. Therefore, it should be
> possible to extend the current implementation to support multiple 'abstract'
> sections, just like abstract methods in java classes. This could be done by
> replacing
> <wicket:child>
> <wicket:extend>
> some content
> </wicket:extend>
> </wicket:child>
> with
> <wicket:abstract id="foo">
> <wicket:implement id="foo">
> some content
> </wicket:extend>
> </wicket:child>
> (new names have been suggested in
> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html)
> A possible application is a layout with two columns, e.g. a header with
> navigation, a left column with sub-navigation and a right column with content
> (where the sub-navigation may change depending on the section. In deed, this
> is already possible using panels or similar means. However, it would allow to
> take advantage of markup inheritance only:
> BasePage extens WebPage:
> <div wicket:id="links>[some nav links here]</div>
> <div><wicket:abstract id="subNavigation">[left navigation goes
> here]</wicket:abstract></div>
> <div><wicket:abstract id="content">[content goes here]</wicket:abstract</div>
> SectionPage extends BasePage:
> <wicket:implement id="subNavigation">[sub navigation links
> here]</wicket:implement>
> FooPage extends SectionPage:
> <wicket:implement id="content">[content goes here]</wicket:implement>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
