[
https://issues.apache.org/jira/browse/WICKET-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540657
]
miojo edited comment on WICKET-1134 at 11/6/07 7:01 PM:
---------------------------------------------------------------
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. What goes in child, is from
the subclass. Period.
In Java, if you declare:
class BasePage ... {
protected Object someProperty;
}
class SectionPage extends BasePage {
protected Object someProperty;
}
What happens here is that SectionPage.someProperty does NOT
override/implement/whatever-you-wanna-call, BasePage.someProperty. What you
want to do in HTML would be this in Java.
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 (like Label) with "content" id, what
would happen? Throw a message: "You cannot use this id because there's an
abstract 'content' markup in BasePage.html". This would lead to code in HTML
that has NO reference within it's Java class.
This means that: what you don't see in Java, it *might* be possible to exist in
the HTML.
And 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
was (Author: miojo):
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.
