Charlie Clark wrote:
Am 11.11.2008 um 16:52 schrieb yuppie:
AFAICT PortalFolder inherits from CMFCatalogAware to make sure it has
the same manage_afterAdd, manage_afterClone and manage_beforeDelete
methods as other content classes. But these methods are gone, so I
guess
the dependency is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charlie Clark wrote:
Am 12.11.2008 um 11:53 schrieb yuppie:
This is the checkin that added CMFCatalogAware to PortalFolder:
http://svn.zope.org/?rev=35114view=rev
Wow, that's some time ago.
It explains why and how it was done. Maybe a first
Am 29.10.2008 um 16:53 schrieb yuppie:
I don't think so. OFS.interfaces.IObjectWillBeRemovedEvent is derived
from OFS.interfaces.IObjectWillBeMovedEvent. So these lines in
handleContentishEvent() should unindex the object:
elif IObjectWillBeMovedEvent.providedBy(event):
if
Hi Charlie!
Charlie Clark wrote:
Digging around I've realised that this is because I have
folderish objects which inherit from PortalFolder which explicitly
deactivates the ICMFCatalogAware methods. Is there any point in
implementing ICMFCatalogAware or IWorkflowAware for Folders? What
Am 11.11.2008 um 16:52 schrieb yuppie:
AFAICT PortalFolder inherits from CMFCatalogAware to make sure it has
the same manage_afterAdd, manage_afterClone and manage_beforeDelete
methods as other content classes. But these methods are gone, so I
guess
the dependency is no longer needed.
Hi,
I noticed in an object derived from CMFCatalogAware that it wasn't
being removed from the catalogue upon deletion. Looking at the event
handlers in CMFCatalogAware it's clear that nothing handles
IObjectWillBeRemovedEvent. Is this intentional or mereley an oversight?
Charlie
--
Charlie
