Then if you really want that then that is the case.
But most of the time that doesn't happen
The current thing is just to restrictive it thing. Just one example in some
code that we have here is that
we have overriden internAttach of ListView because we have a bit more
special build of the list items.
So we completely disable the listviews things and have our own
For the rest everything is the same.
From now on what must be done is that we have to make a complete copy of
listview.......
thats horrible..
johan
On 1/4/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
well if you allow this then it nullifies what i tried to achieve. the
developers, even core ones, will start doing what i said, making onattach
final and providing an onattach2 because in some instances you have things
that are not meant to be overridible. so we will be back to square one.
-igor
On 1/4/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> there is one problem of not being able to override some implementation
in
> an
> onAttach
> and that is that the component builder (maybe even wicket core) doesn't
> put
> that in
> an overridable method so that i can nullify it or make my own impl.
> Then i can never just override it with my own. And that could be a
problem
> if you are not in full control.
> That can be very frustrating. Thats why i think adding an extra method
> that
> does set the flag
> and by passes everything would be a good alternative. Because then you
> really choose for it
> you know what you are doing.
>
> johan
>
>
> On 1/4/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >
> > 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.
> > >
> > >
> >
> >
>
>
