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