i do see your point, but it is not that much different, its just another way
of doing stuff.
Markup inheritance does come from the border stuff. i think i was the one
that proposes it when
we had a meeting here now a few years ago here in Holland so that that we
could border pages.
Then Juergen did implement it..
The thing that the multiply child's solve is that you can have the markup in
the sub page itself
instead of in panels. You can currently have the markup in the sub page (as
fragments), but
then you also have to define <extend> <child>. Else the sub page would
override the complete
base page markup.
But we can see for 1.4 if we can incorporate it into the core. But do make
sure that we don't
create a lot more tags, which is not the case as far as i see. So just just
that name attribute tag tags the specific parts.
1 thing that does bother me a bit (but maybe i have to do a deeper look into
the patch) how do you separate
the components in the constructor of the sub page.. i guess you just add all
the components over all the child fragments
in the page itself. That's not a nice separation... That can lead to big a
big mess.. Because what component belong to what child part.
And the previewability is a bit of mess if you would have 5 childs in your
sub page.
That are then just "random" blocks of html.
johan
On 11/7/07, Stefan Fußenegger <[EMAIL PROTECTED]> wrote:
>
>
> 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<http://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<http://nabble.com/>
> .
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
