[
https://issues.apache.org/jira/browse/WICKET-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540657
]
Bruno Borges commented on WICKET-1134:
--------------------------------------
I think this improvement is just more of a way to "override" components
declared in markups of a super class. Because this is what really happens.
Let's check your example:
In the BasePage, there are two fragments:
- subNavigation
- content
What about if I want to have a fragment in SectionPage with id "content", but
not related with that content from BasePage? You see, the concept of
extend/child, is the same as in OOP's inheritance.
If you declare:
class BasePage ... {
protected Object someProperty;
}
And:
class SectionPage extends BasePage {
protected Object someProperty;
}
What happens here is that SectionPage.someProperty does NOT
override/implement/whatever-you-wanna-call, BasePage.someProperty.
I'm worry about people trying to subclass some WebMarkupContainer, and having
to be carefully with components ids, just to _not_ match something that would
generate strange output.
If in SectionPage I add some component with "content" id, what would happen?
Throw a message: "You cannot use this id because there's an abstract method in
BasePage.html". This would lead to code in HTML that has NO reference in Java.
This means that: what you don't see in Java, it might be possible to exist in
the HTML.
What I like most of Wicket, is its ability to let me take control of
everything, just from one source: Java. But if I'm going to be obligated of
taking care of what people declare in HTML files that I can't see in some Java
source code, then I will reconsider my framework's choice.
Regards
> 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
> Reporter: Stefan Fußenegger
> Priority: Minor
> Attachments: 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.
-
You can reply to this email to add a comment to the issue online.
