Florent Guillaume wrote:
Rob Miller wrote:
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.
yes... i'll play around with this this evening.
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.
good point. thx for the warning.
-r
_______________________________________________
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
