I'd like to revive this discussion about having events in the core. Sidnei even mentionned getting them in Zope directly, http://dev.zope.org/Wikis/DevSite/Proposals/IncludeEventsInCore I'm all for it, and would really help many people. It would be awesome if a minimal implementation could be compatible with Zope 2.7.4, maybe as an addon product. But there needs to be a few hooks in the core (object create/move/clone/delete). Could we try to move together on this ? For the record, CPS has to monkey-patch many things to have its events work, and now that many others want events (Plone for starters), it would be nice to have a common framework, a Zope3-ish framework if possible. Florent Tres wrote:
Sidnei da Silva wrote:
Is there any concrete plan for adding Events to CMF? It would be really nice if we could somehow use Five for that, but given all the constraints, what options we have?
Events are the major new feature planned ATM for CMF 1.6. My intent for them was to use the "thrown-over-the-wall" Zope 2 event products as a basis:
- http://cvs.zope.org/Products/Event
- http://cvs.zope.org/Products/EventListenerTool
as the basis for a CMFEvent product. Those tools are used in production in very large sites, and have been pounded pretty hard. Note that the listener tool allows you to define interface-based subscriptions, which invoke arbitrary scripts: that is a pretty powerful combination.
We would then modify the current content classes to pubish events (following the Zope3 pattern as closely as possible) rather than directly notifying the workflow, or cataloguing themselves, and make the appropriate tools subscribers via the listener tool.
I've implemented a very simple event registry, highly based on Zope3 events, which I think would be more than enough for most of the use cases. Would anyone be interested in adding this into CMF while we wait for the day some Zope3 stuff gets merged into Zope2?
Doctest attached. The implementation is about the same number of lines as the doctest *wink*.
The tools above are "placeful" ("local" in the Zope3 sense), which seems to be more Zope2 / CMF like than the global one (they allow subscriptions to persist across restarts, for one thing).
-- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
--On Montag, 6. Dezember 2004 18:32 Uhr +0100 Florent Guillaume <fg@nuxeo.com> wrote:
I'd like to revive this discussion about having events in the core.
Sidnei even mentionned getting them in Zope directly, http://dev.zope.org/Wikis/DevSite/Proposals/IncludeEventsInCore
I'm all for it, and would really help many people.
It would be awesome if a minimal implementation could be compatible with Zope 2.7.4, maybe as an addon product. But there needs to be a few hooks in the core (object create/move/clone/delete).
Do you volunteer to implement it for Zope 2.8 ? :-) In general +1 -aj
Andreas Jung wrote:
Florent Guillaume <fg@nuxeo.com> wrote:
I'd like to revive this discussion about having events in the core.
Sidnei even mentionned getting them in Zope directly, http://dev.zope.org/Wikis/DevSite/Proposals/IncludeEventsInCore
I'm all for it, and would really help many people.
It would be awesome if a minimal implementation could be compatible with Zope 2.7.4, maybe as an addon product. But there needs to be a few hooks in the core (object create/move/clone/delete).
Do you volunteer to implement it for Zope 2.8 ? :-)
Yes, if there is consensus on the proper way to do it. Florent
In general +1
-- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Florent Guillaume wrote:
I'd like to revive this discussion about having events in the core.
Sidnei even mentionned getting them in Zope directly, http://dev.zope.org/Wikis/DevSite/Proposals/IncludeEventsInCore
I'm all for it, and would really help many people.
It would be awesome if a minimal implementation could be compatible with Zope 2.7.4, maybe as an addon product. But there needs to be a few hooks in the core (object create/move/clone/delete).
Could we try to move together on this ?
Five already has had some work done in backporting the Zope 3 event system, so it'd be nice to be able to reuse this. I'd be willing to work together on this. I tried reasonably hard (there are at least some tests :) to get Zope to send the right Zope 3 style events on creation, copy and move. If we backport the Zope 3 story, we'd need to worry about importing issues. If we backport Zope 3 events, what package will they live in? How will this relate to Five? What other packages does this draw in (zope.interface definitely)? Etc. Five can make something send Zope 3 events right now by just another ZCML statement, though it drives a monkeypatch underneath.. Regards, Martijn
[Keeping only zope-dev, not zope-cmf] Martijn Faassen wrote:
Florent Guillaume wrote:
I'd like to revive this discussion about having events in the core.
Sidnei even mentionned getting them in Zope directly, http://dev.zope.org/Wikis/DevSite/Proposals/IncludeEventsInCore
I'm all for it, and would really help many people.
It would be awesome if a minimal implementation could be compatible with Zope 2.7.4, maybe as an addon product. But there needs to be a few hooks in the core (object create/move/clone/delete).
Could we try to move together on this ?
Five already has had some work done in backporting the Zope 3 event system, so it'd be nice to be able to reuse this. I'd be willing to work together on this. I tried reasonably hard (there are at least some tests :) to get Zope to send the right Zope 3 style events on creation, copy and move.
If we backport the Zope 3 story, we'd need to worry about importing issues. If we backport Zope 3 events, what package will they live in? How will this relate to Five? What other packages does this draw in (zope.interface definitely)? Etc.
Five can make something send Zope 3 events right now by just another ZCML statement, though it drives a monkeypatch underneath..
The two options we have are quite different: The model in Products/Event and Products/EventListenerTool is geared toward local definition of listeners and rules for dispatch (if needed, the tool could easily be divorced from CMF by the way). Zope 3's event model (and the Five backport) is first a global event service, and global subscribers that may look in context-dependent places for specific logic to dispatch events. So we have to chose. Jim added a comment in http://dev.zope.org/Wikis/DevSite/Proposals/IncludeEventsInCore saying (unsurprisingly) that he'd rather use the Zope 3 event system. I'll work in that direction. Martijn asked important question:
If we backport Zope 3 events, what package will they live in? How will this relate to Five? What other packages does this draw in (zope.interface definitely)? Etc.
If we want that to work with Five and Zope 2.7, will there be no way to use the current Zope Interface module ? Will we have to use the Zope 3 one ? Can they be used together in a compatible manner ? If someone has clues... Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Florent Guillaume wrote at 2004-12-10 19:02 +0100:
.... The two options we have are quite different:
The model in Products/Event and Products/EventListenerTool is geared toward local definition of listeners and rules for dispatch (if needed, the tool could easily be divorced from CMF by the way).
Zope 3's event model (and the Five backport) is first a global event service, and global subscribers that may look in context-dependent places for specific logic to dispatch events.
So we have to chose. Jim added a comment in http://dev.zope.org/Wikis/DevSite/Proposals/IncludeEventsInCore saying (unsurprisingly) that he'd rather use the Zope 3 event system.
I fear that we also need to control the order in which subscribers are notified: Consider for example the notification about the creation of a object. Both the catalog service and the workflow service need to be notified. If the catalog service is notified first, the workflow service must renotify the catalog service to get the workflow variables indexed. -- Dieter
Dieter Maurer wrote:
Florent Guillaume wrote at 2004-12-10 19:02 +0100:
.... The two options we have are quite different:
The model in Products/Event and Products/EventListenerTool is geared toward local definition of listeners and rules for dispatch (if needed, the tool could easily be divorced from CMF by the way).
Zope 3's event model (and the Five backport) is first a global event service, and global subscribers that may look in context-dependent places for specific logic to dispatch events.
So we have to chose. Jim added a comment in http://dev.zope.org/Wikis/DevSite/Proposals/IncludeEventsInCore saying (unsurprisingly) that he'd rather use the Zope 3 event system.
I fear that we also need to control the order in which subscribers are notified:
Consider for example the notification about the creation of a object. Both the catalog service and the workflow service need to be notified.
If the catalog service is notified first, the workflow service must renotify the catalog service to get the workflow variables indexed.
Well as you know actually in CMF the catalog tool does not index the object directly, but a wrapper provided by the workflow tool so that its variables are taken into account. So the ordering is taken care of by an explicit knowledge of the other tool in the code. But in theory yes, the problem may exist. I've asked a question about how to do that in the zope3-users list. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Florent Guillaume wrote: [snip]
Martijn asked important question:
If we backport Zope 3 events, what package will they live in? How will this relate to Five? What other packages does this draw in (zope.interface definitely)? Etc.
If we want that to work with Five and Zope 2.7, will there be no way to use the current Zope Interface module ? Will we have to use the Zope 3 one ? Can they be used together in a compatible manner ?
I'd strongly recommend against trying to make the Zope Interface module work directly with Zope 3 technology. I've tried, Zope corp tried, and it's rather painful. Five only managed to get off the ground when it was decided to use Zope 3 interfaces in parallel to Zope 2's, and basically just to ignore Zope 2's. Five does include Tres' bridge directive that can turn a Zope 2 interface into a Zope 3 interface from ZCML. Regards, Martijn
participants (4)
-
Andreas Jung -
Dieter Maurer -
Florent Guillaume -
Martijn Faassen