nothing is ever simple, sigh :)
there is a usecase which might cause some nasty sideeffects
consider
class A extends Page {
@OnAttach protected void init() { System.out.println("A.init();"); }
}
class B extends A {
@OnAttach protected void init() { System.out.println("B.init();");}
}
when you use B and it gets attached the output is:
B.init();
B.init();
this is because when scanning for annots we will see A.init() and B.init()
and then call them both, but because B.init() overrides A.init() when A.init()
is invoked it calls B.init()
i would say this is a user error - since B.init() overrides A.init() the
method should not be annotated with @OnAttach.
so the question is do we leave it like that, or do we implement some more
complex scanning and try to figure out if any method overrides are going on
and exclude those. i dont think java's reflection allows us to do this out
of the box.
what do you all think?
-igor
On 10/27/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
we have a couple of great candidate callbacks to be implemented with
annotations instead of template methods. namely onattach/detach,
onbegin/endrender
what makes them great candidates is this
1) when implementing one you must always call super()
this is not _always_ true. when extending a core component you dont need
to because we have our own internalattach() we can use and onattach() is
just an empty template.
but when extending a non-core component you must call super() because you
never know if that component uses it or not and it is very very unlikely
that it is a behavior you want to override
2) implementors of onattach(), if they are good, will make it final and
provide another breakout template to ensure their onattach code cannot be
messed with. this leads you to have
public final void onAttach(){ dosomething(); onAttach2(); } public void
onAttach2() {}
this is the general java pattern that i find very ugly personally, take a
look at our Component.internalAttach() impl :)
so what i propose is that we provide some annotations
@OnAttach @OnDetach @OnBeforeRender @OnAfterRender
users can annotate any number of methods with these and have them called.
im sure there are other places that can benefit from this, but for now we
can cleanup the mess that is internalAttach(), internalOnAttach()
onAttach(), etc
of course this is wicket 2.0 only
-Igor
