> Hey Chris, I would need some lobbying here! ;)
>
> -- stefan
You're doing a great job Stefan - especially now I see that you've implemented
it - excellent job!
Are we both seeing something here that other people can't see? It wouldn't be
the first time in my life I was in that position - only years later do people
go "oh yeah" what a great idea...
I can only guess that most people haven't actually discovered the power and
reuse facilitated by the child/extend tag because if they had then it's not
such a great stretch to see the power of supporting more than one extendible
section - we're just arguing over multiplicity, not the extendible section
concept itself.
Most of the "panels can do that" arguments, in my mind, disparage the existing
child/extend concept as much as they do the proposed support for multiple
single extendible sections.
The, "I can do that with panels" argument sounds like C programmers back in the
early 90s saying, "I don't need C++ I can do everything in C with function
pointers". Well you probably could but by embarking on a short learning curve
you could be 1000x times more productive.
Someone asked for another explanation of the difference so I'll do that again
in a following post.
>
>
>
> Chris Colman wrote:
> >
> >> Wouldn't this essentially be the same as using <wicket:panel
> >> id="header"/> and using WebMarkupContainers on the java side?
> >> I.e.:
> >>
> >> Base
> >> ----
> >
> > Structural markup goes here (see below for explanation of this)
> >
> >> <wicket:panel id=header />
> >
> > More structural markup goes here
> >
> >> <wicket:panel id=body />
> >
> > And again more structural markup goes here too
> >
> >>
> >> PumpsBase
> >> ---------
> >> <wicket:panel id=header>
> >> A header for all pages to do with pumps
> >> </wicket:panel>
> >>
> >> Note: no body implemented here - deferred until a more specialized
> >> class/markups: WaterPumpsBase and OilPumpsBase
> >>
> >> WaterPumpBase
> >> -------------
> >> Note: no header implemented here - the general PumpsBase one suffices
> >> for all pumps pages
> >>
> >> <wicket:panel id=body>
> >> A body discussing water pumps
> >> </wicket:panel>
> >>
> > ...
> >
> >>
> >> On the java side you'd have to addOrReplace(new
> >> WebMarkupContainer("header")) but it's essentially the same. Or am I
> >> missing some point?
> >
> > This is indeed very different. If it were not so then the wicket
> > developers would never have conceived the need for the current
> > child/extend tag pair.
> >
> > The power of inheritance at the markup level is that you can define
> > markup once in a base markup file that is inherited by all derived
> > markup files. The derived markup files only supply sections that provide
> > "specialized sections of markup - the rest, at render time, comes from
> > the base class.
> >
> > You would typically use components (panels) within these specialized
> > sections but using the panel mechanism as you describe above as a
> > replacement for the powerful markup inheritance feature of wicket is not
> > possible.
> >
> > In the panel example you give you must still provide all of the
> > structural markup surrounding your panel tags in EVERY page's markup in
> > your system and if you decide to make a system wide change of this
> > structural markup you must edit every page's markup to reflect that
> > change. In an OO markup world you provide the structural markup in as
> > many pages as you want but at render time the only structural markup
> > used is that provided in the base base - which is very powerful because
> > you can make system wide changes by modifying only that single base
> > page's markup. Wicket is the first framework I've seen that allows
> > proper OO reuse concepts at the markup level.
> >
> > This is what many people wicket developers with an OO wiring in their
> > brain are doing right now with the existing child/extend feature - and
> > to great benefit.
> >
> > 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.
> >
> > It must be stated again (for the benefit of those who have just recently
> > joined this thread) that supporting multiple sections whose
> > implementation can be deferred to extended markups does not equate to
> > multiple inheritance (a big "no no" in the OO world). Multiple
> > overridden sections is analogous to the support of multiple abstract
> > methods whose implementations are provided in classes that extend the
> > base class - which is supported in all good OO languages, including
> > Java.
> >
> > ---------------------------------------------------------------------
> > 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#a13623108
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
