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