[Zope-dev] ZPatterns framework improvements

[Phillip J. Eby]

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.