isFirstAttach() convenience method

[Jonathan Locke <jo...@gmail.com>]

Although I do still think we should generally discourage two-phase
construction, it is occasionally truly necessary and it seems like it might
be nice to have a method up in Component that uses those component bits to
return whether the component has been attached already. This way, when two
phase truly is needed, you don't need to implement a boolean for use in your
onAttach(). Instead you would call isFirstAttach() which would check a
single lighter-weight bit (versus 16 or even 32 bits per component in a
subclass (depending on processor architecture and alignment considerations
of the JVM)).  I'm not neccessarily /gung-ho/ about this idea, but the core
is in a unique position to add this to the root Component class and I
personally would use it if it existed in those unusual cases where I need to
do two-phase construction. I think other developers might like it as well.
Thoughts?

-- 
View this message in context: http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10324166
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Re: isFirstAttach() convenience method

[Igor Vaynberg <ig...@gmail.com>]

as of yesterday it is

-igor


On 5/4/07, Ivo van Dongen <iv...@gmail.com> wrote:
>
> On 5/4/07, James McLaughlin <jo...@gmail.com> wrote:
> >
> > fwiw, i've occasionally wanted an onRemove callback in the component
> (and
> > now behavior :) )
>
>
>
> Did I mis something? Is it possible to remove behaviors now?  That would
> be
> great, this was something I ran into last week with a timer behavior.
>
> Regard,
> Ivo
>
> hierarchy so the object can undo some of its "damage" when
> > replaced. If we had this, then we could leave that issue to the
> > developer's
> > discretion. I've had to use the two phase init pattern occassionally, so
> > this would be minorly helpful, and does avoid the two phase construction
> > proposal that would make wicket a managed framework. Maybe it can be
> > called
> > onFirstAttach, which seems to jibe better with the wicket model of
> > providing
> > callbacks into the lifecycle rather than forcing it top down.
> >
> > best,
> > jim
> >
> > On 5/4/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > >
> > > so is it a firstattach if you remove a component and then readd it at
> a
> > > later time?
> > >
> > > -igor
> > >
> > >
> > > On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
> > > >
> > > >
> > > > Although I do still think we should generally discourage two-phase
> > > > construction, it is occasionally truly necessary and it seems like
> it
> > > > might
> > > > be nice to have a method up in Component that uses those component
> > bits
> > > to
> > > > return whether the component has been attached already. This way,
> when
> > > two
> > > > phase truly is needed, you don't need to implement a boolean for use
> > in
> > > > your
> > > > onAttach(). Instead you would call isFirstAttach() which would check
> a
> > > > single lighter-weight bit (versus 16 or even 32 bits per component
> in
> > a
> > > > subclass (depending on processor architecture and alignment
> > > considerations
> > > > of the JVM)).  I'm not neccessarily /gung-ho/ about this idea, but
> the
> > > > core
> > > > is in a unique position to add this to the root Component class and
> I
> > > > personally would use it if it existed in those unusual cases where I
> > > need
> > > > to
> > > > do two-phase construction. I think other developers might like it as
> > > well.
> > > > Thoughts?
> > > >
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10324166
> > > > Sent from the Wicket - Dev mailing list archive at Nabble.com.
> > > >
> > > >
> > >
> >
>
>
>
> --
> Ivo van Dongen
> Func. Internet Integration
> W http://www.func.nl
> T +31 20 4230000
> F +31 20 4223500
>

Re: isFirstAttach() convenience method

[Ivo van Dongen <iv...@gmail.com>]

On 5/4/07, James McLaughlin <jo...@gmail.com> wrote:
>
> fwiw, i've occasionally wanted an onRemove callback in the component (and
> now behavior :) )



Did I mis something? Is it possible to remove behaviors now?  That would be
great, this was something I ran into last week with a timer behavior.

Regard,
Ivo

