> ok tell me with 2 examples what is soo different about having 2 panels (or > fragments) > in a page and implement that in a sub page or having 2 wicket childs in a > page and implement those in a sub page.
Ok, here we go... (well one example at least - it's getting late here ;) ) I'm not sure what angle you're coming from: there seems to be two things to argue about here: 1) the value of markup inheritance as facilitated by the ability to "override" or "defer implementation" of a single section of a base page, via the existing child/extends tags, to a sub page's markup. 2) the multiplicity of overridden sections (ie., allowing more than one) The first point is easy to argue for - if you don't have an <extends> tag in a page then that page, when rendered, uses ALL of the markup of that page - it does not merge any markup with a base page. In other words, you need to set up the structural markup around your panels etc., identically in every page if you want to have the same look and feel across your whole site. If you change the structure of your page you need to edit EVERY page... nasty! If you do have a <child> tag in your base page and <extend> in sub pages then wicket works in a much more clever and powerful way: the whole of the base page markup, except for the <child> section is "merged in" when rendering the sub page. In other words - all subpages share the same structural markup surrounding the <child> section. This is very powerful and it's exactly the same concept that's been used in OO languages for the last 20 years. The sub pages have a chance to "specialize" the appearance of the page, albeit (currently) in only one section. No OO language limits the number of methods that can be "specialized" in a sub class to just one method - it would be very restrictive, would make no sense and there would be no logic in such a limitation. In the same way there is no logical reason why the number of "specialized" sections in sub pages in wicket should be limited to just one. What Stefan has brilliantly done is created a wicket patch that does away with this unnecessary limitation of only one specialized section per page. So if you already use and see the value in the child/extend take then support for Multiple "specialized" sections per page is just a simple multiplicity argument. Do you ever find yourself creating more than one overridden method in a Java class? Well then you'll probably feel the urge to do the same in markup now once you grasp the power of markup inheritance. For those wanting an example I'm not a graphic artist, but a developer, so naturally I used a software modeling/coding tool to illustrate an example of how such multiplicity is useful: The picture is a .vcm model (3kb zipped) and is downloaded from: http://www.stepaheadsoftware.com/products/javelin/examples/multipleSpeci alizedSections.zip You can use freeware version (1.3MB) of the Javelin modeling tool to view it, which can be downloaded from: http://www.stepaheadsoftware.com/products/javelin/javelind.htm --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
