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 [EMAIL PROTECTED]
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
