[Zope3-dev] Missing ObjectContentModifiedEvent

[Garrett Smith]

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?

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

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.

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.

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

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.

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

 -- Garrett