Actually no. I wrote that either a developer must either subclass both or none at all, but this should be documented. Instead of documenting that removeAll() does not invoke remove() I suggest you rephrase it as "subclassing guidelines" as I mentioned above so it is more explicit. Unless you choose to subclass, you won't care whether removeAll() invokes remove() under the hood.

Gili

Igor Vaynberg 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] <mailto:[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]
    <mailto:[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]
    <mailto:[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
    <http://ads.osdn.com/?ad_idv37&alloc_id865&opclick>
    _______________________________________________
    Wicket-user mailing list
    Wicket-user@lists.sourceforge.net
    <mailto:Wicket-user@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/wicket-user



--
http://www.desktopbeautifier.com/


-------------------------------------------------------
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_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to