> Playing devil's advocate here: so what's the point/benefit of > preventing a call to setEnabled() if one can override isEnabled and > "modify the hierarchy" beyind Wicket's back anyway? >
That setEnabled method records a change and is thus useful for a visibility flag that has to roll back with back button clicks. For instance, when you have a user action (e.g. a button) for enabling/ disabling the visibility of the component. But when you calculate whether a component should be displayed or not, it might actually be a better idea to override getEnabled, as that will guarantee the behavior based on the current application state and will thus not be stale. >From an API point of view, this one is less tight, and we discussed a couple of times whether we should make getEnabled final or not. We concluded that having that method overridable is just too useful, so we didn't make it final. On 3/16/06, Gili <[EMAIL PROTECTED]> wrote: > > I personally prefer explicit calls to setEnabled() from onRender() > than > subclassing because it allows me to know upfront exactly where its value > is being changed (plus you don't have to recalculate the value if it > hasn't been changed). You can still achieve te same by overriding onBeginRequest. We are still discussing whether that method shouldn't be called onBeginRender btw. Eelco ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
