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 <[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. >> >> > > -- 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.
