[Zope-CMF] Re: backporting GenericSetup to CMF-1.5

[Florent Guillaume]

Rob Miller wrote:
> Florent Guillaume wrote:
> 
>> To repost an earlier mail:
>>
>>> The patch I propose to include is:
>>> http://mail.zope.org/pipermail/cmf-checkins/2005-November/007137.html
>>>
>>> Could some Plone folks please test that switching to
>>> CMF/branches/efge-1.5-five-compatible instead of CMF/branches/1.5 
>>> doesn't
>>> cause problems in Plone ? This patch just changes the order of base 
>>> class
>>> for File and Image, and to do the CMFCatalogAware recursion it calls its
>>> base class instead of redoing it by hand.
>>
>>
>> It *has* to be tested for Plone, as I have no idea what Plone does 
>> w.r.t CMFCatalogAware monkey-patching.
> 
> 
> i've taken a look at this, the patch definitely introduces some problems 
> w/ Plone.  the issue is that AT's BaseFolderMixin class, which is the 
> underlying class for all of Plone's folderish content, has a declaration 
> that looks like this:
> 
> 
> class BaseFolderMixin(CatalogMultiplex,
>                       BaseObject,
>                       PortalFolder,
>                       ):
> 
> 
> CatalogMultiplex is a subclass of CMFCatalogAware which overrides the 
> (un/re)indexObject methods to perform operations in multiple catalogs, 
> if necessary.  your patch changes CMFCatalogAware's manage_before* and 
> manage_after* methods so that it delegates to 'super' in order to handle 
> recursion w.r.t. containers, but in this case 'super' ends up being 
> BaseObject, and so the manage_(after|before)* methods in ObjectManager 
> (inherited via PortalFolder) never get called.

Can't BaseObject's manage_afterAdd & co use super() too? The goal is that 
everyone uses super() because if one piece of code doesn't, everything may 
break.

> to be fair, AT's (un)indexing code is a mess... i tried to change the 
> BaseFolderMixin manage_(after|before)* methods so they explicitly call 
> the PortalFolder implementations and was still ending up w/ subobject 
> orphans left in the catalog after container deletions.  ideally, this 
> would provide us an opportunity to push the CatalogMultiplex 
> functionality down into the CMF core and clean up the indexing mess on 
> the Plone side a bit.  and in a perfect world, we'd defer the actual 
> (un)indexing until the end of the transaction.  those changes might be 
> too much to try to get into CMF 1.6, however...

I've been using this kind of changes for a while in CPS so I know they're 
worthwile. They introduce semantic changes though (the updated catalog is 
not visible until the next request), which may be too much for some apps.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com