Thank all for the help.
Am 28.05.2010 07:21, schrieb Jeremy Thomerson:
On Fri, May 28, 2010 at 12:08 AM, Chris Colman<[email protected]
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:[email protected]]
Sent: Friday, 28 May 2010 8:40 AM
To: [email protected]
Subject: Re: Page in Page
On Thu, May 27, 2010 at 5:33 PM, Chris Colman
<[email protected]>wrote:
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
--.
<h1>my 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">
<p>copyright 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">
<h1>Welcome 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: [email protected]
For additional commands, e-mail: [email protected]
And how is your proposed solution any different than the solution that
I
gave you (putting<div wicket:id="body">[body]</div> in your markup and
creating an abstract method that child classes must implement)? It's
exactly the same except that now people would have to learn a new
wicket:section tag. This doesn't make sense and it strays from
Wicket's
"just java / just html" motto. The two solutions are functionally the
same
and only cosmetically different.
--
Jeremy Thomerson
http://www.wickettraining.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
What I'm saying is that your post earlier, the one with the wicket:section
tag, works exactly like if you used the<div wicket:id="foo"> method that I
gave. The only difference is the tag name. They could both have multiple
overridable sections. In both, you have a markup location that contains
placeholders for the extendable sections. What I failed to mention in the
first post was that in the child page (in your example, WelcomePage.html),
you define the overridable sections with wicket:fragment if you don't have a
ready-use panel already created, meaning you need to put the markup directly
in the child page.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