hierarchy so the object can undo some of its "damage" when
> replaced. If we had this, then we could leave that issue to the
> developer's
> discretion. I've had to use the two phase init pattern occassionally, so
> this would be minorly helpful, and does avoid the two phase construction
> proposal that would make wicket a managed framework. Maybe it can be
> called
> onFirstAttach, which seems to jibe better with the wicket model of
> providing
> callbacks into the lifecycle rather than forcing it top down.
>
> best,
> jim
>
> On 5/4/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > so is it a firstattach if you remove a component and then readd it at a
> > later time?
> >
> > -igor
> >
> >
> > On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
> > >
> > >
> > > Although I do still think we should generally discourage two-phase
> > > construction, it is occasionally truly necessary and it seems like it
> > > might
> > > be nice to have a method up in Component that uses those component
> bits
> > to
> > > return whether the component has been attached already. This way, when
> > two
> > > phase truly is needed, you don't need to implement a boolean for use
> in
> > > your
> > > onAttach(). Instead you would call isFirstAttach() which would check a
> > > single lighter-weight bit (versus 16 or even 32 bits per component in
> a
> > > subclass (depending on processor architecture and alignment
> > considerations
> > > of the JVM)).  I'm not neccessarily /gung-ho/ about this idea, but the
> > > core
> > > is in a unique position to add this to the root Component class and I
> > > personally would use it if it existed in those unusual cases where I
> > need
> > > to
> > > do two-phase construction. I think other developers might like it as
> > well.
> > > Thoughts?
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10324166
> > > Sent from the Wicket - Dev mailing list archive at Nabble.com.
> > >
> > >
> >
>



-- 
Ivo van Dongen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500

Re: isFirstAttach() convenience method

[James McLaughlin <jo...@gmail.com>]

fwiw, i've occasionally wanted an onRemove callback in the component (and
now behavior :) ) hierarchy so the object can undo some of its "damage" when
replaced. If we had this, then we could leave that issue to the developer's
discretion. I've had to use the two phase init pattern occassionally, so
this would be minorly helpful, and does avoid the two phase construction
proposal that would make wicket a managed framework. Maybe it can be called
onFirstAttach, which seems to jibe better with the wicket model of providing
callbacks into the lifecycle rather than forcing it top down.

best,
jim

On 5/4/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> so is it a firstattach if you remove a component and then readd it at a
> later time?
>
> -igor
>
>
> On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
> >
> >
> > Although I do still think we should generally discourage two-phase
> > construction, it is occasionally truly necessary and it seems like it
> > might
> > be nice to have a method up in Component that uses those component bits
> to
> > return whether the component has been attached already. This way, when
> two
> > phase truly is needed, you don't need to implement a boolean for use in
> > your
> > onAttach(). Instead you would call isFirstAttach() which would check a
> > single lighter-weight bit (versus 16 or even 32 bits per component in a
> > subclass (depending on processor architecture and alignment
> considerations
> > of the JVM)).  I'm not neccessarily /gung-ho/ about this idea, but the
> > core
> > is in a unique position to add this to the root Component class and I
> > personally would use it if it existed in those unusual cases where I
> need
> > to
> > do two-phase construction. I think other developers might like it as
> well.
> > Thoughts?
> >
> > --
> > View this message in context:
> >
> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10324166
> > Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >
> >
>

Re: isFirstAttach() convenience method

[Jonathan Locke <jo...@gmail.com>]

oh that's right. i totally forgot about that semantics change. is that
already in trunk?

i think this since this is really just for initing components that need
context, under the new semantics we would only need isFirstRender and
isFirstRenderAfterAdd. that seems fairly clean and self-explanatory. we'd
avoid any state booleans for attachment. i can't see the use for that with
the new semantics of onAttach and onBeforeRender. can you?


