> I found an excellent thread in the archives that explains this topic
very
> well - I swear I searched before, but obviously with the wrong
keywords ;)
>
>
http://www.nabble.com/Multiple-wicket%3Achild-tags-in-the-same-page-tf37
75143.html
>
> Multiple child/extends pairs (where you have to see such a pair as an
> abstract method rather than a baseclass/subclass relationship) could
help
> to combine the advantages of both approaches. However, its not a
feature
> that would improve wickets functionality and probably not worth the
effort
> of implementing it ... though it might be convenient.
I was the original poster of that topic (although I made a few more
replies that must have ended up in a different topic).
I still think that viewing the child/extends pairs as abstracts methods
instead of baseclass/sublass relationships is an ultimately cool model
that Wicket will eventually support one day because now I see that I'm
not the only one who has seen its potential.
I think the belief that the concept of multiple overridden sections in a
page constitutes or is analogous to multiple inheritance is incorrect.
Looking at the overridden sections as abstract methods (of which you can
have many per class in Java) makes a lot of sense. It's a very clean
model and totally analogous to a single inheritance model as per Java:
each page or panel still only has a single page or panel (analogous to
class) from which it extends.
The only requirement would be that if you do choose to support multiple
abstract/overridden sections you would need to provide identifiers (just
like an abstract method has a name) so that the 'compiler' (wicket)
knows which section in a superclass an extended class section is
overriding. In pages where only one section is overridden no identifiers
would be necessary and so existing markup works without change, the way
it does now.
I also made comment that I think the 'child/extends' nomenclature was
kinda wrong sounding. It doesn't seem like a natural fit. One of the
things we try to teach the OO youngsters is that inheritance is very
different to a parent/child relationship. Parent/Child is an association
relationship where as inheritance is more of an 'extension',
'derivation' or 'specialization'.
Too late for changing this now but that's never stopped me from making a
pedantic contribution in the past so why stop now? ;-)
In wicket we already specify the superclass of particular page markup
via the 'extends' relationship between the corresponding Java classes so
there's no need to use the 'extends' term in defining the individual
overridable sections in the markup. Perhaps that tag might have been
called 'abstract' in the base page and 'override' in the extended page
and declared like:
<wicket:abstract id=sidemenubar>
Derived pages will supply their own side bar menu.
[Abstract is a great word here because it indicates that no definition
exists here - it's just declaring a placeholder - and it's perfectly
analogous to the Java abstract keyword]
</wicket:abstract id=sidemenubar>
'Funky divider' that is common throughout the entire site goes in here
<wicket:abstract id=body>
Derived pages will supply their own body
</wicket:abstract id=body>
In the derived (extended) page markups:
<wicket:override id=sidemenubar>
This is the side menu bar
[A nice thing about the word override is that it is perfectly analogous
to the @Override annotation in Java]
</wicket:override id=sidemenubar>
'Funky divider' comes from the base class - this section is ignored
<wicket:override id=body>
This is the side menu bar
</wicket:override id=body>
One reason that support for multiple overridden sections in a page is so
useful is that it is often desirable for a whole category of pages, each
with a different body section, to have a common side bar menu - that is
not common throughout the entire site - just common for that range of
pages - yet the 'Funky divider' IS common to the entire site and so I
only want to define it in one place - in the base page. I am sure there
are many other examples of its usefulness which is probably why the
topic arises from the ashes like a phoenix on a regular basis. :)
It would be quite feasible to add support for multiple overridden
sections using the above tag names while remaining backwards compatible
with existing markup by continuing to support the old <child/extends>
tags working the way they always have.
>
> I hope I got it right.
>
Same here!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
