Thanks again for your reply. On the one hand, I agree with you, adding custom 'addComponent' method does make the mechanics of the code more clear.
On the other hand, in practice (we used such methods for a couple of weeks), it results in the situations in application code where you sometimes have to use add(..) method and sometimes addComponent(..) method (and in case of addComponent(..) method, add(..) method is also available, so no compilation errors there). It invariably led to people forgetting to use addComponent(..) instead of add(..) and thus application crashing/behaving incorrectly at runtime. This was extremely annoying -- hence our decision to un-finalize add(..) method. On the yet another hand, OO programming kind of implies that objects are supposed to hide their implementation details, so even disregarding my previous usability comment, I'm not sure I agree that addComponent(..) is better than overridden add(..) method from the philosophical point of view. And if I may to try and adjust the course of this discussion a bit -- the issue with repeaters is not the only argument against final add(..) method. As I mentioned in passing, there's also issue of Page inheritance where subclasses with <wicket:extend> cannot use add(..) method if parent Page has <wicket:child /> nested into some other tag with wicket:id -- leading to the very similar issues. I'm sure there can be other examples as well. So perhaps add(..) method doesn't need to be final after all? Or would it break something else that I don't know about? If someone could explain reasons behind add(..) being final it would be most appreciated -- that might change my opinion on the whole subject. Best regards, Sergey Pedro H. O. dos Santos wrote: > > If you has some rules for your component, like wrap components, make more > sense you extend RepeatingView, create the addComponentAfterWrapHim > method, > that delegate the call to add method after your customization is made. You > gain plainness by make clean that this component add method is special. > > On Mon, Jan 18, 2010 at 10:52 AM, Sergejs Olefirs > <sergejs.olef...@parex.lv>wrote: >> >> This kind of brings us back to original question -- why is >> MarkupContainer.add(..) method final? Maybe it's something that needs to >> be >> changed (or alternatively mechanism provided for hooking into this >> method)? >> >> >> For our own purposes I already adjusted this method to be non-final (but >> that means that upgrading Wicket version is going to be slightly more >> problematic). >> >> Declaring it non-final resolved the RepeaterView (actually our custom >> component with slightly adjusted functionality) cleanly. >> >> It also resolved the issue with page inheritance. As it stands right now >> (in >> out-of-the-box Wicket), if <wicket:child /> is inside of any other tag >> with >> wicket-id, then children pages can no longer use add(..) method directly >> (as >> it would then add components in the wrong place in the hierarchy and page >> rendering will crash). With 'final' gone, it is a simple matter to >> override >> add(..) in the parent page so that it would add components properly -- >> thus >> children need not be aware of the parent innards. > -- View this message in context: http://old.nabble.com/final-in-MarkupContainer-add%28Component...%29-method-tp27161187p27211055.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
