[Zope3-dev] Re: Container interface issues

[Jim Fulton]

Shane Hathaway wrote:
> Anthony Baxter wrote:
> 
>>>>> Jim Fulton wrote
>>>
>>>
>>> I proposed that application code, rather than containers, be
>>> responsible for generating events and calling necessary hooks when
>>> adding or removing objects.  
>>
>>
>>
>> I understand the rationale for it (indeed, I can't see a better way) but
>> this makes me uneasy. In the process of hooking up the catalog I found a
>> number of existing places that were not Doing The Right Thing with event
>> generation - making more places to do this Would Be Bad. Tracking down
>> missing event generation stuff also sucks - things are just wacky, and
>> it takes some time to find the problem.
> 
> 
> Even so, it doesn't feel right to make containers generate the events. 
> They don't have enough information to know why an object is being added 
> or removed.
> 
> I wonder if there's some kind of "structure management" layer lurking 
> here.  It looms somewhere between the application and the database.  It 
> smells like RDBMS triggers and relational integrity.


This is an interesting point.

Consider a move operation.  In Zope, a move operation is special
because it doesn't change an object's identity. It only changes it's
location.  Deleting an object implies removing it from the system.
Other objects that contain information about the object being moved
are expected to delete their information, or to veto the deletion.
When we move an object, meta data is retained, although we might
update data for the location.

Generally, relational databases have no nothion of object identity,
except, possibly, for the primary key.  In a relational database,
there are a number of ways we might model location.  Typically,
location would be modeled as a value stored in a row.  I suppose that,
in this case, moving would have nothing to do with adding or deleting.

Hm. Maybe we should step back and reconsider the meaning of these
events.

What if we just had moved events, with attributes:

   object -- The object being moved

   oldparent -- The old location __parent__

   oldname -- The old __name__

   newparent -- The new location __parent__

   newname -- The new __name__

So, when we add an object, the old parent and name would be None.

So, when we remove an object, the new parent and name would be None.

Now, when we move an object, we'd *first* add it to the new location.
This would cause a move event to be generated with non-None values for
the old and new parents and names.  We'd then remove the object from
the old container. We'd have a rule that when removing an item from a
container, we would not generate a moved event if the parent of the
object being removed is different than the container it is being
removed from.  This logic allows us to distinguish adds, removes, and
moves. I *think* that all of this could be automated through a fairly
simple api.

I'll put a proposal in a separate message.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (703) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org