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]
