Well, if naming is your only concern, the attribute's name can easily be
replaced with something else than id ... e.g. name
<wicket:abstract name="foo" />
<wicket:implement name="foo">
some text
</wicket:implement>
and remember that they can be optional as well:
<wicket:abstract />
<wicket:implement>
some text
</wicket:implement>
This way, its completely compatible with child/extend (which can be proofed
with the existing junit test for markup inheritance)
just a question: do i start to convince you? ;)
best regards
Bruno Borges wrote:
>
> 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
>
>
-----
-------
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#a13627156
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
