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.


Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to