[Zope-PTK] New tool proposal: portal_events

[Tres Seaver]

On Tue, 5 Sep 2000, Andrew Wilcox wrote:

> >> (Er, was that very
> >> clear?  Perhaps an example?)
> >
> >yes please :-S
> 
> Let's brainstorm a bunch of events we might have in a portal.  Then when we
> investigate a proposed framework such as DOM Level 2, Java 1.1, etc., we
> can look at from the perspective of our examples.  We might say, oh, that
> framework is overkill; or, wow, just the ticket; or, very nice but it's
> missing something *we* need.
> 
> What kind of events might we have?
> 
> What are the properties, attributes, meta-data associated with each event?
> 
> Please make suggestions on my meager beginnings:
> 
> 
> Content is added
>     date content was added
>     type of content
>     dublin core meta-data
>     what else?

   In my scenario, the object being added would be the
   'payload' of the event, while the container's physical path
   and the object's meta_type would be two of the likely
   "filtering" values (remember that the DublinCore metadata
   is "massaged" to make it useful for "discovery" by other
   systems;  it is not always in the most useful form  for
   internal consumption).

> Content is ready for review
>     date of event
>     what else?

   This one is a particular case of your "workflow state change"
   below.  
> 
> Content is deleted
>     date of deletion
>     what else?

   Again, the container path, and in this case the id of
   the deleted object, plus it erstwhile meta_type.  We
   could probably make the removed object payload again,
   as that would guarantee that it remained "alive" during
   the event processing, even if (as is most likely) its
   container held the only "normal" reference to it.

> 
> A user joins the portal
>     date of joining
>     information about the user: name, email, etc.
>     what else?

   Just pass the user object as payload;  I can't think of
   any filtering metadata that would be generally useful
   here (specific portal implementations could always pass
   additional data, if need be).  Perhaps the roles assigned
   would be helpful, in case we need to take different action
   when a "privileged" user joins (I doubt any real portal would
   work like this, however;  most would to the "promotion"
   separately, as you call out next).

> 
> A user is promoted to a new role, such as "reviewer"
>     date of promotion
>     information about the user
>     what else?

   Hmm, the userid and the old/new roles lists.

> A policy of the portal changes
>     what kind of policies do we have?

  I can't think of a use case for this one, actually.

> A workflow status changes
>     date of status change

   Containment path to the object, former state(s),
   new state(s), triggering event name.

> 
> A new comment is added to the discussions of an object
>     date of addition
>     dublin meta-data
>     what else?

   Containment path of the "Discussable" thing, ID
   of the new comment.

> Also, what kinds of meta-data will we typically want to filter on,
> independent of the primary type of the event?

I wouldn't generally include the timestamp on the event on the
"base" framework events, but would instead push that off to be
generated by a "logging subscriber", if any.  A similar adapter
could likewise package up the payload and metadata into the kind
of event-type hierarchy you proposed earlier.

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