Let me paste what I commented in 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. 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*
Now, Stefan, let me reply your last comment in the issue:
*No, ids used with abstract/implement are completely different from
wicket:ids ... they are only used to construct (i.e. merge ... or link) the
markup, so it is perfectly legal to use <div wicket:id="foo"> when there is
a <wicket:abstract id="foo"> somewhere, as they won't be related. Therefore,
no of the concerns you mention would apply, as ...
The concept of abstract/implement is the same as in OOP's inheritance. What
goes in child, is from the subclass! Exclamation mark! ;)*
Ok, you propose a new attribute for extend/abstract, child/implement pair
tags. And you say that this id attribute will NOT have any relationship with
wicket:id. Well, isn't this something... scary? The documentation will have
to take care of this, because it will _not_ be intuitive.
Regards,
On Nov 7, 2007 10:15 AM, Stefan Fußenegger <[EMAIL PROTECTED]>
wrote:
>
> Hi Mats, let me try to explain what Chris and I see here that others don't
> -
> may it be there or not ;)
>
> You can of course do everything with panels that could be done with
> multiple
> abstract sections (may they be named wicket:child or wicket:abstract).
> However, if this is the only argument, you wouldn't need markup
> inheritance
> at all! The proposed change is just an extension of exactly this markup
> inheritance concept (that everybody loves) to make it even more powerful
> than it already is.
>
> I was quite new to wicket (which I still am) and came across a situation
> where I wanted to use two abstract sections: one for a sub-navigation that
> was common for several pages in a section and one for the actual content.
> For me, as a wicket newbie, it would have been most natural to use markup
> inheritance to solve this problem. Using abstract methods, while being a
> nice solution (workaround?), didn't come to my mind at once, nor did I
> find
> it somewhere in the docs.
>
> imho, there are two possible solution to this problem:
> 1. promote using abstract methods for this in the docs as the wicket-way
> of
> doing it
> 2. extend the current markup inheritance mechanism (which I tried to do
> with
> my patch/prototype)
>
> -- stefan
>
>
> Mats Norén-2 wrote:
> >
> > On Nov 7, 2007 11:31 AM, Mats Norén <[EMAIL PROTECTED]> wrote:
> >> Hmm...I'm interested in seeing the difference as well. I would love to
> >> get it but right now I don't.
> >>
> >> Chris Colman wrote:
> >> "This new feature, or extension of the exiting feature, allows more
> than
> >> one section of markup to be "specialized" by derived (extended) markups
> >> whereas currently wicket only supports the deferred
> >> definition/implementation of a single markup section in any page. In
> >> other words we want to make a powerful feature even more powerful."
> >>
> >> Is the above statement really true considering that by adding abstract
> >> methods to your page you defer the creation of the markup in just the
> >> same way as the new proposed solution?
> >>
> >> BasePage.java
> >>
> >> public BasePage() {
> >> addAbstract1("abstractId1");
> >> addAbstract2("abstractId2);
> >> }
> >>
> >> public abstract addAbstract1(String abstractId1);
> >> public abstract addAbstract2(String abstractId2);
> >
> > A little typo here..I meant:
> >
> > public BasePage() {
> > add(addAbstract1("abstractId1"));
> > add(addAbstract2("abstractId2));
> > }
> >
> > public abstract Component addAbstract1(String abstractId1);
> > public abstract Component addAbstract2(String abstractId2);
> >
> > /Mats
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context:
> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626055
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Bruno Borges
blog.brunoborges.com.br
+55 1185657739
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
