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