yes, this has to be clear in the javadoc, at least.
On 12/28/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > i think gili's point was more to the tune of the fact that he expects > removeall() to call remove() for each component as a contract. that way if > he overrides remove() and adds special functionality, he does not also have > to override removeall() because that should just forward the call to > remove() for each component. > > -Igor > > > > On 12/28/05, Laurent PETIT <[EMAIL PROTECTED]> wrote: > > > > What about something like an internalRemove() that does everything > > needed when the component is removed, but NOT versioning stuff. > > And a remove() method, that does call internalRemove() and do the > > versioning stuff. > > > > Then the internalRemove() of MarkupContainer could call each > > internalRemove() of each child component ... something like that ... > > (don't know if it is a good point or not, just an idea out of my > > brain). > > > > OR, in the remove method of the MarkupContainer, take care of browsing > > all the children and calling setParent(null) on them : a compromise > > between calling remove() on all children, and just getting rid of the > > children reference as it is done currently (I know that wicket is > > "unmanaged", but I think that a container component should be > > responsible of the lifecycle/management of its children components. > > > > > > > > > > On 12/28/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > so what you are saying is that we should not optimize removeall() and > just > > > make it loop over components and call container.remove() on them? > > > > > > this would be much simpler then the current implementation that performs > an > > > optimization that saves a lot of what would be wasted session space. > calling > > > removeall() on a container with 20 children using the simple > implementation > > > would cause 20 change objects created and added to the version history, > > > while using the current implementation only a single change object is > > > created. the net effect is the same. > > > > > > so this is a tradeoff between user's assumption of how the code works > and > > > efficiency ( how it actually works ). > > > > > > if you feel strongly about this then start a vote to change the > removeall() > > > impl to cascade remove() on each component. > > > > > > -Igor > > > > > > > > > > > > On 12/28/05, Gili <[EMAIL PROTECTED]> wrote: > > > > > > > > I (partially) disagree. Invoking removeAll() should be > equivilent > > > to > > > > invoking remove() on all children individually -- assuming no > > > > subclassing has occured. removeAll() might be more efficient, but if > it > > > > doesn't get the job done what's the point? If subclassing has entered > > > > into the discussion then both remove() and removeAll() will have to be > > > > subclassed as a team (similar to hashCode() and equals()). > > > > > > > > Gili > > > > > > > > Igor Vaynberg wrote: > > > > > i do not think removeAll() should call the regular remove(). > removeAll() > > > > > generates a single change object and clears out the children, i > think > > > > > that is enough. it does what it says in a simple and efficient way. > > > > > > > > > > -Igor > > > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_idv37&alloc_id865&opclick > > _______________________________________________ > > Wicket-user mailing list > > Wicket-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
