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