all these method are equivalent, suppose
public class MyComponent extends Component {
protected void onattachhandler1() {//foo }
protected void onattachhandler2() {//bar}
}
now:
public class MyComponent extends Component {
protected void onattach() { onattachhandler1(); onattachhandler2(); }
protected void onattachhandler1() {//foo }
protected void onattachhandler2() {//bar}
}
annots:
public class MyComponent extends Component {
protected void onattachhandler1() {//foo }
@OnAttach protected void onattachhandler2() {//bar}
}
listeners:
public class MyComponent extends Component {
public MyComponent(...) {
add(new IAttachListener() { public void onAttach() {
onattachhandler1(); onattachhandler2(); }}
}
protected void onattachhandler1() {//foo }
protected void onattachhandler2() {//bar}
}
personally i like the current one, its simpler
the thing is that we should factor out all the behavior that needs to be
overridable out of the onattach() methods, like i did for the listview just
now. and yes, if it is not meant to be overridden then use a different
component.
-igor
On 1/4/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
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
