Dieter Maurer wrote:
Romain Slootmaekers wrote at 2003-8-28 22:14 +0200:
> after an object is copied & paste, the following method is called:
> > > def manage_afterClone(self, item):
> """
> """
> > > > > as it happens, both self and item refer to the same object.... which > severely limits the use of the method. You probably want a reference to > the original object from which this one was cloned.


I am not so sure about this.

I think, in most use cases, it is sufficient to have the copied
object. At least for all currently handled use cases it is apparently
sufficient.
What use case do you have that needs the original object?

We have a content type that has 2 types of attributes: - private attributes (private as 'not shared') - shared attributes (btw, these reside in a RDB, the object only knows a primary key)

Only the original content object can modify the shared attributes
the others can view them but only edit their private attributes

This all works fine.

We want to delete all clones automatically when an original is deleted.
For this, we need an accounting scheme that notifies the original about its clones. The designated place to do this is manage_afterClone, but we lack the necessary information in that method, hence the suggested change.


So the official use case would be:
  "clone needs to call method on original."




Under no circumstances are you allowed to redefine the "item"
parameter above to refer to the original object (as suggested in
the quoted message):

  "manage_clone" is often implemented recursively and
  while in the top call "self" and "item" are identical,
  this changes in recursive calls.

  Knowing "item" (where the recursive "manage_clone" started)
  is essential to differentiate actions depending on the
  relative position of "item" with respect to other objects:

  e.g. initialize workflow when "item" is below the portal
  but do not when it is above.

  Code that makes these checks will break when you pass a differnt
  object as "item".


I changed my 2.6.1 and haven't noticed any defects (yet ;)) in the plone that uses this behaviour.


I'm willing to run the whole testset against my changes but this will cost me significant setup time as I'm not a (registered) zope developer.
as the changes only affect 10 lines, I was wondering if someone else would 'do the honours'. :)


Dieter

Romain








_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to