[Zope-CMF] Re: backporting GenericSetup to CMF-1.5
Florent Guillaume
fg at nuxeo.com
Tue Nov 15 05:19:49 EST 2005
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
More information about the Zope-CMF
mailing list