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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
