[Zope-PTK] New tool proposal: portal_events

Andrew Wilcox circle@gwi.net
Mon, 21 Aug 2000 20:13:37 -0400


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

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

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

Andrew

(Who just finished Martin Fowler's Analysis Patterns book :-)