[Zope3-dev] Missing ObjectContentModifiedEvent

[Jim Fulton]

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

> 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

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org