Right, well put then. :)
On Thu, Jul 8, 2010 at 5:41 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote:
> my point was simply that it is trivial to solve, it has a well known
> solution, and this is not the only usecase where it applies. you will
> need to do your homework no matter which way you go.
>
> -igor
>
> On Thu, Jul 8, 2010 at 2:35 PM, James Carman <ja...@carmanconsulting.com>
> wrote:
>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
