[
https://issues.apache.org/jira/browse/WICKET-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038156#comment-13038156
]
Igor Vaynberg commented on WICKET-3702:
---------------------------------------
actually there was a request to make add() behave normally for borders
clients can use border.addtobody() instead of add()
this is to make things more consistent. if i add() something i should be able
to remove() it and see it in iterator() and size()
> wicket:border: inconsistency between add() and remove()
> -------------------------------------------------------
>
> Key: WICKET-3702
> URL: https://issues.apache.org/jira/browse/WICKET-3702
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 1.5-RC4
> Reporter: Antti S. Lankila
> Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Assuming c1 is a Border and c2 is some component, the following sequence
> crashes with duplicate addition:
> c1.add(c2);
> c1.remove(c2);
> c1.add(c2);
> The reason for this is that remove() doesn't remove the object from the
> bodycontainer. The sequence can be made to work by changing the middle line
> to:
> c1.getBodyContainer().remove(c2);
> That remove() doesn't look the component from the same container as add()
> adds it to, seems to violate the principle of least astonishment.
> Unfortunately the Component structure manipulation API has more methods, such
> as swap(), size(), get(), etc. which are final, and can't be overridden by
> Border as they are. It could be best to force all users to use
> c1.getBodyContainer().add() instead of c1.add(), because consistent operation
> is probably easier to deal with in the long run than behavior that conforms
> to initial assumptions but has flaws elsewhere.
> This ticket suggests removing the overload of add() and documenting the
> difference in migration guide.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
