Ooops! I just saw that my previous posting on the other thread has become
obsolete to a large degree.
[EMAIL PROTECTED] wrote:
>I suggest we generalize this a bit. I suggest that the ObjectModified
>event could accept one or more modification descriptions (hints?).
> 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',
>This says we modified the file data and the DC title and description.
>Uwe, I still think you need something else for your versioning work.
I'm not sure. Previously, I thought that it would be useful to have the
old and new values of an attribute change in addition. Such infos allow to
create the first version of an attribute value after the first change,
which means that one creates versions only for the (usually few) parts of
an object that really change. Since each versioned value has some overhead
(e.g. modification time, user etc.) this makes a difference
The proposed approach makes the descriptions optional, and I agree that a
framework should not be overloaded by application specific optimizations.
Therefore, I probably will continue using complete replicas of the
original objects since I cannot rely on the fact that all programmers
specify all changes in such detail. Otherwise it would be possible to
extend the modification descriptions a little bit and provide
ValueChanged(IZopeDublinCore, 'title', u'Old title', u'New title')
descriptions at least for the few cases in the framework where
modification events are produced. Whether other programmers find these
descriptions also usefull can then be left to the future.
What remains is the problem that change detection should be fool proof. It
would be nice to have a debugging tool that prints a warning if a modified
object is written back to the database without a corresponding event.
Zope3-dev mailing list