[Zope3-dev] Missing ObjectContentModifiedEvent

[Uwe Oestermeier]

"Garrett Smith" wrote:
>
>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?

Application specific events can still be 'better', but if the framework is
flexible enough to capture typical use cases like versioning and indexing
in an efficient way this is 'better' than the current state. 
>
>
>- 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?

As far as I can see, the extra burden is relatively small. The additional
explictness makes debugging and testing probably easier. Zope core should
not keep track about scenario specific modification descriptions, but new
ones should be defineable.
>
>
>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.

As far as I can see, this is still possible and works probably fine within
one application. But if we want to combine different apps (e.g. a
groupware with a versioning system with a special text index), changes are
high that application specific events will not work together in the long
run, because each application developer has  to keep track of new event
types, changes in the interface, etc. of other applications.
For a framework, I prefer more complex but reusable events over simple but
application specific events.  In my application I was quite satisfied with
Zope3's container events from the beginning, and I'm quite sure that this
is due to their higher informativity. All in all, the current proposal
combines simplicity (AnnotationModifiedEvent and ContentModifiedEvent are
obsolete) with optional modification descriptions. It is at the same time
easy to integrate in the current framework and still open to application
specific events.
>
Uwe