Uwe Oestermeier wrote: ...very good analysis of current modified event usage...
> 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. I certainly like the idea of getting rid of ObjectContentModifiedEvent and ObjectAnnotationsModifiedEvent -- they're both WHUI (we haven't use it) as you've shown. I'd be concerned about making ObjectModifiedEvent too burdensome for developers. For most, cases, it's sufficient to just say "this object has changed" and be done with it. As for your goals of maintaining versioning for any possible third part product added to Zope, I think you'll need another strategy -- there's no guarentee that you'll get all the change info you need. Someone may choose, for example, not to use the default forms machinery (assuming that's even changed to support the proposed scheme). I do think a 'property changed' scheme -- one that let subscribers veto changes -- would be an excellent addition to the object change lifecycle. -- Garrett _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
