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