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

 -- Garrett
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to