igor.vaynberg wrote:
> 
> will we also have isFirstBeforeRender and isFirstBeforeRenderAfterAdd?
> since
> in onattach you cannot modify component hierarchy anymore, and you
> shouldnt
> really be attaching models in onbeforerender.
> 
> -igor
> 
> 
> On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
>>
>>
>>
>> right.
>>
>> well, if the component wants to check for re-init, the method should
>> definitely not be called isFirstAttach() because a re-init is not a first
>> attachment.
>>
>> i think there's a compelling and very common use case for one-shot
>> isFirstAttach() that works exactly like a constructor with the right
>> context
>> available. that would be very unsurprising behavior for a method with
>> that
>> name and i'd be worried about overloading it for re-init because those
>> using
>> a method with that name would not expect it to ever be true a second
>> time.
>>
>> so if we want to support a re-init on re-add (which actually seems like
>> it
>> would be pretty rare), i think we ought to have a separate boolean that's
>> explicit to that exact use case so it's 100% clear what it does.  so
>> perhaps:
>>
>> isFirstAttach - only true during the very first call to onAttach()
>>
>> isFirstAttachAfterAdd - true during the first call to onAttach after each
>> re-parenting of the component
>>
>> we'd put @see javadoc references on each method to make sure people know
>> there are two of these methods for different purposes.
>>
>>
>> igor.vaynberg wrote:
>> >
>> > well i dont know
>> >
>> > if you need second-phase-init then you are likely doing something that
>> is
>> > "context-sensitive" because this context is the only thing you are
>> missing
>> > in the constructor really.
>> >
>> > so when you move things around the context changes, so should the
>> > component
>> > reinit itself?
>> >
>> > -igor
>> >
>> >
>> > On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> good question.  re-adding dynamism seems like a fairly unusual use
>> case
>> >> (can
>> >> you think of any good ones?) so i think the answer is probably no.  it
>> >> seems
>> >> like if you have a component that dynamically does things on being
>> >> re-added
>> >> you could manage that case on your own.
>> >>
>> >>
>> >> igor.vaynberg wrote:
>> >> >
>> >> > so is it a firstattach if you remove a component and then readd it
>> at
>> a
>> >> > later time?
>> >> >
>> >> > -igor
>> >> >
>> >> >
>> >> > On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >> Although I do still think we should generally discourage two-phase
>> >> >> construction, it is occasionally truly necessary and it seems like
>> it
>> >> >> might
>> >> >> be nice to have a method up in Component that uses those component
>> >> bits
>> >> >> to
>> >> >> return whether the component has been attached already. This way,
>> when
>> >> >> two
>> >> >> phase truly is needed, you don't need to implement a boolean for
>> use
>> >> in
>> >> >> your
>> >> >> onAttach(). Instead you would call isFirstAttach() which would
>> check
>> a
>> >> >> single lighter-weight bit (versus 16 or even 32 bits per component
>> in
>> >> a
>> >> >> subclass (depending on processor architecture and alignment
>> >> >> considerations
>> >> >> of the JVM)).  I'm not neccessarily /gung-ho/ about this idea, but
>> the
>> >> >> core
>> >> >> is in a unique position to add this to the root Component class and
>> I
>> >> >> personally would use it if it existed in those unusual cases where
>> I
>> >> need
>> >> >> to
>> >> >> do two-phase construction. I think other developers might like it
>> as
>> >> >> well.
>> >> >> Thoughts?
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10324166
>> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10327822
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10333603
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10333700
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Re: isFirstAttach() convenience method

[Igor Vaynberg <ig...@gmail.com>]

will we also have isFirstBeforeRender and isFirstBeforeRenderAfterAdd? since
in onattach you cannot modify component hierarchy anymore, and you shouldnt
really be attaching models in onbeforerender.

-igor


On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
>
> right.
>
> well, if the component wants to check for re-init, the method should
> definitely not be called isFirstAttach() because a re-init is not a first
> attachment.
>
> i think there's a compelling and very common use case for one-shot
> isFirstAttach() that works exactly like a constructor with the right
> context
> available. that would be very unsurprising behavior for a method with that
> name and i'd be worried about overloading it for re-init because those
> using
> a method with that name would not expect it to ever be true a second time.
>
> so if we want to support a re-init on re-add (which actually seems like it
> would be pretty rare), i think we ought to have a separate boolean that's
> explicit to that exact use case so it's 100% clear what it does.  so
> perhaps:
>
> isFirstAttach - only true during the very first call to onAttach()
>
> isFirstAttachAfterAdd - true during the first call to onAttach after each
> re-parenting of the component
>
> we'd put @see javadoc references on each method to make sure people know
> there are two of these methods for different purposes.
>
>
> igor.vaynberg wrote:
> >
> > well i dont know
> >
> > if you need second-phase-init then you are likely doing something that
> is
> > "context-sensitive" because this context is the only thing you are
> missing
> > in the constructor really.
> >
> > so when you move things around the context changes, so should the
> > component
> > reinit itself?
> >
> > -igor
> >
> >
> > On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
> >>
> >>
> >>
> >> good question.  re-adding dynamism seems like a fairly unusual use case
> >> (can
> >> you think of any good ones?) so i think the answer is probably no.  it
> >> seems
> >> like if you have a component that dynamically does things on being
> >> re-added
> >> you could manage that case on your own.
> >>
> >>
> >> igor.vaynberg wrote:
> >> >
> >> > so is it a firstattach if you remove a component and then readd it at
> a
> >> > later time?
> >> >
> >> > -igor
> >> >
> >> >
> >> > On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
> >> >>
> >> >>
> >> >> Although I do still think we should generally discourage two-phase
> >> >> construction, it is occasionally truly necessary and it seems like
> it
> >> >> might
> >> >> be nice to have a method up in Component that uses those component
> >> bits
> >> >> to
> >> >> return whether the component has been attached already. This way,
> when
> >> >> two
> >> >> phase truly is needed, you don't need to implement a boolean for use
> >> in
> >> >> your
> >> >> onAttach(). Instead you would call isFirstAttach() which would check
> a
> >> >> single lighter-weight bit (versus 16 or even 32 bits per component
> in
> >> a
> >> >> subclass (depending on processor architecture and alignment
> >> >> considerations
> >> >> of the JVM)).  I'm not neccessarily /gung-ho/ about this idea, but
> the
> >> >> core
> >> >> is in a unique position to add this to the root Component class and
> I
> >> >> personally would use it if it existed in those unusual cases where I
> >> need
> >> >> to
> >> >> do two-phase construction. I think other developers might like it as
> >> >> well.
> >> >> Thoughts?
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10324166
> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10327822
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10333603
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>

