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
>> suggest. 
>> 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

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

Reply via email to