not quiete if the method is private then they should both be called, but
output should be
A.init();
B.init();
-igor
On 10/29/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
I guess when scanning you get a method object.
Why not make a hash (method name and params) and throw that in a hashmap
so that they are all unique?
johan
On 10/29/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
> 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
> >
> >
>
>
