At 12:14 PM 5/22/00 -0400, Tres Seaver wrote:

"Phillip J. Eby" wrote:

...

At 03:51 PM 5/21/00 -0400, Tres Seaver wrote:

...

This is really just the classic Observer pattern, a la GoF Design Patterns. "ObjectAdded" and "ObjectRemoved" are events a "RackObserver" would register for; "AfterCreate", "Changed", and "BeforeDestroy" are events of the "hosted" object itself. Note that "ObjectAdded" and "ObjectRemoved" would be called during move or rename operations, even though the object is not being created.

Yes, but the DataManager will filter that such that Zope "Move" and "Rename" operations will show to Indexing and Rule agents as though they were just "Change" events. See the DataManagementEvents entry in the new ZPatterns Wiki for details on how this will work.

This design has the unfortunate side effect of coupling an object tightly to a single location. Properly speaking, objects shouldn't "know" about their containers; the container should be responsible for handling any operations which depend on it. Consider a Unix file system: the command to get rid of a file is "rm," which is an operation on the *directory*, not on the file/subdirectory; it only causes the file to be deleted if the current directory was the only one with a link to the file. CatalogAware is currently broken (as Evan just pointed out to me) because it tries too hard to know about its container's path; it would be better if the container were responsible for doing the index_object/reindex_object/unindex_object stuff, and not the object itself.

You've lost me here. DataManager doesn't care about the object's path. The filtering I was referring to is that the DataManager recognizes a delete followed by an add of the same object (as determined by python "id()" value) as a change operation. It only does this if the add occurs under the domain of the same DataManager, otherwise one DataManager will see a delete and the other will see an add. If you move an object between two locations served by the same data manager, then the move or rename is effectively only a change of the object's path, and any Providers/Agents that care about the path would want to know that it changed. Either way, the notifications follow the reality of the situation. For event management purposes, DataManager does *not* identify objects by anything other than their Python pointer value, and that only for the duration of a (sub)transaction. It is up to the specific Providers and Agents to use whatever identification scheme they want, since different attributes of an object might be used as a key for different external databases. For example, in an X10 home automation project, you might have an IndexingAgent that identified a controller by its Zope path, but the RuleAgent that actually turned lights on and off would want to identify the controllers by their X10 house/unit codes. Hm.. one thing all this makes me realize, though... Providers and Agents will also have to do some "same-object add/delete" recognition, because if the same provider or agent is shared by two DataManagers and the object moves from the scope of one to the scope of the other, it's not *really* an add/delete from *that* agent's perspective, even if it is in general to the DataManager.