You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jan Vermeulen <ja...@isencia.com> on 2007/01/03 14:08:05 UTC
onAttach() and FLAG_ATTACHING
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.
Re: onAttach() and FLAG_ATTACHING
Posted by Igor Vaynberg <ig...@gmail.com>.
yes, what should really be done is that we need to go through the code and
factor out things that happen in onattach into separate method if they are
meant to be overridable.
lets say you override ondetach() and dont call super. are you going to
remember to call detachModels() which is done in component.ondetach() ? are
you going to do all the important things up the entire class hierarchy that
are done in ondetach()?
the fact that listview has item generation directly in onattach is just
crappy and needs to be fixed _properly_.
-igor
On 1/4/07, Johan Compagner <jc...@gmail.com> wrote:
>
> 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 <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ja...@isencia.com> 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.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: onAttach() and FLAG_ATTACHING
Posted by Igor Vaynberg <ig...@gmail.com>.
lol, welcome to the conversation. i have already implemented such a check,
and this whole conversation is about the pros and cons of this check.
-igor
On 1/4/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> For this line they are, but when MyOtherComponent extends MyComponent,
> the ballpark changes a bit:
>
> Assume:
> public class MyComponent extends Component {
> protected void onattachhandler1() {//foo }
> protected void onattachhandler2() {//bar}
> }
>
> public class MyOtherComponent extends MyComponent {
> protected void onattachhandler3() { // beer }
> }
>
> then:
>
> public MyOtherComponent() {
> add(new IAttachListener() { public void onAttach() {
> onatachhandler3(); }
> }
>
> is not equivalent to:
> public void MyOtherComponent:onAttach() {
> onattachhandler3();
> }
>
> because it requires you to add a call to super(). This can/will be
> forgotten.
>
> If we do so, we could add a detection system in the
> Component.onAttach()/onDetach() methods that super is actually called,
> with a possibility to disable that check, and would only perform such
> a check in development mode (just like the serialization now).
>
> something like:
>
> Component.onAttach() {
> if(isAttachCalled() != null) {
> setAttachCalled(true);
> }
> }
> Component.isAttachCalled() {
> // defaults to true, subclasses that allow overriding can
> // return NULL.
> return false;
> }
>
> somewhere in the request cycle:
>
> if(settings.isAttachCheckEnabled()) {
> page.visit(new AttachChecker() { if(!component.isAttachCalled())
> throw ... } );
> }
>
> Martijn
>
> On 1/4/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > 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 <ma...@gmail.com> wrote:
> > >
> > > On 1/4/07, Igor Vaynberg <ig...@gmail.com> 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
> > >
> >
> >
>
>
> --
> 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
>
Re: onAttach() and FLAG_ATTACHING
Posted by Martijn Dashorst <ma...@gmail.com>.
For this line they are, but when MyOtherComponent extends MyComponent,
the ballpark changes a bit:
Assume:
public class MyComponent extends Component {
protected void onattachhandler1() {//foo }
protected void onattachhandler2() {//bar}
}
public class MyOtherComponent extends MyComponent {
protected void onattachhandler3() { // beer }
}
then:
public MyOtherComponent() {
add(new IAttachListener() { public void onAttach() { onatachhandler3(); }
}
is not equivalent to:
public void MyOtherComponent:onAttach() {
onattachhandler3();
}
because it requires you to add a call to super(). This can/will be forgotten.
If we do so, we could add a detection system in the
Component.onAttach()/onDetach() methods that super is actually called,
with a possibility to disable that check, and would only perform such
a check in development mode (just like the serialization now).
something like:
Component.onAttach() {
if(isAttachCalled() != null) {
setAttachCalled(true);
}
}
Component.isAttachCalled() {
// defaults to true, subclasses that allow overriding can
// return NULL.
return false;
}
somewhere in the request cycle:
if(settings.isAttachCheckEnabled()) {
page.visit(new AttachChecker() { if(!component.isAttachCalled())
throw ... } );
}
Martijn
On 1/4/07, Igor Vaynberg <ig...@gmail.com> wrote:
> 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 <ma...@gmail.com> wrote:
> >
> > On 1/4/07, Igor Vaynberg <ig...@gmail.com> 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
> >
>
>
--
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
Re: onAttach() and FLAG_ATTACHING
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ma...@gmail.com> wrote:
>
> On 1/4/07, Igor Vaynberg <ig...@gmail.com> 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
>
Re: onAttach() and FLAG_ATTACHING
Posted by Martijn Dashorst <ma...@gmail.com>.
On 1/4/07, Igor Vaynberg <ig...@gmail.com> 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
Re: onAttach() and FLAG_ATTACHING
Posted by Igor Vaynberg <ig...@gmail.com>.
On 1/4/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> > you can do this with IBehavior, just add onattach/ondetach to it.
>
> However, I see IBehavior more as a plugin for external visible
> effects. And it would break api quite a bit :-)
well, all this work is going into the 2.0 branch anyways. and ive been
meaning to add onattach/ondetach to behavior for a while anyways, these two
methods are very useful.
> Or find a way of doing these things in a way that avoids this
> discussion altogether. If we can remove the onAttach/onDetach methods
> in Component, wouldn't that be a solution? Just exploring the space
> here, not taking a position.
>
> We could call the feature "Wicket now uses closures for lifecycle methods"
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.
-igor
Martijn
>
Re: onAttach() and FLAG_ATTACHING
Posted by Martijn Dashorst <ma...@gmail.com>.
On 1/4/07, Igor Vaynberg <ig...@gmail.com> wrote:
> On 1/4/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > Perhaps a really baaaaaad idea, but novel in its concept... I know the
> > @onAttach annotations were not something worth implementing. But the
> > idea of more flexible attach methods is apparently still compelling.
>
> actually i had @OnAttach and @OnDetach full implemented and working, but
> decided to scratch it. the trouble with annotations is that it really
> destroys api discoverability.
>
>
> Can we implement a chain of commands for the attach/detach logic (or
> > any other lifecycle)? In the constructor of a component, the component
> > builder can register the commands...
> >
> > public MyComponent extends Component {
> > public MyComponent() {
> > addAttachBehavior(new IAttachBehavior() { public void
> > onAttach() { myOwnAttach(); }});
> > }
> > }
>
> you can do this with IBehavior, just add onattach/ondetach to it.
However, I see IBehavior more as a plugin for external visible
effects. And it would break api quite a bit :-)
> but really the core of the issue is not flexibility or lack there of. this
> is a discussion about coding style. the decision is between making it
> mandatory to call super, or making things final and having multiple
> breakouts like we did.
Or find a way of doing these things in a way that avoids this
discussion altogether. If we can remove the onAttach/onDetach methods
in Component, wouldn't that be a solution? Just exploring the space
here, not taking a position.
We could call the feature "Wicket now uses closures for lifecycle methods"
Martijn
Re: onAttach() and FLAG_ATTACHING
Posted by Igor Vaynberg <ig...@gmail.com>.
On 1/4/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> Perhaps a really baaaaaad idea, but novel in its concept... I know the
> @onAttach annotations were not something worth implementing. But the
> idea of more flexible attach methods is apparently still compelling.
actually i had @OnAttach and @OnDetach full implemented and working, but
decided to scratch it. the trouble with annotations is that it really
destroys api discoverability.
Can we implement a chain of commands for the attach/detach logic (or
> any other lifecycle)? In the constructor of a component, the component
> builder can register the commands...
>
> public MyComponent extends Component {
> public MyComponent() {
> addAttachBehavior(new IAttachBehavior() { public void
> onAttach() { myOwnAttach(); }});
> }
> }
you can do this with IBehavior, just add onattach/ondetach to it.
We then guarantee that the attach queue is processed in order of
> addition. For detach we guarantee that the detach queue is processed
> in the reverse order. This eliminates the trouble we had with the
> annotations where the order of methods was hard to implement.
we didnt have this trouble with annotations. the only trouble was that we
did not guarantee order of invocation for multiple annotated methods within
the same class. i had it implemented where listeners in the class hieararchy
would get invoked in the right order.
but really the core of the issue is not flexibility or lack there of. this
is a discussion about coding style. the decision is between making it
mandatory to call super, or making things final and having multiple
breakouts like we did.
-igor
Martijn
>
> On 1/4/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > fwiw i just factored out some things out of the listview's onattach into
> > onGenerateItems. take a look, tell me if enough has been factored out to
> > support your usecase.
> >
> > -igor
> >
> >
> > On 1/4/07, Johan Compagner <jc...@gmail.com> wrote:
> > >
> > > 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 <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ja...@isencia.com>
> 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.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
> --
> 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
>
Re: onAttach() and FLAG_ATTACHING
Posted by Martijn Dashorst <ma...@gmail.com>.
Perhaps a really baaaaaad idea, but novel in its concept... I know the
@onAttach annotations were not something worth implementing. But the
idea of more flexible attach methods is apparently still compelling.
Can we implement a chain of commands for the attach/detach logic (or
any other lifecycle)? In the constructor of a component, the component
builder can register the commands...
public MyComponent extends Component {
public MyComponent() {
addAttachBehavior(new IAttachBehavior() { public void
onAttach() { myOwnAttach(); }});
}
}
We then guarantee that the attach queue is processed in order of
addition. For detach we guarantee that the detach queue is processed
in the reverse order. This eliminates the trouble we had with the
annotations where the order of methods was hard to implement.
Martijn
On 1/4/07, Igor Vaynberg <ig...@gmail.com> wrote:
> fwiw i just factored out some things out of the listview's onattach into
> onGenerateItems. take a look, tell me if enough has been factored out to
> support your usecase.
>
> -igor
>
>
> On 1/4/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > 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 <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ja...@isencia.com> 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.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
--
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
Re: onAttach() and FLAG_ATTACHING
Posted by Igor Vaynberg <ig...@gmail.com>.
fwiw i just factored out some things out of the listview's onattach into
onGenerateItems. take a look, tell me if enough has been factored out to
support your usecase.
-igor
On 1/4/07, Johan Compagner <jc...@gmail.com> wrote:
>
> 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 <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ja...@isencia.com> 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.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: onAttach() and FLAG_ATTACHING
Posted by Johan Compagner <jc...@gmail.com>.
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 <ig...@gmail.com> 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 <jc...@gmail.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ja...@isencia.com> 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.
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: onAttach() and FLAG_ATTACHING
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <jc...@gmail.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ja...@isencia.com> 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.
> > >
> > >
> >
> >
>
>
Re: onAttach() and FLAG_ATTACHING
Posted by Johan Compagner <jc...@gmail.com>.
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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ja...@isencia.com> 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.
> >
> >
>
>
Re: onAttach() and FLAG_ATTACHING
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ja...@isencia.com> 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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ja...@isencia.com> 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.
>
>
Re: onAttach() and FLAG_ATTACHING
Posted by Johan Compagner <jc...@gmail.com>.
>
> 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.
yes but this doesn't hold. What happens if you extend an object (yours or
not your own)
that already implements onAttach() ?
We currently in wicket do already have all kinds of internalAttach and
things like that
that is messy
johan
Re: onAttach() and FLAG_ATTACHING
Posted by Jan Vermeulen <ja...@isencia.com>.
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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ja...@isencia.com> 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.
Re: onAttach() and FLAG_ATTACHING
Posted by Johan Compagner <jc...@gmail.com>.
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 <ig...@gmail.com> 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 <ja...@isencia.com> 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 <ja...@isencia.com> 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.
> >
> >
>
>
Re: onAttach() and FLAG_ATTACHING
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ja...@isencia.com> 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 <ja...@isencia.com> 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.
>
>
Re: onAttach() and FLAG_ATTACHING
Posted by Jan Vermeulen <ja...@isencia.com>.
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 <ja...@isencia.com> 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.
Re: onAttach() and FLAG_ATTACHING
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ja...@isencia.com> 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.
>
>