Location-related events (was Re: [Zope3-dev] Using parent references rather than context wrappers to represent containment)

Jim Fulton jim at zope.com
Wed Aug 13 17:20:19 EDT 2003


Phillip J. Eby wrote:
> At 10:58 AM 8/13/03 -0400, Jim Fulton wrote:
> 
>> I worked up a preproposal on location-related events at:
>>
>>   http://dev.zope.org/Zope3/LocationRelatedEvents
>>
>> I've conviced, based on this preliminary analysis, that containers 
>> cannot be
>> responsible for generating location-change events.
> 
> 
> Per our previous discussion, I disagree with "location implies 
> traversal", since a component may wish to use another component as its 
> context, and yet that context has no references to the component.

This is a matter of definition. In Zope, location definately implied traversal.
One of the most common uses of ILocation will be to generate paths that can
be traveresed and URLs.  There could be other forms of context, but Zope's
notion of location is definately tied up with traversal. This is spelled
out in ILocation:

               __name__ = schema.TextLine(
                   __doc__=
                   """The name within the container

                   The container can be traversed with this name to get
                   the object.  """)

...

> That is, I'm not 
> sure what the use case is for propagating an event to all descendants of 
> a container. 

We need to generate events *for* (not to) all of the descendents.  If
I remove a container, I'm also removing everything that's contained.

For example, if I remove an object, I need to generate a remove event
that has, in it's data, information about all of the objects that have
been removed. This includes all of the objects located within the removed
object. To do this, I need to know what these objects are.


...

> As far as the event structure...  in ZPatterns I found it useful to 
> structure the event differently according to who was receiving it.  I 
> don't know if this will do what you want, but anyway, what I did was 
> that each recipient saw the event from its own point of view.  Let's say 
> that you had this structure:
> 
>     A
>    / \
>   B   C
> 
> And you moved an object O from folder B to folder C.  A received an 
> event that said "O moved from B to C", while B received an event that 
> said "O has been removed", and C received an event that said "O has just 
> arrived".  The purpose of this is that if B and C have local invariants 
> to preserve regarding their contents, they are seeing the right kind of 
> event, from their local perspective.  Meanwhile, A could maintain any 
> location-based things, but would not think an object had been created or 
> destroyed.
> 
> Perhaps this is the sort of event structure you are looking for?

No. Events in Zope 3 are used to decouple things.  An object publishes
an event having no idea who may be interested in it. Event subscribers
get relavent events and take actions based on them. Event channels may
provide some extra processing or routing along the way.

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




More information about the Zope3-dev mailing list