Hi, since I've been struggling with wicket attaching/detaching for more than a month (I'm developing some models which rely on being properly detached), I'll share my thoughts on this issue:-)
> but now that i think about it, i think i would be ok with removing > onattach() altogether. the reason is that it can be quite wasteful. when > invoking a simple listener, like link's onclick we have to attach the > entire page, and i think most of that will go to waste. i think a lazy-load > pattern, just like the one we use in models works much better here and > maybe we should force it onto our users. i would like to see if anyone can > come up with viable usecases for the onattach() within this new definition. I must agree with that - since onAttach is most often used to modify component's state (visibility, new children, ...) and not to attach any resources (as it was probably intended to) it should be refactored to a method which should be invoked after the listener phase and before the render phase. Users can create they own onAttach mehtod and call it if the need it. IModel also defines only detach() and no attach(). > this means that all code that is in onattach needs to move to onbeforerender > and onbeforerender needs to be relaxed to allow changes in the component > hierarchy, while onattach should not allow modification of hierarchy. Moreover, the new onBeforeRender should be invoked on all components that could be rendered, not only on visible components as it is now... Finally I'd like to suggest one more refactorization: To make Component#isVisible final becase overriding this method will - in most cases - silently break setVisible and can be IMHO quite harmful. Overridden isVisible could be always replaced by calling setVisible(...) in the new onBeforeRender method. Regards, Bendis
