I'm not wedded to this philosophy, but I think Zope should provide as
little application-specific event notifications as possible. I think
even the distinction between 'content' and 'metadata' in the current
implementation is dubious. (I don't believe the 'metadata' events are
even used.) I'd just as soon see a single 'object modified' event that
gets fired by the ZMI interfaces as appropriate.
The rest (I think) is all application specific.
If there are a handful of important indexes (e.g. text), they might
publish an applicable set of events that can be fired by applications
that want to use them. I don't think this needs to be in the core --
each index (or other utility) needs to provide its own event-API.
My take anyway.
Jim Fulton wrote:
> A week or so ago, there was a thread on the distinction between
> IObjectModifiedEvent, IObjectAnnotationsModifiedEvent, and
> 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
> 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.
> Are there other applications for modification events that
> I haven't considered?
Zope3-dev mailing list