[Zope-PTK] [Fwd: Re: [Zope-PTK] New tool proposal: portal_events]

[Tres Seaver]

*My apologies -- I neglected to CC the PTK list on this reply.*

Andrew Wilcox wrote:
> 
> >  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.
> 
> Do consider having an "Event" class with a single "event" object passed to
> notify().  Using an object-oriented approach would include these advantages:
> 
> * Event data would be encapsulated in the Event object, so it would be easy
> to add new data elements in the future without breaking existing code.

Of course an inheritance-based solution is actually slighly *more*
inflexible than one which leverages Python's dynamism.  My proposal
is actually motivated by the CORBA NotificationService, which has
a very similar signature, passing "filterable" meta-data separately
from the payload.  Their service was developed after extensive
experience with strongly-typed event hierarchies, and makes some
good tradeoffs, it seems to me.

> * It is easy to classify and filter on event types, simply by having
> subclasses of Event such as: ObjectAddedEvent, a subclass of
> ObjectManagerEvent, a subclass of Event.

Filtering based on inheritance classifications has two drawbacks:

  * Either you *don't* know all the event types ahead of time, in
    which case you must do *really slow* testing for each base
    class you *do* know about;  you can then use only the services
    provided by those bases.  Note that subscribers have a "moral
    obligation" to take as little time as possible during the
    notification;  their processing is (at least in a naive
    implementation) blocks the completion of the transaction.

  * Or, you *do* know all the event types, in which case you are
    going to dispatch on the type directly;  this is exactly the
    case for the signature I proposed, except that the subscriber
    has to do more work.

> * If you are filtering on **kw, you may not know if a keyword of a
> particular name is being used in the same way by different events.

The 'eventType' parameter (which may, indeed, be a class object)
will dictate what keywords, if any, are passed with a given event.

> Instead, create an interface that defines the meaning of common meta-data.
> Put the common meta-data elements into a mixin class that can then be
> subclassed by any Event class that provides those meta-data elements.  Now
> it is easy to tell if you're getting the meta-data you want to filter on,
> and you don't have to worry about the event type.  (Er, was that very
> clear?  Perhaps an example?)
> 
> * You will find in your client code that there are operations that you do
> over and over again in reference to the event.  With an Event class, you
> can easily refactor your code to make the common operations methods of the
> class, simplifying your client code.

This may be so, for a specific portal;  one of the problems of the PTK
is to provide extensible mechanisms for implementing such behavior, without
imposing policies rigid enough to defeat the extensibility.  Given the
API I originally specified, for instance, it would be simple to deploy
a portal which passed the kind of Event objects you describe as the payload
paramter, passing their class object as the eventType;  all "custom" code
in the portal would use the payload object directly, while the "framework"
code would continue to dispatch on eventType.

Thanks for the feedback!

Tres.
-- 
=========================================================
Tres Seaver                          tseaver@digicool.com
Digital Creations   "Zope Dealers"   http://www.zope.org