[Zope-CMF] Re: Bug with recursing into opaque items (__recurse in CMFCatalogAware)

[Gregoire Weber]

Hi,

>If this is a bug, it's a general bug, not one related to opaque items.

Yes.


>After staring for a while at this code, at ZCatalog.CatalogAwareness and at OFS.ObjectManager, I came to these conclusions:
>
>- Nowhere is defined which values should be passed to the 'item' and 'container' arguments of the manage_before*/manage_after* methods. Most manage_before*/manage_after* methods don't use these arguments at all.

That's it! I guessed their meaning by inserting prints in the respective 
SimpleItem manage_after/before methods to find out what the parameters
are.


>- The recursive manage_before*/manage_after* methods in CatalogAware and ObjectManager pass 'item' and 'container' just through, so by default 'item' is always the object and 'container' the container of the object on which the method was called first. This is also the behavior of CMFCatalogAware.

Yes. But for a callable attribute the item and container must have 
another meaning because the attribute is kind of deeper in the tree.


>'item' and 'container' as used by default seem to be quite useless, 

They're used somewhere (As I remember in ObjectManager). There is a check
if self == container: do some stuff.


>so giving them a new meaning in ICallableOpaqueItemEvents would not really hurt. But on the other hand the proposed meaning - 'item' for the container of the opaque item and container defunct - makes things not more intuitive.

Ok. Unfortnately my analysis is some weeks away and I can't remember the
details in which case item and container carry which meaning. But as I 
remember it makes some sense.

>Why not just taking the parent from the acquisition context and ignoring 'item' and 'container' completely?

Yes, this was/is a solution I thought also about. I tested it and worked also.
But for me the handling of opaque items in __recurse is buggy.

I can live with both solutions.

Gregoire