Thank all for the help.
Am 28.05.2010 07:21, schrieb Jeremy Thomerson:
On Fri, May 28, 2010 at 12:08 AM, Chris Colmanchr...@stepaheadsoftware.com
wrote:
I think the concepts are very different. The opinion that they are
effectively the same was raised in the earlier discussion (probably more
than a year ago).
Your suggestion involved using child/extend for one of the overridable
sections and then doing the other section with
div wicket:id=body[body]/div
If it's just as good or just as easy to implement using the later option
then why not do both with the later suggestion? The reason they are
different is that the later is not true markup inheritance.
A child/extend section is indeed true markup inheritance, albeit, we're
currently constrained to a single inheritable/overridable section per
page but as was agreed a year ago limiting wicket to a single overidable
section was an 'arbitrary constraint' and has nothing to do with
maintaining a single inheritance model. A single inheritance model only
imposes the constraint that each page directly extends only one other
page and that constraint is clearly not violated by having multiple
overridable sections.
-Original Message-
From: Jeremy Thomerson [mailto:jer...@wickettraining.com]
Sent: Friday, 28 May 2010 8:40 AM
To: users@wicket.apache.org
Subject: Re: Page in Page
On Thu, May 27, 2010 at 5:33 PM, Chris Colman
chr...@stepaheadsoftware.comwrote:
Wicket (just like Java) does not support multiple inheritance. If
you're
creating a base page that has two blocks that need to be filled in,
you
can:
I agree that wicket shouldn't support multiple inheritance but I'm
not
sure that what is required here is multiple inheritance.
In the wicket parallel universe multiple inheritance would be
represented by one page extending from multiple base pages but
that's
not what is required here and that would indeed be a bad path to
trod.
What I have had the need for many times is for a base page to have
multiple overridable 'sections' - one base page but multiple sections
within that page that could be overridden (or not) by pages that
extend
that page. This does not represent multiple inheritance. It is the
equivalent of Java allowing multiple overridable methods in a single
base class. In Java classes that extend the base class can override
one
or more of the virtual (non final) methods in the base class but the
same rule applies - any class/page can only extend a single base
class/page.
The constraint that wicket has now is that only one section of a page
can be overridden by the 'limit of one' child/extend wicket tags. As
only one overridable section is currently allowed in wicket there is
no
need to identify it. If wicket were to allow multiple sections in a
base
page to be overridden in derived pages then a simple identification
scheme would be required - much like Java uses method signatures to
identify the methods that are being overridden.
Eg.,
BasePage.html:
body
div id=container
wicket:section id=header
!-- markup will be used if no derived page overrides
it
--.
h1my website/h1.
/wicket:section
hr /
wicket:section id=body
!-- a derived page should override this --
/wicket;section
hr /
!-- footer same for every page - no overriding --
div class=footer
pcopyright 2010 acme corp/p
/div
/div
/body
WelcomePage.html:
body
!-- happy to use base page's header so no header section
override --
wicket:section id=body
h1Welcome to my website!/h1
My website is the best because it uses wicket!
/wicket:section
/body
Note how I've used the same tag 'section' in both base and extended
pages to avoid the obvious issue that occurs should someone extend
the
WelcomePage.html above. Ie. When inheritance is chained over more
than
two levels. In that case it becomes very wrong to specify whether a
section is 'overriding' (extend) or can be overridden (child). Much
like
in Java inheritance you don't specify each method as being a 'child'
or
'extension'. Instead, the mere presence of a method with identical
signature as in a base class indicates that that method is overriding
the base class method. That would seem an obvious model for
overridable
markup sections in wicket also.
This idea/issue has been raised a few times before in this list and
once
a remarkably small patch was even developed that would enable this to
work.
-
To unsubscribe, e-mail:
