Uwe Oestermeier wrote:
Alternatively, all mentioned usages could be easily subsumed under an
ObjectModifiedEvent definition. Some optional keywords (for the
the attribute that was used to change the object, and additional infos
the changed values if available) are probably sufficient:
1-3: ObjectModifiedEvent(obj, interface=schema, attr=field,
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?).
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.
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
We could change the form machinery in an obvious way to generate
Dieter, I'm pretty sure that this would provide enough information
for you to do the kind of optimizations you want to do.
Uwe, I still think you need something else for your versioning work.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list