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: [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
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
[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
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
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
[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
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 RD +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
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: [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
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 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: 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-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)
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
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
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
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: 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. shrug 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: 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
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: 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
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
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
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
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
