Of course, it really is optional. Wicket only checks whether a page has a <wicket:extend> tag or not to decide if markup merging is needed. (Therefore, my patch does not have any impact on that, as there is no markup merging triggered)
Thanks for pointing this out! -- stefan Sebastiaan van Erk wrote: > > Hi, > > Actually, Wicket already works like this. It does *NOT* require the > <wicket:extend>, and if it's not present it just renders the contents of > the <wicket:child>. (Just tested this with beta4). > > Furthermore, your patch works exactly the same as far for multilple > child sections (as far as I can tell, or otherwise it should for > backwards compatibility), and does precisely what both you and Chris want. > > Regards, > Sebastiaan > > Stefan Fußenegger wrote: >> I think it would be a nice feature to define defaults and overrides this >> way. >> However, this wouldn't be backwards compatible anymore as the contents >> are >> currently ignored. (Ok, you are currently forced to extend them, so you >> probably wouldn't see the markup from such sections in *old* >> applications.) >> >> My vote on this: >> - I would love to have multiple sections. >> - I would appreciate default markup for extendible sections. >> >> Kind regards, >> >> -- stefan >> >> PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :) >> >> >> >> Chris Colman wrote: >>>> That is what I'd suggest as well, since it involves the least amount >>> of >>>> change. As an added bonus, if no id's are added and 2 <wicket:child> >>>> sections are used, it could throw an exception (which it currently >>> does >>>> not do, it just silently ignores the second <wicket:child>). >>> That would be magic! >>> >>> While we're at this epic moment after spending days thrashing this out >>> could we spend just 3 extra minutes to investigate implementing standard >>> Java method like behavior for this feature? >>> Ie., In the case that no override <extend> is provided in a derived >>> page, simply use the markup in the <child> tag in the base page. >>> >>> Then it would work like methods work in Java - and it's probably how >>> most Java developers would naturally expect an OO framework like wicket >>> to work anyway. >>> >>> Intuitively it seems like an easy to implement option in the framework: >>> the <child>/<extend> feature is already merging code from the base page >>> anyway - if there is no override <extend> tag in a derived page then it >>> simply pulls the markup from the base page's <child> tag. >>> >>>> Regards, >>>> Sebastiaan >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> >> ----- >> ------- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) > > > ----- ------- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13666078 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
