[Zope-dev] Re: CopySupport bug or feature?

[Geoff Davis]

I've been talking to people on #zope about this.  They're scared to
touch the methods for backward compatibility reasons.

Maybe the way to go is to create some new methods that are called
recursively on objects when they are copied or moved.  How about:

def _beforeMove(self, 
		destination_container, 
		destination_path,
		recurse=True):
   # destination_container may be None (since for subobjects, the
   #    destination will not have been created yet)
   # destination_path is a tuple containing the physical path of
   #    the new container (which may not yet exist)
   # call subobjects recursively if recurse flag is True
   #
   # default implementation does nothing and returns self

def _afterMove(self, source_container, recurse=True)
   # source_container may be None (since for subobjects, the
   #    source may have been moved elsewhere)
   # source_path is a tuple containing the physical path of 
   #    the old container (which may no longer exist) 
   # call subobjects recursively if recurse flag is True 
   #
   # default implementation does nothing and returns self 

def _beforeCopy(self, destination_container, recurse=True):
   # destination_container may be None (since for subobjects, the
   #    destination will not have been created yet)
   # destination_path is a tuple containing the physical path of
   #    the new container (which may not yet exist)
   # call subobjects recursively if recurse flag is True
   #
   # default implementation does nothing and returns self
 
def _afterCopy(self, source_container, original_object, recurse=True):
   # source_path is a tuple containing the physical path of 
   #    the new container (which should still exist) 
   # call subobjects recursively if recurse flag is True 
   #
   # default implementation does nothing and returns self

The calls would look something like:

ob = ob._beforeMove(destination, destination.getPhysicalPath(), True)
... 
moved_ob = moved_ob._afterMove(source, source.getPhysicalPath(), True)

etc


Once we have a decent event system in place, these methods could be the
place where copy / move events are generated.

Thoughts?

Geoff

On Mon, 08 Aug 2005 11:26:55 -0400, Chris McDonough wrote:

> I've been able to get around this by creating a _notifyOfCopyTo on the
> folder type that does the recursion.  There's a delicate dance in some
> of my code that does some work in _notifyOfCopyTo and other work in
> _getCopy.  This could be improved I bet, but touching the code means
> that you surely own it forever. ;-)
> 
> On Mon, 2005-08-08 at 11:05 -0400, Geoff Davis wrote:
>> I have been developing some classes that need to know when they are copied
>> or moved.  I have been achieving this by adding my own versions of
>> _notifyOfCopyTo, _postCopy, and manage_afterClone.  Everything works as
>> expected when you copy / paste an individual object.  However, I have
>> recently been made aware of a problem with this approach: if you copy not
>> the object itself, but rather a folder containing the object, only
>> manage_afterClone is called.  In looking through OFS/CopySupport.py and
>> OFS/ObjectManager.py, I discovered the source of the problem:
>> manage_afterClone is called recursively on ObjectManagers, but
>> _notifyOfCopyTo and _postCopy are not.
>> 
>> Is this intentional?  If not, I'd like to check in a fix.
>> 
>> Geoff
>>