[Zope3-dev] event service.

[Gary Poster]

My take on this is that the event_type limits the events that will be
processed by the filter: therefore, the filter *can* rely on receiving an
event implementing the given event_type.  If you're building a filter for an
IObjectAddedEvent event_type, you can rely on the functions offered by the
IObjectAddedEvent (getURL or whatever it is) being there.

Gary

-----Original Message-----
From: zope3-dev-admin@zope.org [mailto:zope3-dev-admin@zope.org]On
Behalf Of Chris McDonough

I've backported the Zope 3 event service to Zope 2, and I've got an
architecture question for those who might be willing to ponder it..

The IEvent interface specifies a that Event objects must have a __call__
method, but specifies no other features.

Objects that implement the ISubscribable interface accept three arguments to
their "subscribe" method: subscriber, event_type, and filter.

The Event Service implementation (which implements the ISubscribable
interface)  runs the event through the filter method for each subscriber
subscribed to a received event type.

However, there is no interface-specified metadata on objects which implement
IEvent that would allow the filter method to switch on an attribute or
method call value.  Currently, when the filter method is called with an
object that implements IEvent, it really can't reliably do much with the
object except call it.

I'm wondering if there should be another interface type, perhaps
IFilterableEvent that specifies another method, 'getFilterData', the return
value of which the filter could examine to see if it's interesting to a
particular subscriber.

- C




_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
http://lists.zope.org/mailman/listinfo/zope3-dev