When a component is removed from the tree, onRemove is called on it and all its children, so they can do cleanup. When a component is added to the page, there is no similar call that could do initializations.
Note: onInitialize sounds similar, but is actually rather different: onInitialize is called exactly once, the very first time the component is added to the page's component tree. It is basically a delayed constructor to allow superclasses to depend on (abstract) methods implemented by subclasses while giving the subclass's constructor a chance to run.
onInitialize is not called again if a component is removed from the hierarchy and then added again. This happens, for example, in wizards, and in pages that replace panels to show different views.
A good example is FencedFeedbackPanel, with the issue reported in
WICKET-5265: in onRemove, the FFP clears the fence marker in its fence component. Stepping forward in a wizard where a step contains such an FFP causes onRemove to be called. Going backwards then re-adds the step panel and its FFP, but the fence is now broken, because the FFP has no way of knowing that it was re-added.
I tried working around it using onConfigure and onBeforeRender. But due to the way Wicket traverses the component tree, it is not always guaranteed that this will be called soon enough, i.e. before an outer FFP has already "stolen" the feedback messages that should have been protected by the fence.
I therefore propose adding a method onAddToPage that is called:
- whenever a component or one of its parents is added to the page component tree, i.e. when it gets a connection to the page.
- never more than once per add
- never before the parent components are initialized.
If a component is added to a container before the container is added to the page, this method should NOT be called - only when there is a path to the page.
I have an implementation of this that is tested and fixes the problem in
WICKET-5265. I'll push it to a branch as soon as I can. It's currently based on wicket-6.x but is easily portable to 7. It's not an API break, since only non-abstract methods are added.