> ... > > 5) Conclusion > > In conclusion, the proposed change: > - is useful > - does not have to be used if you don't like it > - is 100% backwards compatible > - it introduces no new tags (if using child/extends) > > I also do not see any real issues. This is purely about merging markup > when rendering, I think the analogies between this and OO concepts in > Java are clouding the issue! > > Regards, > Sebastiaan
Great summary Sebastiaan! I just thought of a possible, even more powerful, improvement (whoops!) What if the base page sections (child or abstract tag) were "optionally" overridden in a derived page. Ie., the section in the derived page markup is used if supplied otherwise Wicket defaults to using that provided in the base page. That's immensely powerful because you could provide some default markup in the base page and that will be used if the derived page does not provide an implementation of that section. A derived page now only needs to provide override sections for sections that it actually needs to override. It makes 'abstract' not a good choice for a tag name because abstract implies there is no implementation in the base page. In this case we could drop the OO language terms and use easy to understand terms for the tags like <wicket default id="header" />" in a base page section and <wicket override id="header" /> in a derived page section. Even my graphic designers could understand a tag pair called default/override! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
