well the problem is this
lets say onattach() comes with no strings attached
then you have Component->MyComponent
MyComponent overrides onattach and puts something very important into it,
what to do now?
there are two choices: make onattach() final, and provide a break out method
called onAttach2() or something like that
or leave it onattach() if you know the contract is always to call super()
now comes Component->MyComponent->MySecondComponent
MySecondComponent also has something very important in onattach(), but it
cannot override onattach, so it overrides onattach2() adds its logic and
provides another break out method onattach3()
this gets very ugly very fast
so what should components do? things that are meant to be overridden should
be factored out into a protected method and called from onattach()
i think the alternative of not forcing the call to super() is too ugly, that
is why we had all those damned internalonattach/internalattach/blah blah,
but those were only places for _us_ the framework devels to have a place to
put code we were sure would be executed in attach/detach.
-igor
On 1/4/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
I agree with that. We indeed could invent ourselfs a method that we call
from
within onAttach() to solve outr problem, but what if I'm not happy with
what
someone else (possibly in some framework implementation) added to the
onAttach().
If I commented the problem in the first place, it's because I like to
think
of these 'on...' methods as methods without any specific contract, that
the
framework user can freely overwrite. It's more kind of a suggestion.
Jan.
Johan Compagner wrote:
>
> but this could be a problem if somebody really wants to override
behavior
> of
> a component
> that is not in its own control. So maybe we should have a special final
> protected method that just sets the flag?
> That can also be called from the onAttach() instead of calling super?
>
> johan
>
>
> On 1/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>>
>> well, unfortunately it is now a requirement due to various reasons.
>>
>> what you should do is factor out whatever behavior out of onattach()
into
>> a
>> separate method, and then override that method in the subclass, that
way
>> you
>> dont need to override onattach() in the subclass, and even if you do
you
>> can
>> still call super.
>>
>> -igor
>>
>>
>> On 1/3/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> > The problem is I don't want to call super.onAttach(), because the
code
>> of
>> > my
>> > onAttach() overwrites the behavior of the code in super.onAttach().
>> > But if I don't call super.onAttach(), the flag FLAG_ATTACHING never
>> gets
>> > reset, and Wicket throws an exception.
>> >
>> > Jan.
>> >
>> >
>> > igor.vaynberg wrote:
>> > >
>> > > what exactly is the problem?
>> > >
>> > > can you not do
>> > >
>> > > onattach() {
>> > > super.onattach();
>> > > togglevisibilityofchildren();
>> > > }
>> > >
>> > > and no you cannot use attachchildren(), it is package-private
>> > >
>> > > -igor
>> > >
>> > >
>> > > On 1/3/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
>> > >>
>> > >>
>> > >> The last change in TRUNK related to onAttach(), with the
>> introduction
>> > of
>> > >> a
>> > >> (private) flag FLAG_ATTACHING that is reset in the onAttach() of
>> > >> Component,
>> > >> is causing us problems. We have inherited components that override
>> the
>> > >> logic
>> > >> of the onAttach() of their superclass, typically
enabling/disabling
>> or
>> > >> hiding of child components in function of some dynamically
>> changeable
>> > >> state.
>> > >> With the introduction of the flag, we are bound to call the
>> > >> implementation
>> > >> of the superclass, in order to reset the flag correctly.
>> > >>
>> > >> Are we using onAttach() in a wrong way ? I understood it is a
>> callback
>> > >> method that allows component implementors to do their thing,
without
>> > >> having
>> > >> to worry about the internal attach logic. Or should we use
>> > >> attachChildren()
>> > >> for that ?
>> > >>
>> > >> Jan.
>> > >> --
>> > >> View this message in context:
>> > >>
>> >
>>
http://www.nabble.com/onAttach%28%29-and-FLAG_ATTACHING-tf2913350.html#a8140407
>> > >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> > >>
>> > >>
>> > >
>> > >
>> >
>> > --
>> > View this message in context:
>> >
>>
http://www.nabble.com/onAttach%28%29-and-FLAG_ATTACHING-tf2913350.html#a8145567
>> > Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >
>> >
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/onAttach%28%29-and-FLAG_ATTACHING-tf2913350.html#a8158789
Sent from the Wicket - Dev mailing list archive at Nabble.com.
