Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Uwe Oestermeier wrote: [EMAIL PROTECTED] wrote: What is the missing event bug? Currently no modification event is fired if one uploads new file content via ZMI. In a former mail I proposed to fire the event in File.setData, alternatively it can be fired by the upload view. Would this be for 3.2? Keep in mind that we want to generate a beta release this weekend. I can do it tomorrow since there are only a few places where modification events are actually used. If that seems to risky I will wait for 3.2. Sounds good. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
[EMAIL PROTECTED] wrote: >What is the missing event bug? Currently no modification event is fired if one uploads new file content via ZMI. In a former mail I proposed to fire the event in File.setData, alternatively it can be fired by the upload view. > > >Would this be for 3.2? Keep in mind that we want to generate a beta >release this weekend. I can do it tomorrow since there are only a few places where modification events are actually used. If that seems to risky I will wait for 3.2. Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Uwe Oestermeier wrote: I would like to fix the missing event bug, What is the missing event bug? implement Jim's proposal and mark ObjectContentModifiedEvent and ObjectAnnotationModifiedEvent as deprecated. Any objections? Would this be for 3.2? Keep in mind that we want to generate a beta release this weekend. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
I would like to fix the missing event bug, implement Jim's proposal and mark ObjectContentModifiedEvent and ObjectAnnotationModifiedEvent as deprecated. Any objections? Uwe [EMAIL PROTECTED] wrote: > >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. > >This information would be a hint that subscribers could use, or not use >as appropriate. > >We could change the form machinery in an obvious way to generate >attribute descriptions. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: What is modification, and why do we care? (was Re: [Zope3-dev] Missing ObjectContentModifiedEvent)
On 5/26/05, Jim Fulton <[EMAIL PROTECTED]> wrote: > Given the applications above, I don't think that there's value in > fine-grained modification events that justifies the complecity of > proposals we've thought of so far. > > > Thoughts? I doubt the event system needs to be much more fine-grained. If you want an event to tell you when a particular property value has changed, it's easy enough to use a custom field that wraps set() and spawns a custom change event, e.g: # untested... class SearchableTextLineModified(ObjectEvent): def __init__(self, object, changed_field): ObjectEvent.__init__(self, object) self.changed_field = changed_field class SearchableTextLine(TextLine): def set(self, object, value): TextLine.set(self, object, value) notify(SearchableTextLineModified(object, self.__name__)) If you use this field type for all text properties you want searched, your text index can simply ignore all change events beside the one(s) you care about and *then* only act on the specific fields changed. Other tools that depend on built-in change events should still work. This approach has the advantage of providing events that are as fine-grained as the developer wishes them to be and pushes resposibility for managing any resulting complexity sqarely on the developer's shoulders. I doubt that making Zope's built-in events more complicated is the way to go. FWIW, $.02, etc, Dylan > > Are there other applications for modification events that > I haven't considered? > > Jim > > -- > Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! > CTO (540) 361-1714http://www.python.org > Zope Corporation http://www.zope.com http://www.zope.org > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dylanreinhardt%40gmail.com > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
[EMAIL PROTECTED] wrote: >> Because there is no guarantee that all relevant modifications are >> accompanied by events? > >Right But this problem is not unique to versioning. If you cannot rely on events there is also no guarantee that your catalogs are always up to date. Therefore I'm planning a debug tool that uses a beforeCommitHook to check whether all modifications I'm interested in are accompanied by events. This indeed is another way to say that I'm doing versioning better at the transactional level. My point is, that this debug mode is relatively expensive and I hope that I can switch it off as soon as all components fire the events as required. Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Garrett Smith wrote: Jim Fulton wrote: Garrett Smith wrote: :-) I guess this approach is *so* endemic to Zope 3, I must be missing something huge. What we're talking about is not very different from the way that composition is used to prevent explosition of field types. For example, we use: List(Int()) rather than IntegerList. Note that we use a combination of type and composition, hopefully striking a good balence. I see your point. But events are essentially an API and a well defined contract is better than an implicit one. I think we're going to see a lot code that looks like this: if not 'my stuff' in event.extra: return doSomething() I don't think so. I also think this is being driven by the "I can imagine..." syndrome. I don't think that was the case with Deiter's use case. In Zope 2, there was no event system. The closest thing to one was the old catalog framework. This framework allowed catalog updates to specify which indexes were affected. This feature was widely used. I don't think what we're talking about is imaginary. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
Garrett Smith wrote: > Jim Fulton wrote: >> Garrett Smith wrote: >>> :-) I guess this approach is *so* endemic to Zope 3, I must be >>> missing something huge. >> >> What we're talking about is not very different from the way that >> composition is used to prevent explosition of field types. >> >> For example, we use: List(Int()) rather than IntegerList. >> >> Note that we use a combination of type and composition, >> hopefully striking a good balence. > > I see your point. > > But events are essentially an API and a well defined contract is > better than an implicit one. I think we're going to see a lot code > that looks like this: > > if not 'my stuff' in event.extra: > return > doSomething() I take this back -- we can always provide a multi-adapter delegator. That's actually pretty nice. > I also think this is being driven by the "I can imagine..." syndrome. I'm still concerned about WHUI. What in the core can be replaced with this new model? -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
Jim Fulton wrote: > Garrett Smith wrote: >> :-) I guess this approach is *so* endemic to Zope 3, I must be >> missing something huge. > > What we're talking about is not very different from the way that > composition is used to prevent explosition of field types. > > For example, we use: List(Int()) rather than IntegerList. > > Note that we use a combination of type and composition, > hopefully striking a good balence. I see your point. But events are essentially an API and a well defined contract is better than an implicit one. I think we're going to see a lot code that looks like this: if not 'my stuff' in event.extra: return doSomething() OTOH, if we're talking about different event types, only the applicable handlers gets called. I also think this is being driven by the "I can imagine..." syndrome. Anyway, I'm done spouting :-) -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Uwe Oestermeier wrote: [EMAIL PROTECTED] wrote: I'm 99% sure that this event model will not be sufficient for object versioning. Why? Because there is no guarantee that all relevant modifications are accompanied by events? Right I think these problems can be solved, but perhaps you have other reasons in mind. I don't agree. As I've said before, I think you need a much lower level and more automatic process. It's up to you to do what you think best. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
[EMAIL PROTECTED] wrote: >I'm 99% sure that this event model will not be sufficient for object >versioning. Why? Because there is no guarantee that all relevant modifications are accompanied by events? Because the events do not carry enough information? I think these problems can be solved, but perhaps you have other reasons in mind. Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Garrett Smith wrote: ... I'm seeing a lot of hypothesizing and we should instead be driven by hard requirements/use cases. I think Dieter's use case was a pretty good one. It convinced me. I think getting modification time "right" is another one. 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 sufficient. I'm 99% sure that this event model will not be sufficient for object versioning. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Garrett Smith wrote: Jim Fulton wrote: Uwe Oestermeier wrote: ... 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. 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. This information would be a hint that subscribers could use, or not use as appropriate. We could change the form machinery in an obvious way to generate attribute descriptions. A couple questions: - How is a 'better' (loaded term, feel free to interpret) arrangement than using application-specific event types that clearly define a) when the event is generated and b) what information the event conveys? 1. It uses composition to prevent an explosion of event types. 2. I think it better lends itself to automation. For example, it's very easy to see how form machinery could generate these events. - What new burdens does this place on application developers? Does Zope core now have to keep track of what "extra" information is conveyed in various scenarios? What about library vendors? This is optional. There are obvious ways the forma machinery could easily provide this information. Applications that need finer-level control (e.g. Dieter's document-management app) may need to provide more information in events. I've viewed the current ObjectModifiedEvent as being appropriate for simple interfaces like the ZMI. In many cases, this simple event model works perfectly. Different applications are free to layer new event models on top of that. Yes, unless there isn't enough information to support the higher layers. The way to add new event models (at least in my experience) is to create new event types -- not embed "extra" information in an otherwise clearly defined data structure. This is a classic tradeoff between classification and composition. It seems to me that we're trying to make the ZMI anticipate application-specific requirements without knowing that those might be. No, we are providing a simple way that an application can extend a corner of the event system with some supplimental information. I'd rather see something like this: - If a utility (or some other pluggable component) uses specific information from an event, it should provide an event interface that describes what it needs. - An application that's aware of that component type can fire an event that provides that interface. The same can go for looking for the extra information. :-) I guess this approach is *so* endemic to Zope 3, I must be missing something huge. What we're talking about is not very different from the way that composition is used to prevent explosition of field types. For example, we use: List(Int()) rather than IntegerList. Note that we use a combination of type and composition, hopefully striking a good balence. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Florent Guillaume wrote: Jim Fulton <[EMAIL PROTECTED]> wrote: ... 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. Martijn and Philipp prototypd the later a couple of years ago. The idea was to generate an interface from am xml schema and then look up components based on an xml schemas. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
Florent Guillaume wrote: > On 31 May 2005, at 12:39, Garrett Smith wrote: >>> 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. > > Ah no, I'm saying that in addition to fulfulling existing scenarios I > have, it also fulfills some fantasy ones :) > >> 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 sufficient. > > That's if you want things to be totally transparent, yes. Which is a > valid concern, but I'm not sure it's the most expressive choice for a > system. I wouldn't mind requiring have a small bit of cooperation > from objects if they want to be versioned properly. I see your point. But I think you're asking a lot from the system. It's going to be very hard to accomplish what you want even with this proposed eventing scheme. I'd hate to see this increased complexity without any assurance that it will even meet the one hard requirement driving it. Have you explored looking at versions at the persistence level? I would think the Zope 2 community would have a ton of experience that would be valuable here. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
On 31 May 2005, at 12:39, Garrett Smith wrote: 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. Ah no, I'm saying that in addition to fulfulling existing scenarios I have, it also fulfills some fantasy ones :) 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 sufficient. That's if you want things to be totally transparent, yes. Which is a valid concern, but I'm not sure it's the most expressive choice for a system. I wouldn't mind requiring have a small bit of cooperation from objects if they want to be versioned properly. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
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 sufficient. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
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. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Jim Fulton wrote at 2005-5-30 08:42 -0400: > ... >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. > >This information would be a hint that subscribers could use, or not use >as appropriate. > >We could change the form machinery in an obvious way to generate >attribute descriptions. > >Dieter, I'm pretty sure that this would provide enough information >for you to do the kind of optimizations you want to do. Sounds good! -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
"Garrett Smith" wrote: > >A couple questions: > >- How is a 'better' (loaded term, feel free to interpret) arrangement >than using application-specific event types that clearly define a) when >the event is generated and b) what information the event conveys? Application specific events can still be 'better', but if the framework is flexible enough to capture typical use cases like versioning and indexing in an efficient way this is 'better' than the current state. > > >- What new burdens does this place on application developers? Does Zope >core now have to keep track of what "extra" information is conveyed in >various scenarios? What about library vendors? As far as I can see, the extra burden is relatively small. The additional explictness makes debugging and testing probably easier. Zope core should not keep track about scenario specific modification descriptions, but new ones should be defineable. > > >I've viewed the current ObjectModifiedEvent as being appropriate for >simple interfaces like the ZMI. In many cases, this simple event model >works perfectly. Different applications are free to layer new event >models on top of that. >The way to add new event models (at least in my experience) is to create >new event types -- not embed "extra" information in an otherwise clearly >defined data structure. > >It seems to me that we're trying to make the ZMI anticipate >application-specific requirements without knowing that those might be. > >I'd rather see something like this: > >- If a utility (or some other pluggable component) uses specific >information from an event, it should provide an event interface that >describes what it needs. > >- An application that's aware of that component type can fire an event >that provides that interface. As far as I can see, this is still possible and works probably fine within one application. But if we want to combine different apps (e.g. a groupware with a versioning system with a special text index), changes are high that application specific events will not work together in the long run, because each application developer has to keep track of new event types, changes in the interface, etc. of other applications. For a framework, I prefer more complex but reusable events over simple but application specific events. In my application I was quite satisfied with Zope3's container events from the beginning, and I'm quite sure that this is due to their higher informativity. All in all, the current proposal combines simplicity (AnnotationModifiedEvent and ContentModifiedEvent are obsolete) with optional modification descriptions. It is at the same time easy to integrate in the current framework and still open to application specific events. > Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
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?). >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. 1+ > >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. > Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
Jim Fulton wrote: > Uwe Oestermeier wrote: > ... >> 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. > > 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. > > This information would be a hint that subscribers could use, or not > use as appropriate. > > We could change the form machinery in an obvious way to generate > attribute descriptions. A couple questions: - How is a 'better' (loaded term, feel free to interpret) arrangement than using application-specific event types that clearly define a) when the event is generated and b) what information the event conveys? - What new burdens does this place on application developers? Does Zope core now have to keep track of what "extra" information is conveyed in various scenarios? What about library vendors? I've viewed the current ObjectModifiedEvent as being appropriate for simple interfaces like the ZMI. In many cases, this simple event model works perfectly. Different applications are free to layer new event models on top of that. The way to add new event models (at least in my experience) is to create new event types -- not embed "extra" information in an otherwise clearly defined data structure. It seems to me that we're trying to make the ZMI anticipate application-specific requirements without knowing that those might be. I'd rather see something like this: - If a utility (or some other pluggable component) uses specific information from an event, it should provide an event interface that describes what it needs. - An application that's aware of that component type can fire an event that provides that interface. :-) I guess this approach is *so* endemic to Zope 3, I must be missing something huge. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Uwe Oestermeier wrote: ... 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. 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. This information would be a hint that subscribers could use, or not use as appropriate. We could change the form machinery in an obvious way to generate attribute descriptions. 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 -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: What is modification, and why do we care? (was Re: [Zope3-dev] Missing ObjectContentModifiedEvent)
Jim Fulton wrote at 2005-5-27 10:45 -0400: > ... >> You cannot make text extraction cheap (as it handles potentially large >> data). > >You can't make it cheap in all applications. For most applications, >text extraction and comparison is very cheap. > >I'm guessing that you are refering to indexing large (book size) >documents. I would argue that this is pretty specialized. No, I am speaking about a repository with office documents (letters, reports, drafts, documentation, ...) which apparently is not too rare at least in a Plone like context. >And it is usually not the case that text extraction is expensive. I analysed last year text extraction from office documents. WVware extraction for documents in the order of 1 MB size took time in the order of seconds; OpenOffice text extraction in the order of 10 seconds (after optimization; standard - twice as much). Definitely, I do not like this time for any change in a metadatum or a workflow change. While a user accepts some seconds delays when he uploads large documents, he feels it unacceptable to wait for seconds when he performs e.g. a workflow action on such a document. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: What is modification, and why do we care? (was Re: [Zope3-dev] Missing ObjectContentModifiedEvent)
Dieter Maurer wrote: Jim Fulton wrote at 2005-5-27 08:29 -0400: ... Then, we probably do something wrong... That's always a possibility. I think what we are doing is pretty reasonable. Perhaps you have other suggestions. I think we need more control over what modifications trigger what reindexing events. I am not yet sure about the best (or even a good) approach. ... Even computing the value for a text index (without any change to the index itself) can be very expensive: it may include expensive fetching of a large object, an expensive conversion (text extraction), expensive splitting and comparison to what is currently indexes. Perhaps. It depends a lot on the application. I suggest that, if this optimization is important, it might be much easier and cleaner to make text extracttion and comparison cheap, rather than, trying to solve the problem with a more complex event model. You cannot make text extraction cheap (as it handles potentially large data). You can't make it cheap in all applications. For most applications, text extraction and comparison is very cheap. I'm guessing that you are refering to indexing large (book size) documents. I would argue that this is pretty specialized. You could make comparison cheap -- e.g. by storing last modification dates and comparing them. But, I fear, you would just move the problem to when changing the modification date. I think this is a nice solution for those special cases where text extraction is expensive. The nice thing about this solution is that it involves a contract between the content and the index without complicating the event framework. ... I think it would be very difficult to come up with rules for deciding which events might effect a text value and which would not. For example, I can easily imagine objects who's searchable text depends on their workflow state. Indeed, such objects are easily imaginable. But usually, it is not the case. And it is usually not the case that text extraction is expensive. The problem is obviously difficult -- not solvable with a trivial event model and trivial reindexing dispatching. Agreed. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: What is modification, and why do we care? (was Re: [Zope3-dev] Missing ObjectContentModifiedEvent)
Jim Fulton wrote at 2005-5-27 08:29 -0400: > ... >> Then, we probably do something wrong... > >That's always a possibility. I think what we are doing is >pretty reasonable. Perhaps you have other suggestions. I think we need more control over what modifications trigger what reindexing events. I am not yet sure about the best (or even a good) approach. >>>... >> Even computing the value for a text index (without any change >> to the index itself) can be very expensive: it may >> include expensive fetching of a large object, >> an expensive conversion (text extraction), expensive splitting >> and comparison to what is currently indexes. > >Perhaps. It depends a lot on the application. > >I suggest that, if this optimization is important, it might >be much easier and cleaner to make text extracttion and comparison >cheap, rather than, trying to solve the problem with a more complex >event model. You cannot make text extraction cheap (as it handles potentially large data). You could make comparison cheap -- e.g. by storing last modification dates and comparing them. But, I fear, you would just move the problem to when changing the modification date. > ... >I think it would be very difficult to come up with rules >for deciding which events might effect a text value and which would not. >For example, I can easily imagine objects who's searchable text >depends on their workflow state. Indeed, such objects are easily imaginable. But usually, it is not the case. The problem is obviously difficult -- not solvable with a trivial event model and trivial reindexing dispatching. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: What is modification, and why do we care? (was Re: [Zope3-dev] Missing ObjectContentModifiedEvent)
Dieter Maurer wrote: Jim Fulton wrote at 2005-5-26 14:43 -0400: ... Probably the indexes that we *most* want to avoid reindexing are text indexes. We have a ISearchableText interface that we commonly adapt objects to to get the text to index. We really can't predict how this text is computed. Then, we probably do something wrong... That's always a possibility. I think what we are doing is pretty reasonable. Perhaps you have other suggestions. ... A safer strategy seems to me to be to have the indexes themselves responsible for detecting changes that they care about. I'm pretty sure that some of the Zope 2 indexes are careful to avoid reindexing, or at least avoid updating indexes if indexed values haven't changed. Even computing the value for a text index (without any change to the index itself) can be very expensive: it may include expensive fetching of a large object, an expensive conversion (text extraction), expensive splitting and comparison to what is currently indexes. Perhaps. It depends a lot on the application. I suggest that, if this optimization is important, it might be much easier and cleaner to make text extracttion and comparison cheap, rather than, trying to solve the problem with a more complex event model. I would not like this overhead for e.g. workflow state changes by default. I think it would be very difficult to come up with rules for deciding which events might effect a text value and which would not. For example, I can easily imagine objects who's searchable text depends on their workflow state. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: What is modification, and why do we care? (was Re: [Zope3-dev] Missing ObjectContentModifiedEvent)
Jim Fulton wrote at 2005-5-26 14:43 -0400: > ... > Probably the indexes that we *most* want to avoid reindexing are > text indexes. We have a ISearchableText interface that we > commonly adapt objects to to get the text to index. We really > can't predict how this text is computed. Then, we probably do something wrong... > ... > A safer strategy seems to me to be to have the indexes themselves > responsible for detecting changes that they care about. I'm > pretty sure that some of the Zope 2 indexes are careful to avoid > reindexing, or at least avoid updating indexes if indexed values > haven't changed. Even computing the value for a text index (without any change to the index itself) can be very expensive: it may include expensive fetching of a large object, an expensive conversion (text extraction), expensive splitting and comparison to what is currently indexes. I would not like this overhead for e.g. workflow state changes by default. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
What is modification, and why do we care? (was Re: [Zope3-dev] Missing ObjectContentModifiedEvent)
A week or so ago, there was a thread on the distinction between IObjectModifiedEvent, IObjectAnnotationsModifiedEvent, and IObjectContentModifiedEvent. I'd like to step back a little bit and brainstorm some use cases that, hopefully, illustrate why we care about this. Here's a start: - A persistence or versioning system wants to know when objects have changed so that they can save new versions of the object. This needs to be pretty much fool proof. To do this, I think you really need to do something like what the ZODB persistence mechanism does. Perhaps for versions, once could hook into this mechanism somehow. - Record, as meta data, the time that an object changes. My original thought was that this would track only data, not meta-data changes. This is not what we are doing now. For example, updating an object's DC title changes it's modification time. I'm not sure what we should do here. - Update indexes (and other cache-like data structures) There is a thought that perhaps the generated event could contain enough information to eliminate some indexes from use. This is (mostly) an optimization. In one of his proposals, Uwe suggested including an interface and attributes that were changed as optional information in an event. In some cases, I think this information could be pretty useful, however, it probably isn't useful in as many cases as you might expect. The common pattern for Zope 3 indexes is that they adapt an object to an interface of interest. The index can't really know how an adapter computes it's data. The data are sometimes computed from data in a completely separate interface. Probably the indexes that we *most* want to avoid reindexing are text indexes. We have a ISearchableText interface that we commonly adapt objects to to get the text to index. We really can't predict how this text is computed. A safer strategy seems to me to be to have the indexes themselves responsible for detecting changes that they care about. I'm pretty sure that some of the Zope 2 indexes are careful to avoid reindexing, or at least avoid updating indexes if indexed values haven't changed. Unfortunately, the Zope 3 indexes don't seem to be doing this fairly straightforward optimization, which is a shame. Given the applications above, I don't think that there's value in fine-grained modification events that justifies the complecity of proposals we've thought of so far. Thoughts? Are there other applications for modification events that I haven't considered? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
This proposal is way too unpythonic IMO. Application code shouldn't have to go through this much machinery just to make changes. I don't mind if some application does something like this, but I wouldn't want to make this a standard mode of operation for Zope 3. If a goal is to avoid reindexing values that haven't changed, then I would say that indexes should remember old values and only reindex if the value hasn't changed. This would be an optimization and thus optional. Jim Uwe Oestermeier wrote: Dieter Maurer wrote: As soon as you index the content, you will be interested to distinguish between a modification in the primary content and some meta data (as it has big repercussions on the speed of the reindexing). I agree, but perhaps we can find a compromise that fits all needs. I propose to use pluggable modification utilities. The container related events are already fired by only two functions (setitem and uncontained). If we introduce a third one for object modification (e.g. update or modify and an additional annotate if needed), we can replace these functions with callable utilities, which are responsible for performing the changes and firing the events. It's then up these components which events are actually used. Direct calls of ObjectModifiedEvents can then be marked as deprecated to ensure that all applications will use these pluggable modifiers. Regards, Uwe The following code should make clear what I mean: #! python import doctest, unittest, zope from zope.app import zapi from zope.interface import Interface, implements from zope.app.event.objectevent import ObjectModifiedEvent from zope.app.event.interfaces import IObjectModifiedEvent class IPluggableModifier(Interface) : """ A pluggable modifier can be used to replace the existing modification mechanism in Zope. It should be used in all places where other systems are notified about changes. The implementation must ensure that at least one IObjectModifiedEvent is fired if an object's state has been changed. """ def __call__(self, obj, interface, **kw) : """ Performs the update and fires an IObjectModifiedEvent. It's up to the plugin which specialization of IObjectModifiedEvent is actually used. Returns the modified object or None if the object could not be modified. """ class DefaultModifier(object) : """ Implements a default behavior that mimics Zope3's current modification event handling. Setup : >>> from zope.component import provideUtility >>> provideUtility(DefaultModifier(), IPluggableModifier) >>> events = [] >>> zope.event.subscribers.append(events.append) >>> class Sample(object) : pass Usage : >>> modify = zapi.getUtility(IPluggableModifier) >>> sample = Sample() >>> result = modify(sample, None, title='Test', description='Example') >>> result == sample True >>> IObjectModifiedEvent.providedBy(events[0]) True >>> sample.title 'Test' >>> sample.description 'Example' """ implements(IPluggableModifier) def __call__(self, obj, interface, **kw) : """ Modifies an object and fires an IObjectModifiedEvent. """ if interface is not None : obj = interface(obj) for key, value in kw.items() : setattr(obj, key, value) zope.event.notify(ObjectModifiedEvent(obj)) return obj class ValueChangedEvent(object) : """ A modification event that keeps additional information about the used interface, the old and new values. """ def __init__(self, object, interface, key, old_value, new_value) : self.object = object self.interface = interface self.key = key self.old_value = old_value self.new_value = new_value class BetterModifier(object) : """ Implements a modification behavior that fires more informative events for more efficient versioning and reindexing. Setup : >>> from zope.component import provideUtility >>> provideUtility(BetterModifier(), IPluggableModifier) >>> events = [] >>> zope.event.subscribers.append(events.append) >>> class Sample(object) : pass Usage : >>> modify = zapi.getUtility(IPluggableModifier) >>> sample = Sample() >>> result = modify(sample, None, title='Test', description='Example') >>> result == sample True >>> sample.title 'Test' >>> sample.description 'Example' >>> for x in events : print x.__class__.__name__ ValueChangedEvent ValueChangedEvent ObjectModifiedEvent """ implements(IPluggableModifier)
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Dieter Maurer wrote: >Sounds good, but I am nevertheless convinced that we >want finer grain control -- almost as fine (but probably with other >means) as the "idxs" argument to "catalog_object" (which controls >precisely which indexes should be reindexed). We will probably >replace the selection of affected indexes with some interface >related concept. That's exactly what my proposal wants to achieve. If you need finer control the pluggable modifier is the right place to introduce whatever you want. Besides special events you can add hooks, introduce type specific adapters etc. All we need at the moment (at least for cataloging and versioning) is the certainty that all relevant modifications are going through the same replaceable component. Everything else can be implemented later on. As far as I understand Zope3's catalog implementation most indexes use a interface + attribute specification, which a ValueChangedEvent could provide. The "BetterModifier" in my proposal sends these infos in addition to an unspecific modified event and thus should be sufficient for most purposes. One problem I see is that different schema adapters can use the same slots for different fields. To solve this problem one could probably use object annotations to store footprints of the involved indexes and their relationships. But again the modification component would be the right place to evaluate these annotations. -- Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Uwe Oestermeier wrote at 2005-5-11 11:18 +0200: > ... indexing performance ... >I agree, but perhaps we can find a compromise that fits >all needs. I propose to use pluggable modification utilities. > >The container related events are already fired by only two >functions (setitem and uncontained). If we introduce a third >one for object modification (e.g. update or modify and an >additional annotate if needed), we can replace these >functions with callable utilities, which are responsible for >performing the changes and firing the events. >It's then up these components which events are >actually used. Sounds good, but I am nevertheless convinced that we want finer grain control -- almost as fine (but probably with other means) as the "idxs" argument to "catalog_object" (which controls precisely which indexes should be reindexed). We will probably replace the selection of affected indexes with some interface related concept. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Dieter Maurer wrote: As soon as you index the content, you will be interested to distinguish between a modification in the primary content and some meta data (as it has big repercussions on the speed of the reindexing). I agree, but perhaps we can find a compromise that fits all needs. I propose to use pluggable modification utilities. The container related events are already fired by only two functions (setitem and uncontained). If we introduce a third one for object modification (e.g. update or modify and an additional annotate if needed), we can replace these functions with callable utilities, which are responsible for performing the changes and firing the events. It's then up these components which events are actually used. Direct calls of ObjectModifiedEvents can then be marked as deprecated to ensure that all applications will use these pluggable modifiers. Regards, Uwe The following code should make clear what I mean: #! python import doctest, unittest, zope from zope.app import zapi from zope.interface import Interface, implements from zope.app.event.objectevent import ObjectModifiedEvent from zope.app.event.interfaces import IObjectModifiedEvent class IPluggableModifier(Interface) : """ A pluggable modifier can be used to replace the existing modification mechanism in Zope. It should be used in all places where other systems are notified about changes. The implementation must ensure that at least one IObjectModifiedEvent is fired if an object's state has been changed. """ def __call__(self, obj, interface, **kw) : """ Performs the update and fires an IObjectModifiedEvent. It's up to the plugin which specialization of IObjectModifiedEvent is actually used. Returns the modified object or None if the object could not be modified. """ class DefaultModifier(object) : """ Implements a default behavior that mimics Zope3's current modification event handling. Setup : >>> from zope.component import provideUtility >>> provideUtility(DefaultModifier(), IPluggableModifier) >>> events = [] >>> zope.event.subscribers.append(events.append) >>> class Sample(object) : pass Usage : >>> modify = zapi.getUtility(IPluggableModifier) >>> sample = Sample() >>> result = modify(sample, None, title='Test', description='Example') >>> result == sample True >>> IObjectModifiedEvent.providedBy(events[0]) True >>> sample.title 'Test' >>> sample.description 'Example' """ implements(IPluggableModifier) def __call__(self, obj, interface, **kw) : """ Modifies an object and fires an IObjectModifiedEvent. """ if interface is not None : obj = interface(obj) for key, value in kw.items() : setattr(obj, key, value) zope.event.notify(ObjectModifiedEvent(obj)) return obj class ValueChangedEvent(object) : """ A modification event that keeps additional information about the used interface, the old and new values. """ def __init__(self, object, interface, key, old_value, new_value) : self.object = object self.interface = interface self.key = key self.old_value = old_value self.new_value = new_value class BetterModifier(object) : """ Implements a modification behavior that fires more informative events for more efficient versioning and reindexing. Setup : >>> from zope.component import provideUtility >>> provideUtility(BetterModifier(), IPluggableModifier) >>> events = [] >>> zope.event.subscribers.append(events.append) >>> class Sample(object) : pass Usage : >>> modify = zapi.getUtility(IPluggableModifier) >>> sample = Sample() >>> result = modify(sample, None, title='Test', description='Example') >>> result == sample True >>> sample.title 'Test' >>> sample.description 'Example' >>> for x in events : print x.__class__.__name__ ValueChangedEvent ValueChangedEvent ObjectModifiedEvent """ implements(IPluggableModifier) undefined = object() def __call__(self, obj, interface, **kw) : """ Modifies an object and fires an IObjectModifiedEvent. """ if interface is not None : obj = interface(obj) for key, value in kw.items() : old = getattr(obj, key, self.undefined) if old != value : setattr(obj, key, value) event = ValueChangedEvent(obj, interface, key, old, value) zope.event.notify(event) zope.even
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
Garrett Smith wrote at 2005-5-9 12:35 -0500: > ... >I'd be concerned about making ObjectModifiedEvent too burdensome for >developers. For most, cases, it's sufficient to just say "this object >has changed" and be done with it. But many developers are interested in efficiency. As soon as you index the content, you will be interested to distinguish between a modification in the primary content and some meta data (as it has big repercussions on the speed of the reindexing). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
Uwe Oestermeier wrote: ...very good analysis of current modified event usage... > 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. I certainly like the idea of getting rid of ObjectContentModifiedEvent and ObjectAnnotationsModifiedEvent -- they're both WHUI (we haven't use it) as you've shown. I'd be concerned about making ObjectModifiedEvent too burdensome for developers. For most, cases, it's sufficient to just say "this object has changed" and be done with it. As for your goals of maintaining versioning for any possible third part product added to Zope, I think you'll need another strategy -- there's no guarentee that you'll get all the change info you need. Someone may choose, for example, not to use the default forms machinery (assuming that's even changed to support the proposed scheme). I do think a 'property changed' scheme -- one that let subscribers veto changes -- would be an excellent addition to the object change lifecycle. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
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. Regards, Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Garrett Smith wrote: Jim Fulton wrote: Garrett Smith wrote: Uwe Oestermeier wrote: In the meanwhile we need a decision, whether the ObjectContentModifiedEvent should be used in the File._setData method. I would like to check this solution in. Any objections? The ObjectContentModifiedEvent class can be removed later on, if noone else is using it. -1 if ObjectContentModifiedEvent does't have a clear distinction from ObjectModifiedEvent. For my part, I don't see a difference in modifying a 'data' attribute because it's a large number of bytes, versus modifying a 'title' attribute or some other non-'content' value. If ObjectModifiedEvent isn't firewhen when a file's data changes, it should be (assuming people buy my previous point :) I think the distinction is pretty clear. Clear enough after you explain it. We divide information into ordinary/intrinsic and meta/extrinsic informatiom. IObjectContentModifiedEvent should indicate that intrinsic information has changed. IObjectAnnotationsModifiedEvent, which isn't well named, should indicate that extrinsic/meta information has changed. 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. Yup. Yup. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
Jim Fulton wrote: > Garrett Smith wrote: >> Uwe Oestermeier wrote: >> >>> In the meanwhile we need a decision, whether the >>> ObjectContentModifiedEvent should be used in the File._setData >>> method. I would like to check this solution in. Any objections? The >>> ObjectContentModifiedEvent class can be removed later on, if noone >>> else is using it. >> >> >> -1 if ObjectContentModifiedEvent does't have a clear distinction from >> ObjectModifiedEvent. For my part, I don't see a difference in >> modifying a 'data' attribute because it's a large number of bytes, >> versus modifying a 'title' attribute or some other non-'content' >> value. >> >> If ObjectModifiedEvent isn't firewhen when a file's data changes, it >> should be (assuming people buy my previous point :) > > I think the distinction is pretty clear. Clear enough after you explain it. > We divide information into ordinary/intrinsic and meta/extrinsic > informatiom. > > IObjectContentModifiedEvent should indicate that intrinsic information > has changed. > > IObjectAnnotationsModifiedEvent, which isn't well named, should > indicate that extrinsic/meta information has changed. 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. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Garrett Smith wrote: Uwe Oestermeier wrote: In the meanwhile we need a decision, whether the ObjectContentModifiedEvent should be used in the File._setData method. I would like to check this solution in. Any objections? The ObjectContentModifiedEvent class can be removed later on, if noone else is using it. -1 if ObjectContentModifiedEvent does't have a clear distinction from ObjectModifiedEvent. For my part, I don't see a difference in modifying a 'data' attribute because it's a large number of bytes, versus modifying a 'title' attribute or some other non-'content' value. If ObjectModifiedEvent isn't firewhen when a file's data changes, it should be (assuming people buy my previous point :) I think the distinction is pretty clear. We divide information into ordinary/intrinsic and meta/extrinsic informatiom. IObjectContentModifiedEvent should indicate that intrinsic information has changed. IObjectAnnotationsModifiedEvent, which isn't well named, should indicate that extrinsic/meta information has changed. I agree that a more precise model might be useful, if one could design one that made sense. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
Uwe Oestermeier wrote: > In the meanwhile we need a decision, whether the > ObjectContentModifiedEvent should be used in the File._setData > method. I would like to check this solution in. Any objections? The > ObjectContentModifiedEvent class can be removed later on, if noone > else is using it. -1 if ObjectContentModifiedEvent does't have a clear distinction from ObjectModifiedEvent. For my part, I don't see a difference in modifying a 'data' attribute because it's a large number of bytes, versus modifying a 'title' attribute or some other non-'content' value. If ObjectModifiedEvent isn't firewhen when a file's data changes, it should be (assuming people buy my previous point :) -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Garrett Smith wrote: I think ValueChangedEvent would be a good addition to the forms machinery. But if you need something like that now, I'd recommend using your own edit view class. That would be a solution for the moment, but in the future I would like to say that my application provides also versioning for content types of other third party applications. This leads to a second major problem: How can I be sure that other applications do send events for all modifications they perform. It is very easy to forget that. My versioning scheme would be less error prone if I could check for modified objects via ITransaction.beforeCommitHook or ISynchronizer.beforeCompletion. Can this already be done in the current state of development? I found no hints in the Zope3 sources that these interfaces of the transaction module are already used. In the meanwhile we need a decision, whether the ObjectContentModifiedEvent should be used in the File._setData method. I would like to check this solution in. Any objections? The ObjectContentModifiedEvent class can be removed later on, if noone else is using it. Regards, Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
Uwe Oestermeier wrote: > "Garrett Smith" wrote: > > I'd see this being something like a ValueChangedEvent that specified > the object, schema, field name, old value, and new value. This would > be a nice way to bolt on validation without modifying the schema. > > Yes, that's exactly what I need for versioning. > > Anyone needing more information in ObjectModified can just create a > new event type with the additional info. This seems application > specific to me. > > But there is a major problem: How can you reuse an existing > infrastructure then? You have to write all editing views or other > components that modify the content objects anew. It wouldn't be that hard. You would extend EditView (in zope/app/form/browser) and insert your own event firing as needed. Then just specify your new view as the class attribute in ZCML. You can redefine the standard Zope views for the handful of content types they provide using overrides.zcml. > In my view > ValueChangedEvents are usefull in many applications and for many > purposes (reindexing catalogs, updating views in standalone > applications, triggering external processes etc.). Would it be too > much overhead to have them in the framework from the beginning? I think ValueChangedEvent would be a good addition to the forms machinery. But if you need something like that now, I'd recommend using your own edit view class. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
"Garrett Smith" wrote: I'd see this being something like a ValueChangedEvent that specified the object, schema, field name, old value, and new value. This would be a nice way to bolt on validation without modifying the schema. Yes, that's exactly what I need for versioning. Anyone needing more information in ObjectModified can just create a new event type with the additional info. This seems application specific to me. But there is a major problem: How can you reuse an existing infrastructure then? You have to write all editing views or other components that modify the content objects anew. In my view ValueChangedEvents are usefull in many applications and for many purposes (reindexing catalogs, updating views in standalone applications, triggering external processes etc.). Would it be too much overhead to have them in the framework from the beginning? Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
Uwe Oestermeier wrote: > But I could also live with ObjectModifiedEvents only. IMO, the second event type, if it doesn't have a clear distinction, should be removed. > A more radical approach would be to specify in each > ObjectModifiedEvent which aspects of an object changed. By aspect I > mean the schema and the modified field within the schema: I'd see this being something like a ValueChangedEvent that specified the object, schema, field name, old value, and new value. This would be a nice way to bolt on validation without modifying the schema. Anyone needing more information in ObjectModified can just create a new event type with the additional info. This seems application specific to me. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Garrett Smith wrote:
What is the difference between 'content' that gets modified and the
object that gets modified.
In my understanding the difference stems from the filesystem
metaphor behind Zope. The "content" of a Zope object corresponds
to the content of a file, while other attributes are more like descriptive
metadata (e.g. modification time).
The distinction however is not clear cut because content objects
can be much more complex than simple files and metadata can also be stored
in annotations.
In my use case, however, it makes sense to draw such a distinction
because I'm using the filesystem to store versions.
Content in this sense is simply that what can be edited by opening and writing files.
Since Zope3 supports WebDAV and FTP something similar is probably needed for
other systems too.
But I could also live with ObjectModifiedEvents only.
I've to check all aspects of an object anyway, because
the non-content parts of an object are versionable too. Currently I loop over
all versionable attributes (which are provided by special adapters) and
try to detect all differences between new and old versions of an object.
A more radical approach would be to specify in each ObjectModifiedEvent
which aspects of an object changed. By aspect I mean the schema and the modified
field within the schema:
class IPerson(Interface) :
age = Attribute("The age of the person")
class Person(object) :
implements(IPerson)
person = Person()
person.age = 42
zope.event.notify( ObjectModifiedEvent(person, aspect=IPerson["age"]))
File content then could be handled as a special case :
file.data = "">
zope.event.notify( ObjectModifiedEvent(person, aspect=IFile["data"]))
With this extension the ObjectModifiedEvents would be more informative and a loop over all versionable
attributes in my application would become unnecessary. This would also make updates of
catalogs more efficient.
Regards
Uwe Oestermeier
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
>From the interface docs, it's not clear to me what the difference between the events are: class IObjectModifiedEvent(IObjectEvent): """An object has been modified"" class IObjectContentModifiedEvent(IObjectModifiedEvent): """An object's content has been modified""" What is the difference between 'content' that gets modified and the object that gets modified. How might I interpret receiving both events for a 'modify' operation on the same operation? -- Garrett Jim Fulton wrote: > Uwe Oestermeier wrote: >> Hi, >> >> I'm working on a versioning system that creates a new version for >> each changed file content. I tried to listen to >> zope.app.event.interfaces.IObjectContentModifiedEvents, >> but unfortunately no such event seems to be generated. >> >> Editing an existing zope.app.file.File via the edit view leads only >> to an ObjectModifiedEvent, uploading new content produces no object >> event at all. >> >> Should this be fixed by generating ObjectContentModifiedEvents in >> both cases (which I would prefer), > > Yes. > >> or should the less informative ObjectModifiedEvent be used? In the >> later case, the misleading IObjectContentModifiedEvent should >> probably removed from the list of objectevents. >> >> In general, missing events are difficult to detect and I'm quite sure >> that file editing and uploading >> are not the only relevant cases (e.g. WebDAV and FTP are other ways >> to modify file contents). Wouldn't it be the best solution to >> generate an IObjectContentModifiedEvent in the File._setData method >> and not the view classes? > > I think this would be OK for this specific case. > > What I don't want to see is some general implicit event-generation > scheme. > > Jim ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Uwe Oestermeier wrote: Hi, I'm working on a versioning system that creates a new version for each changed file content. I tried to listen to zope.app.event.interfaces.IObjectContentModifiedEvents, but unfortunately no such event seems to be generated. Editing an existing zope.app.file.File via the edit view leads only to an ObjectModifiedEvent, uploading new content produces no object event at all. Should this be fixed by generating ObjectContentModifiedEvents in both cases (which I would prefer), Yes. or should the less informative ObjectModifiedEvent be used? In the later case, the misleading IObjectContentModifiedEvent should probably removed from the list of objectevents. In general, missing events are difficult to detect and I'm quite sure that file editing and uploading are not the only relevant cases (e.g. WebDAV and FTP are other ways to modify file contents). Wouldn't it be the best solution to generate an IObjectContentModifiedEvent in the File._setData method and not the view classes? I think this would be OK for this specific case. What I don't want to see is some general implicit event-generation scheme. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Missing ObjectContentModifiedEvent
Hi, I'm working on a versioning system that creates a new version for each changed file content. I tried to listen to zope.app.event.interfaces.IObjectContentModifiedEvents, but unfortunately no such event seems to be generated. Editing an existing zope.app.file.File via the edit view leads only to an ObjectModifiedEvent, uploading new content produces no object event at all. Should this be fixed by generating ObjectContentModifiedEvents in both cases (which I would prefer), or should the less informative ObjectModifiedEvent be used? In the later case, the misleading IObjectContentModifiedEvent should probably removed from the list of objectevents. In general, missing events are difficult to detect and I'm quite sure that file editing and uploading are not the only relevant cases (e.g. WebDAV and FTP are other ways to modify file contents). Wouldn't it be the best solution to generate an IObjectContentModifiedEvent in the File._setData method and not the view classes? Cheers, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
