Florent Guillaume wrote:
> Jim Fulton <[EMAIL PROTECTED]> wrote:
>> Based on the discussion so far, I'm convinced that something like
>> this would be useful, at least as an optional feature, as you
>> I suggest we generalize this a bit. I suggest that the
>> ObjectModified event could accept one or more modification
>> descriptions (hints?). Some examples:
>> 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',
>> 'description'), )
>> This says we modified the file data and the DC title and description.
> That looks good to me. Especially because, using interfaces, we could
> theoretically express more than just a set of attributes that have
> changed on an object. I'm thinking of:
> - having the interface itself add semantics to what a subscriber could
> want to do about the change (i.e., it could recognize
> IZopeDublinCore and decide to delay its work),
> - having the interface express more complex object structure than
> just a set of attributes (I'm thinking about XML Schema-derived /
> XForms interfaces, where you can represent deep structures).
> That's all science-fiction of course.
This is my concern :-)
I'm seeing a lot of hypothesizing and we should instead be driven by
hard requirements/use cases.
IIR, the one definite requirement is to provide support for object
versioning. But, as Jim's pointed out, this is probably better handled
at a lowed level, since there's no guarantee *any* event model will be
Zope3-dev mailing list