[z3-five] Re: Bug in eventconfigure in zope-2.8

[Janko Hauser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Am 27.03.2006 um 19:02 schrieb Florent Guillaume:

> Philipp von Weitershausen wrote:
>> Martijn Faassen wrote:
>>> Tres Seaver wrote:
>>> [snip]
>>>>> Instead you may just want to install Five 1.2 into Zope 2.8. It  
>>>>> might
>>>>> have the fixes already (it at least has significant changes in  
>>>>> the event
>>>>> story compared to Five 1.0). If the bug is still in Five 1.2,  
>>>>> then we
>>>>> need to fix it and we could do another release.
>>>>
>>>> You're suggesting that Janko do that installation locally,  
>>>> rather than
>>>> that we do that change in the Zope SVN, right?  I don't think  
>>>> doing a
>>>> major version change to the Five bundled with Zope 2.8 between  
>>>> 2.8.6 and
>>>> 2.8.7 would fit the "maintenance only" policy for that branch.
>>>>
>>> My suggestion was for a local instal only. I now saw a suggestion by
>>> Philipp on zope-dev to do this for Zope proper.
>> For the record, it was Andreas's suggestion...
>>> That's indeed completely going to destroy the maintenance-only  
>>> policy
>>> for that branch. On the other hand, I imagine many developers  
>>> install
>>> Five 1.2 on top of that anyway.

Actually I'm not sure that the event stuff from 1.2 works without the  
corresponding changes in ObjectManager, but I have not tried it.

>> Yup.
>> Janko fixed one of his two problems for 1.0.3 (which hasn't been
>> included into the Zope 2.8 branch due to the discussion whether  
>> Five 1.2
>> should be included instead). The other one he described to me  
>> briefly on
>> IRC, but it was beyond my understanding of Five's event stuff. I  
>> suggest
>> he described it here and CCs Florent so that we can solve whatever
>> problem might exist.


With a recent install of Zope-2.8.6 I can not reproduce the error,  
but I will describe it here for the record.

The original code in eventconfigure is:

49 def manage_afterAdd(self, item, container):
50     original_location_path = getattr(self,  
'__five_location_path__', None)
51     self.__five_location_path__ = self.getPhysicalPath()
52     # if there still is an object in the original location, we're  
copied
53     # we cannot rely on manage_afterClone, as this gets triggered  
only
54     # *after* a manage_afterAdd. This logic might fail in the case  
where
55     # something *is* somehow left in the original location that can
56     # be traversed to.
57     is_copied = original_location_path and  
(self.unrestrictedTraverse(
58         original_location_path, None) is not None)
59     if is_copied:
60         notify(ObjectCopiedEvent(self))
61     if original_location_path is None or is_copied:
62         notify(ObjectAddedEvent(self))
63     else:
64         original_location = self.unrestrictedTraverse(
65             original_location_path[:-1])
66         notify(ObjectMovedEvent(self,
67                                 original_location,  
original_location_path[-1        ],
68                                 container, self.id))
69     # call original
70     method = getattr(self, '__five_original_manage_afterAdd', None)
71     if method is not None:
72         self.__five_original_manage_afterAdd(item, container)

To handle copy and paste in our case I needed to change line 65 to

   original_location_path[:-1], None)

Looking at the implementation of unrestrictedTraverse the "None" is  
used instead of a marker _marker=object(). But I find an interface  
definition in Five where default is "None".

The error which sometimes occured looked like this traceback:

Traceback (most recent call last):
   File "/opt/zope-2.8.6/lib/python/ZPublisher/Publish.py", line 114,  
in publish
     request, bind=1)
   File "/opt/zope-2.8.6/lib/python/ZPublisher/mapply.py", line 88,  
in mapply
     if debug is not None: return debug(object,args,context)
   File "/opt/zope-2.8.6/lib/python/ZPublisher/Publish.py", line 40,  
in call_object
     result=apply(object,args) # Type s<cr> to step into published  
object.
   File "/home/union/dgb/Products/uccore/core/ucbaseview.py", line  
65, in before_action_hook
   File "/home/union/dgb/Products/uccore/composer2/ 
folder_editing.py", line 44, in rename
   File "/opt/zope-2.8.6/lib/python/OFS/CopySupport.py", line 253, in  
manage_renameObjects
     self.manage_renameObject(ids[i], new_ids[i], REQUEST)
   File "/home/union/dgb/Products/orderedbtreefolder/ 
orderedbtreefolder.py", line 184, in manage_renameObject
   File "/opt/zope-2.8.6/lib/python/OFS/CopySupport.py", line 282, in  
manage_renameObject
     self._setObject(new_id, ob, set_owner=0)
   File "/opt/zope-2.8.6/lib/python/Products/BTreeFolder2/ 
BTreeFolder2.py", line 431, in _setObject
     object.manage_afterAdd(object, self)
   File "/opt/zope-2.8.6/lib/python/Products/Five/eventconfigure.py",  
line 72, in manage_afterAdd
     self.__five_original_manage_afterAdd(item, container)
   File "/home/union/dgb/Products/CMFCore/CMFCatalogAware.py", line  
148, in manage_afterAdd
   File "/home/union/dgb/Products/CMFCore/CMFCatalogAware.py", line  
177, in __recurse  File "/opt/zope-2.8.6/lib/python/Products/Five/ 
eventconfigure.py", line 64, in manage_afterAdd
     original_location = self.unrestrictedTraverse(
   File "/opt/zope-2.8.6/lib/python/OFS/Traversable.py", line 182, in  
unrestrictedTraverse
     next = bobo_traverse(REQUEST, name)
   File "/opt/zope-2.8.6/lib/python/Products/Five/traversable.py",  
line 85, in __bobo_traverse__
     return self.__fallback_traverse__(REQUEST, name)
   File "/opt/zope-2.8.6/lib/python/Products/Five/traversable.py",  
line 55, in __fallback_traverse__
     raise AttributeError, name
AttributeError: copy_of_projektplanung

I'm not sure, if the change should actually be applied. If Florent or  
someone else has a possible explanation for this, I think I could add  
it, as it seems to have a low possibilty to break something and the  
code never worked before, because of the other fix.

Sorry to be not of more help,

__Janko Hauser










-----BEGIN PGP SIGNATURE-----

iD8DBQFEL6wVe7bTUi4B2KARAmM1AJ4sjWiTFoq5GC5uxZeBQVvOzHqnawCeO5Or
cEeDMCLFO9PMLr5sCV98J5A=
=FZF5
-----END PGP SIGNATURE-----