Raphael Ritz wrote:
> I know I'm getting myself in danger now as I know too little
> yet about Zope 3 and I have no practical experience whatsoever
> using the new event system or not even the slightes idea to
> what extend the work for CMF-2.0 already achieved progress here.
> So, before I start digging deeper into this I have some
> fundamental (and hopefully trivial!) questions:
> This is about using events for catalog awareness
> If it's already there, please tell me and you can
> stop reading. If not:
> What would it need to get there?
> I consider support for container events as given (Zope 2.9
> or Zope 2.8 and Five 1.2).
> - Does that mean these events are there now when content
> is added/changed/removed in a CMF site or is there anything
> to be done first (like declaring Portal[Folder|Content]
> to provide some interface and making them generate these
> events?; add or change some base classes?)
There are there provided my branch is merged.
Note that this only deals with container add/moved/removed events, not
> - Is there anything like a ZCatalog in Zope 3 including event
> handlers for IObject[Added|Removed|Changed|...]Event triggering
> [index|unindex|reindex] etc?
> If not: providing such handlers for the current catalog
> should be straight-forward. Something like
> getToolByName(obj, 'portal_catalog').[un|re]indexObject(obj)
> or am I missing something? (how to deal with multiple
> catalogs? wouldn't this be the wrong place for handling
> this anyway? but where then?)
> - Glueing it together needs some interface on the content
> side. E.g., say there is a marker interface 'ICatalogAware'
> declared for portal content and portal folder.
> Then we could configure subscribers like
> where - again - the handler could be as easy as
> def addedContent(obj, event):
> getToolByName(obj, 'portal_catalog').indexObject(obj)
Yes that's the idea, except you can't just subscribed to IObjectAddedEvent
to check for adds, see my blog.
> (BTW: where are those handlers typically defined?
> Should it be a method of the specific tool or a more
> general utility? If defined on the tool itself, how would
> one deal with several instances - either different CMF sites
> in one Zope instance or several catalogs in one portal site)
They are handlers for ICatalogAware so they'd be defined in the same
package, here CMFCore.
> Now my questions: is the outline given above correct?
> At least w.r.t. the big picute?
Yes. But you're missing "IObjectModified" events, which need to be sent
whenever some content is modified. There are various steps to the transition:
1. you could send the event from CMFCatalogAware's reindexObject()
2. you could send it directly from all places in the code that call
> If so: Having this in place shouldn't this allow for easy
> extension to multiple catalogs (like the uid or reference
> catalogs from AT) by simply registering them as further
> subscribers to the respective events? How to do that?
> (RTFM manual pointers welcome; maybe I just need to
> read Philipp's chapter on sites and local utilies again
> but as of now I don't see how you get this together with
> the TTW generation of arbirary many CMF and/or Plone
> sites in one Zope instance).
> If this would be all true, is it correct to infer
> then that this is something Plone shouldn't have to
> deal with at all (except for configuration)?
All application frameworks, Plone included, will have to send
IObjectModifiedEvent from many places.
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
See http://collector.zope.org/CMF for bug reports and feature requests