"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 _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
