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.

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.

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to