On 1/4/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
ahh, but then you are back to the exact same problem. how do you override behavior that was added via an anonymous ILifecycleListener (or whatever you call it) :) the solution is the same as for the current onattach() problem, and for annotations approach - behavior that is meant to be overridable needs to be factored out into a separate method.
Not completely: the problem we are discussing is not methods that need to be overridden, but overridable methods that are implemented, but still need to be called. With the chain (and the annotations) we avoided that particular aspect of the problem. The thing you are talking about is disabling a particular behavior. In that case, I think creating a new component might be a better solution, as you are truly not extending the original design of a component, but tinkering with the intended behavior to which the component was designed. If you still want to re-use that particular component, then the common functionality should be extracted to a base, without the undesired behavior. Currently the problem is not that some feature needs to be disabled, but that some necessary code has to be called for the component to work correctly. Registering the handlers (through annotations or chain of commands) does solve this particular problem without the need for reading and correctly interpreting javadocs. Martijn -- Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now! http://wicketframework.org
