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 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

Reply via email to