[EMAIL PROTECTED] wrote: > >- 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.
Yes, that's an alternative I'm considering. It would be nice to have an explict API for getting the modified objects of a transaction and I remember that this was discussed on another list months ago. Is there such an API already? I didn't find one. > >- 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. In my view this depends on the use case. For instance, currently I'm working on a blog system that uses DC title and description together with the body of the blog entry as parts of a searchable text. The whole blog entry with title, description, and body appears to the user as a unit. In this case it seems ok, that the modification date is changed if one part of the searchable text is changed. But I'm also using DC effective as publication date and there it would be misleading if a change of the publication date also changes the modification date. So we have at least two types of annotations here. This was one reason, why I proposed a pluggable mechanism for event notification. We cannot know in advance what kinds of events are really needed and which distinctions will be necessary in the future. But I agree with you, that the use of a utility is not very Pythonic, although the proposed modify(obj, key1=value1, key2=value2, ...) syntax was borrowed from dict.update. > >- 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. ... > > 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. Yes, not from outside. But as a programmer I know which interfaces I use. To use the blog example again: given that the used interface+attribute is recorded in the modification event it's not to difficult to write a subscriber that listens to changes of the body, the title or description, and fires an additional modification event for ISearchableText["getSearchableText"] if a change of a part is detected. The problem of computed attributes has to be solved anyway. If I have an object schema that promises an attribute and the value is computed from the state of other objects we have chains of dependent modification events, or we cannot rely on the event mechanism any longer. It is probably easier to write and understand such chains if the events describe in detail what happens. > > >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. That might be, but what remains from the idea of loosely connected components that communicate via events if we need hooks into the transaction machinery for versioning, a special dependency checker for indexing and caching, and application specific modification events even for a simple blog implementation? > > >Thoughts? The container events are much more specific and contain enough information to undo/redo the described operation. Why are modification events treated differently here? Wouldn't it be a usefull rule of thumb, that all events should carry enough information to be able to undo/redo them? I agree with Dieter that efficiency will become important as soon as Zope3 has to cope with office documents and user expectations. I'm not sure whether all optimization issues should be left to the applications. This will result in applications that use hooks, direct update calls, etc. instead of events and it will become difficult to use them in combination. > >Are there other applications for modification events that >I haven't considered? I'm using modification events in a wxPython app with a MVC architecture. Zope3 events are a very clean way to keep models and their views in sync. There are of course other ways to avoid unnecessary flicker, but the most easy way to update only the affected parts of a view is to specify the changed part of the model. That was also a motivation behind my proposal to use a pluggable modification mechanism. -- Uwe > > _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com