[Zope-PTK] portal_events

[Tres Seaver]

Shane Hathaway wrote:
> 
> Michael,
> 
> portal_events would consist of only a small piece of
> code, would not require any change to existing
> architecture, and would not introduce a dependency on
> ZPatterns.  It would be an implementation of a common
> design pattern.  So no, it's not a duplication of
> ZPatterns agents.
> 
> However, your message and Andrew Wilcox's reminded me
> of the change to the event model in the transition
> from JDK 1.0 to JDK 1.1.  In 1.0 you had to subclass
> to receive events.  In 1.1 you have to subscribe to
> receive very specific events.
> 
> portal_events, as proposed, would let you subscribe to
> *all* portal events.  Maybe instead of that approach
> we need to add event subscription capability to
> specific tools, such as:
> 
>   portal_workflow.addStatusChangeListener()
> 
> and:
> 
>   portal_workflow.removeStatusChangeListener()

I would *far* rather add one or more filter objects, perhaps
of the same class as 'portal_events', but whose job in life
was to "condition" the set of events which they propagated
to *their* subscribers::

         portal_events :
       PortalEventChannel
            ^
            |
      <<subscribed>>
            |
  workflow_events : +---- passes only "WorkflowEvent" events
 PortalEventChannel       on to its subscribers.

Part of the point of my proposal was to remove the burden
of tracking subscriptions from all possible event sources,
and to allow for customization of event flows via
configuration, rather than coding.

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