> 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]