Garrett Smith wrote:
Jim Fulton wrote:

Uwe Oestermeier wrote:

Alternatively, all mentioned usages could be easily subsumed under
an extended ObjectModifiedEvent definition. Some optional keywords
(for the interface and the attribute that was used to change the
object, and additional infos about the changed values if available)
are probably sufficient:
   1-3: ObjectModifiedEvent(obj, interface=schema, attr=field,
   oldvalue=old, newvalue=new) 4: ObjectModifiedEvent(obj,
   interface=IObjectFile, attr="setBody") 5:
   ObjectModifiedEvent(obj, interface=IContainer,
   attr="__setitem__") 6: ObjectModifiedEvent(obj,
interface=IContainer, attr="__delitem__") 7:
ObjectModifiedEvent(obj, interface=IZopeDublinCore, attr="title")
Since the keywords are optional, these changes could be easily made
in a backward compatible way.

Based on the discussion so far, I'm convinced that something like this
would be useful, at least as an optional feature, as you suggest.

I suggest we generalize this a bit.  I suggest that the ObjectModified
event could accept one or more modification descriptions (hints?).
Some examples:

  ObjectModifiedEvent(obj, IObjectFile)

This says that we modified the objects file data.  Note that
an interface is an acceptable description.  In fact, we
might allow pretty muich anything as a description.

  ObjectModifiedEvent(obj, IObjectFile,
                      Attributes(IZopeDublinCore, 'title',
                      'description'), )

This says we modified the file data and the DC title and description.

This information would be a hint that subscribers could use, or not
use as appropriate.

We could change the form machinery in an obvious way to generate
attribute descriptions.

A couple questions:

- How is a 'better' (loaded term, feel free to interpret) arrangement
than using application-specific event types that clearly define a) when
the event is generated and b) what information the event conveys?

1.  It uses composition to prevent an explosion of event types.

2. I think it better lends itself to automation.  For example, it's
   very easy to see how form machinery could generate these events.

- What new burdens does this place on application developers? Does Zope
core now have to keep track of what "extra" information is conveyed in
various scenarios? What about library vendors?

This is optional.  There are obvious ways the forma machinery could
easily provide this information.  Applications that need finer-level
control (e.g. Dieter's document-management app) may need to
provide more information in events.

I've viewed the current ObjectModifiedEvent as being appropriate for
simple interfaces like the ZMI. In many cases, this simple event model
works perfectly. Different applications are free to layer new event
models on top of that.

Yes, unless there isn't enough information to support the higher

The way to add new event models (at least in my experience) is to create
new event types -- not embed "extra" information in an otherwise clearly
defined data structure.

This is a classic tradeoff between classification and composition.

It seems to me that we're trying to make the ZMI anticipate
application-specific requirements without knowing that those might be.

No, we are providing a simple way that an application can extend a
corner of the event system with some supplimental information.

I'd rather see something like this:

- If a utility (or some other pluggable component) uses specific
information from an event, it should provide an event interface that
describes what it needs.

- An application that's aware of that component type can fire an event
that provides that interface.

The same can go for looking for the extra information.

:-) I guess this approach is *so* endemic to Zope 3, I must be missing
something huge.

What we're talking about is not very different from the way that
composition is used to prevent explosition of field types.

For example, we use: List(Int()) rather than IntegerList.

Note that we use a combination of type and composition,
hopefully striking a good balence.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to