[Zope-CMF] CMF events

[Florent Guillaume]

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 
"changed" events.

 >  - 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
 >
 >  ...
 >   <subscriber
 >       for="Products.CMFCore.interfaces.ICatalogAware
 >            zope.app.container.interfaces.IObjectAddedEvent"
 >       handler="Products.CMFCore.CatalogTool.addedContent"
 >       />
 > ...
 >   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 
reindexObject()

 > 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

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com