[Zope-PTK] New tool proposal: portal_events
Dieter Maurer
dieter@handshake.de
Tue, 22 Aug 2000 23:22:08 +0200 (CEST)
Tres Seaver writes:
> I am proposing to add a new tool, 'portal_events', to the
> set of top-level tools provided by each portal. This tool
> would be a CORBA-style event channel, supporting the following
> interfaces::
>
> class PortalEventSource:
> def register( observer ):
> """ Register an event sink for future notification.
>
> 'observer' -- must be a traversable path to an
> object conforming to the PortalEventSink interface.
> """
>
> def unregister( observer ):
> """ Unegister an event sink to prevent future notification.
>
> 'observer' -- must be a traversable path to an
> object conforming to the PortalEventSink interface.
> """
>
> class PortalEventSink:
> def notify( eventType, payload=None, **kw ):
> """ Process an event from an event source.
>
> 'eventType' -- meant to be easily tested for filtering;
> may be a well-known constant, a class object, etc.
>
> 'payload' -- event data (or a lazy proxy therefore).
>
> 'kw' -- meta-data about the event, especially useful
> for filtering.
>
> Implementations of this interface contract to handle
> these notifications "quickly", without blocking.
> """
>
> Here are the events I foresee flowing through 'portal_events':
>
> * ObjectManagers within the portal will notify the tool when
> objects are added or removed (the portal_catalog will subscribe
> to get these).
>
> * PortalContent will notify the tool when saving changes (the
> portal_catalog can subscribe to this one, too).
>
> * The portal_registration tool will notify of newly-added members.
>
> Comments, please.
I like the idea.
However, I see three actors in the standard use case:
the event source, such a "ObjectManager", "PortalContent", "PortalRegistration"
the EventChannel (EventSource in your interface)
the observer (EventSink in your interface)
The "EventChannel" would provide "register" and "unregister"
for "observers" and "notify" for event sources.
Dieter