Re: isFirstAttach() convenience method

[Jonathan Locke <jo...@gmail.com>]

right.  

well, if the component wants to check for re-init, the method should
definitely not be called isFirstAttach() because a re-init is not a first
attachment.

i think there's a compelling and very common use case for one-shot
isFirstAttach() that works exactly like a constructor with the right context
available. that would be very unsurprising behavior for a method with that
name and i'd be worried about overloading it for re-init because those using
a method with that name would not expect it to ever be true a second time.

so if we want to support a re-init on re-add (which actually seems like it
would be pretty rare), i think we ought to have a separate boolean that's
explicit to that exact use case so it's 100% clear what it does.  so
perhaps:

isFirstAttach - only true during the very first call to onAttach()

isFirstAttachAfterAdd - true during the first call to onAttach after each
re-parenting of the component

we'd put @see javadoc references on each method to make sure people know
there are two of these methods for different purposes.


igor.vaynberg wrote:
> 
> well i dont know
> 
> if you need second-phase-init then you are likely doing something that is
> "context-sensitive" because this context is the only thing you are missing
> in the constructor really.
> 
> so when you move things around the context changes, so should the
> component
> reinit itself?
> 
> -igor
> 
> 
> On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
>>
>>
>>
>> good question.  re-adding dynamism seems like a fairly unusual use case
>> (can
>> you think of any good ones?) so i think the answer is probably no.  it
>> seems
>> like if you have a component that dynamically does things on being
>> re-added
>> you could manage that case on your own.
>>
>>
>> igor.vaynberg wrote:
>> >
>> > so is it a firstattach if you remove a component and then readd it at a
>> > later time?
>> >
>> > -igor
>> >
>> >
>> > On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
>> >>
>> >>
>> >> Although I do still think we should generally discourage two-phase
>> >> construction, it is occasionally truly necessary and it seems like it
>> >> might
>> >> be nice to have a method up in Component that uses those component
>> bits
>> >> to
>> >> return whether the component has been attached already. This way, when
>> >> two
>> >> phase truly is needed, you don't need to implement a boolean for use
>> in
>> >> your
>> >> onAttach(). Instead you would call isFirstAttach() which would check a
>> >> single lighter-weight bit (versus 16 or even 32 bits per component in
>> a
>> >> subclass (depending on processor architecture and alignment
>> >> considerations
>> >> of the JVM)).  I'm not neccessarily /gung-ho/ about this idea, but the
>> >> core
>> >> is in a unique position to add this to the root Component class and I
>> >> personally would use it if it existed in those unusual cases where I
>> need
>> >> to
>> >> do two-phase construction. I think other developers might like it as
>> >> well.
>> >> Thoughts?
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10324166
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10327822
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10333603
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Re: isFirstAttach() convenience method

[Igor Vaynberg <ig...@gmail.com>]

well i dont know

if you need second-phase-init then you are likely doing something that is
"context-sensitive" because this context is the only thing you are missing
in the constructor really.

so when you move things around the context changes, so should the component
reinit itself?

-igor


