[Zope-dev] bug in manage_pasteObjects ??
Romain Slootmaekers
romain at zzict.com
Mon Sep 1 11:07:54 EDT 2003
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.
More information about the Zope-Dev
mailing list