Right, it's doable, but there's a bit of homework you have to do to
make sure it all works correctly. You have to solve the whole
"onFirstRender" problem in a reliable way. Our base page has an
overridable onFirstRender() method that subclasses can override if
they wish to do this sort of initialization. I like the
onInitialize() method name better, though.
On Thu, Jul 8, 2010 at 5:29 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote:
> class Page extends .... Page {
>
> abstract Component getPart1(String id);
> abstract Component getPart2(String id);
>
> onBeforeRender() {
> if (get("part1")==null) { add(getPart1("part1")); }
> if (get("part2")==null) { add(getPart2("part1")); }
> }}
>
> in 1.5 it would be done like this
>
> class Page extends .... Page {
>
> abstract Component getPart1(String id);
> abstract Component getPart2(String id);
>
> onInitialize() {
> add(getPart1("part1"));
> add(getPart2("part1"));
> }}
>
> -igor
>
> On Thu, Jul 8, 2010 at 2:23 PM, James Carman <ja...@carmanconsulting.com>
> wrote:
>> And, this method doesn't really work very well either. You can't
>> reliably call those abstract methods from the superclass' constructor.
>>
>> On Thu, Jul 8, 2010 at 2:47 PM, Chris Colman
>> <chr...@stepaheadsoftware.com> wrote:
>>>>class Page extends .... Page {
>>>>
>>>>abstract Component getPart1();
>>>>abstract Component getPart2();
>>>>}
>>>>
>>>><html>....
>>>>
>>>><div wicket:id="id4part1" />
>>>><wicket:child />
>>>><div wicket:id="id4part2" />
>>>
>>> That's the component based workaround that I mentioned which IMHO isn't
>>> really the pure markup OO solution we're proposing. I'm hoping for true
>>> markup inheritance that supports multiple overridable sections that
>>> doesn't mandate a Java side coding change each time a markup editor adds
>>> or removes a particular overridable section.
>>>
>>>
>>>>On Thu, Jul 8, 2010 at 5:49 AM, Chris Colman
>>>><chr...@stepaheadsoftware.com>wrote:
>>>>
>>>>> >Search the list for this and you'll find some quite long
>>> discussions.
>>>>> >Basically, it's not going to happen. This would be multiple
>>>>> inheritance,
>>>>> >not single.
>>>>>
>>>>> Hi Jeremy, I hope I don't sound confrontationalist when I say this
>>> but
>>>>> this is clearly not a case of multiple inheritance.
>>>>>
>>>>> For this request to be deemed to be multiple inheritance one
>>>>> class/markup file would need to be inheriting from two separate super
>>>>> classes/markup files. That is not what is requested here. There
>>> remains
>>>>> only a single super class/markup file.
>>>>>
>>>>> All that is requested here is for multiple markup sections to be
>>>>> overridden in this single inheritance scenario - just like Java does
>>> not
>>>>> restrict you to overriding only a single method in any Java class:
>>> You
>>>>> can override as many methods as you like in a Java class but that
>>> does
>>>>> not break Java's single inheritance model - which constrains the
>>> number
>>>>> of base classes to ONE, not the number of methods you can override to
>>>>> ONE.
>>>>>
>>>>> All this user (and others before him) are asking is for wicket to
>>>>> support the overriding of N markup sections without instead of the
>>>>> arbitrarily imposed constraint of N <= 1.
>>>>>
>>>>> >
>>>>> >Jeremy Thomerson
>>>>> >-- sent from my smartphone - please excuse formatting and spelling
>>>>> errors
>>>>> >
>>>>> >On Jul 5, 2010 12:41 AM, "Arjun Dhar" <dhar...@yahoo.com> wrote:
>>>>> >
>>>>> >
>>>>> >Hi,
>>>>> > all the examples etc suggest that Single inheritence is possible
>>> but I
>>>>> >cant
>>>>> >break it up. The break up is essential when you want to merge common
>>>>> parts
>>>>> >of your MARKUP with multiple specific parts of the Child page.
>>>>> >
>>>>> >Example:
>>>>> >
>>>>> >
>>>>> ><HTML>
>>>>> ><HEAD><title>BASE TEMPLATE / PARENT PAGE</title></HEAD>
>>>>> >
>>>>> ><BODY>
>>>>> > <wicket:child />
>>>>> > <br />
>>>>> > <h2>Some other Html common</h2>
>>>>> > <wicket:child />
>>>>> ></BODY>
>>>>> ></HTML>
>>>>> >
>>>>> >
>>>>> >-------------------------------------------
>>>>> >
>>>>> ><HTML>
>>>>> ><HEAD><title>CHILD PAGE 1</title></HEAD>
>>>>> >
>>>>> ><BODY>
>>>>> > <wicket:extend>
>>>>> > Part 1 specific to Child Page
>>>>> > </wicket:extend>
>>>>> > Any HTML here can be ignored as conceptually anyway what
>>> appears
>>>>> in
>>>>> ><extend> is what should be rendered from a child page.
>>>>> > <wicket:extend>
>>>>> > Part 2 Specific to Child Page (will appear after
>>>>> common
>>>>> >HTML in parent page)
>>>>> > </wicket:extend>
>>>>> ></BODY>
>>>>> ></HTML>
>>>>> >
>>>>> >
>>>>> >I tried this, only the first part renders. I'm wondering if we can
>>> add
>>>>> such
>>>>> >capability. Conceptually I don't see why not. If already possible do
>>>>> let me
>>>>> >know or consider as a feature request?!
>>>>> >
>>>>> >-Thanks Arjun
>>>>> >--
>>>>> >View this message in context:
>>>>>
>>>>http://apache-wicket.1842946.n4.nabble.com/Single-inheritence-in-parts-
>>>>> >tp2278064p2278064.html
>>>>> >Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>> >
>>>>>
>>>>---------------------------------------------------------------------
>>>>> >To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> >For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