On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
>
> good question.  re-adding dynamism seems like a fairly unusual use case
> (can
> you think of any good ones?) so i think the answer is probably no.  it
> seems
> like if you have a component that dynamically does things on being
> re-added
> you could manage that case on your own.
>
>
> igor.vaynberg wrote:
> >
> > so is it a firstattach if you remove a component and then readd it at a
> > later time?
> >
> > -igor
> >
> >
> > On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
> >>
> >>
> >> Although I do still think we should generally discourage two-phase
> >> construction, it is occasionally truly necessary and it seems like it
> >> might
> >> be nice to have a method up in Component that uses those component bits
> >> to
> >> return whether the component has been attached already. This way, when
> >> two
> >> phase truly is needed, you don't need to implement a boolean for use in
> >> your
> >> onAttach(). Instead you would call isFirstAttach() which would check a
> >> single lighter-weight bit (versus 16 or even 32 bits per component in a
> >> subclass (depending on processor architecture and alignment
> >> considerations
> >> of the JVM)).  I'm not neccessarily /gung-ho/ about this idea, but the
> >> core
> >> is in a unique position to add this to the root Component class and I
> >> personally would use it if it existed in those unusual cases where I
> need
> >> to
> >> do two-phase construction. I think other developers might like it as
> >> well.
> >> Thoughts?
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10324166
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10327822
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>

Re: isFirstAttach() convenience method

[Jonathan Locke <jo...@gmail.com>]

good question.  re-adding dynamism seems like a fairly unusual use case (can
you think of any good ones?) so i think the answer is probably no.  it seems
like if you have a component that dynamically does things on being re-added
you could manage that case on your own.  


igor.vaynberg wrote:
> 
> so is it a firstattach if you remove a component and then readd it at a
> later time?
> 
> -igor
> 
> 
> On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
>>
>>
>> Although I do still think we should generally discourage two-phase
>> construction, it is occasionally truly necessary and it seems like it
>> might
>> be nice to have a method up in Component that uses those component bits
>> to
>> return whether the component has been attached already. This way, when
>> two
>> phase truly is needed, you don't need to implement a boolean for use in
>> your
>> onAttach(). Instead you would call isFirstAttach() which would check a
>> single lighter-weight bit (versus 16 or even 32 bits per component in a
>> subclass (depending on processor architecture and alignment
>> considerations
>> of the JVM)).  I'm not neccessarily /gung-ho/ about this idea, but the
>> core
>> is in a unique position to add this to the root Component class and I
>> personally would use it if it existed in those unusual cases where I need
>> to
>> do two-phase construction. I think other developers might like it as
>> well.
>> Thoughts?
>>
>> --
>> View this message in context:
>> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10324166
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10327822
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Re: isFirstAttach() convenience method

[Igor Vaynberg <ig...@gmail.com>]

so is it a firstattach if you remove a component and then readd it at a
later time?

-igor


On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
> Although I do still think we should generally discourage two-phase
> construction, it is occasionally truly necessary and it seems like it
> might
> be nice to have a method up in Component that uses those component bits to
> return whether the component has been attached already. This way, when two
> phase truly is needed, you don't need to implement a boolean for use in
> your
> onAttach(). Instead you would call isFirstAttach() which would check a
> single lighter-weight bit (versus 16 or even 32 bits per component in a
> subclass (depending on processor architecture and alignment considerations
> of the JVM)).  I'm not neccessarily /gung-ho/ about this idea, but the
> core
> is in a unique position to add this to the root Component class and I
> personally would use it if it existed in those unusual cases where I need
> to
> do two-phase construction. I think other developers might like it as well.
> Thoughts?
>
> --
> View this message in context:
> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10324166
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>

Re: isFirstAttach() convenience method

[Johan Compagner <jc...@gmail.com>]

I am against this method
If you want that do it your self.
its simple

MyPage extends WebPage
{
   private boole firstAttached = false;


  onAttach()
 {
   if (firstAttached) // do something
   firstAttached = true
  }
}

johan

On 5/4/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
> Although I do still think we should generally discourage two-phase
> construction, it is occasionally truly necessary and it seems like it
> might
> be nice to have a method up in Component that uses those component bits to
> return whether the component has been attached already. This way, when two
> phase truly is needed, you don't need to implement a boolean for use in
> your
> onAttach(). Instead you would call isFirstAttach() which would check a
> single lighter-weight bit (versus 16 or even 32 bits per component in a
> subclass (depending on processor architecture and alignment considerations
> of the JVM)).  I'm not neccessarily /gung-ho/ about this idea, but the
> core
> is in a unique position to add this to the root Component class and I
> personally would use it if it existed in those unusual cases where I need
> to
> do two-phase construction. I think other developers might like it as well.
> Thoughts?
>
> --
> View this message in context:
> http://www.nabble.com/isFirstAttach%28%29-convenience-method-tf3692483.html#a10324166
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>