[Zope3-dev] Missing ObjectContentModifiedEvent

Jim Fulton jim at zope.com
Thu May 26 13:35:30 EDT 2005


Uwe Oestermeier wrote:
> Garrett Smith wrote:
> 
>  > So we shouldn't see ObjectModifiedEvent being fired directly then. It
>  > should be one of the two subclasses, correct? This is not the case
>  > throughout zope/app.
> 
> Jim Fulton answered:
>  > Yup. Yup.
> 
> A closer look at the ObjectModifiedEvents (or the related modified() calls)
> revealed that there are only a few places were these events are actually 
> fired.
> Most usages occur inside tests.
> 
> ObjectModifiedEvents are fired in
> 
> 1. app.form.browser.add (in a _set_after_add hook together with a list 
> of fields)
> 2. app.form.browser.editview (after a call of applyWidgetsChanges)
> 3. app.form.browser.editwizard (after a call of applyWidgetsChanges)
> 4. app.fssync.committer (after a call of adapter.setBody)
> 5. zope.app.workflow.stateful.definition (in _publishModified, seems to be
>     related to container events)
> 6. zope.app.container.contained (in setitem and uncontained)
> 
> An ObjectAnnotationsModifiedEvent is used in
> 
> 7. zope.app.dublincore.browser.metadataedit (for dc.title and 
> dc.description)
> 
> ObjectContentModifiedEvents are currently not used, as already mentioned.
> 
> According to the intrinsic/extrinsic distinction
> 
> 1-4 are clear cases for ContentModifiedEvents (or ValueChangedEvents),
> 5 & 6 indicate modified containers, which are presumably 
> ContentModifiedEvent
> according to the intrinsic/extrinsic distinction.
> 7 is the only clear case for an extrinsic usage.
> 
> Therefore one should use  ObjectContentModifiedEvent for 1-6, and
> an ObjectAnnotationsModifiedEvent for 7. As far as I see, 4. becomes 
> redundant,
> if File._setData fires the event. But the general question is,  whether 
> the adapter
> or the adapted interface should send the event.
> 
> 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.

What would be the use of this?

It's a little bit unclear what we hope to get from all of this.

I'll ask about goals and use cases in a separate thread.

Jim


-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


More information about the Zope3-dev mailing list