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

Dieter Maurer wrote:

Romain Slootmaekers wrote at 2003-8-30 13:29 +0200:

...

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

I customized "_getCopyOf" for a similar requirement. But, I see, you do not have the "id" in the method.

...

... 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'. :)

It may not break the test suite but it will break my application (which relies on the current semantics).

Moreover, the current behaviour is consistent with the "manage_afterClone" companion "manage_afterAdd" (which is called, too, after copying and moving).

I would suggest:

In "_getCopyOf", you put the necessary information about the original in the copy (as a volatile attribute). In your "manage_afterClone", you look for this attribute and take appropriate action.

Yuk, this is ugly (but I guess I'll have to use it..) The fact remains that my use case: "clone wants to call method on original" is not something far fetched. An alternative solution would be to change the signature of the manage_afterClone method in something like def manage_afterClone(self,item,originalItem): """ even perhaps an originalItem = None parameter although that is ugly too (semantics) """ But that would require changes all over the code base, and in 3th party products too. So this probably isn't a feasible alternative either. Anyway, If you're reluctant to change anything about the zope-2.X copy-paste behaviour, can you guys atleast add the use case to the list for zope-3? Romain Slootmaekers.