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.

-- 
Jeremy Thomerson
http://www.wickettraining.com

Reply via email to