[Zope3-dev] event-meta.zcml placement? i18n-meta.zcml?

Gary Poster gary@modernsongs.com
Tue, 17 Dec 2002 12:45:20 -0500


Steve Alexander wrote:
> 
>> The current event services are not aware of traversal, relying instead 
>> on indirect subscribers for traversal and weak referencing.  
>> Therefore, if the design doesn't change, that isn't an issue.  Do you 
>> want the design to change?
> 
> 
> ObjectEvents need to be able to have a lazy location. So, they need to 
> be aware of traversal.
> 
> The service itself doesn't need to be aware of this. There should be 
> ObjectEvent implementations in Zope.App.Event.

OK.  This makes sense and seems easy enough.  I'll do it, unless anyone 
stops me. :-)

> Independently of this, I suggest that subscribing by location should be 
> the most common form of subscription in Zope 3. This is important to 
> preserve the containment context of objects when they are notified of 
> events, so that they will have the correct security context.
> 
> As this is very common, and important for security, it should be easy 
> to subscribe in this way. So, either the 'subscribe' method of 
> Subscribable should support subscription by location, or there should 
> be a LocationSubscribable interface to describe this,
>   ...with a subscribeLocation method...
> and EventChannels and the local EventService should support this.

That makes sense as a goal, although subscribing by object hub id 
accomplishes the same goals.

I think "subscribe" should remain location-unaware in both interface and 
implementation.  I prefer the "sub-classed interface with new method" 
approach.

I don't think "subscribeLocation" is a big improvement, though. 
Basically, you are substituting

   eventService.subscribeLocation(locationAsTuple(myObj))

for the current approach's

   eventService.subscribe(PathSubscriber(myObj)

and/or (more-or-less theoretical)

   eventService.subscribe(HubIdSubscriber(myObj))

This does not seem like a big win to me.

Is the current code above really all that unpleasant?

If the answer is yes :-), another approach might be to have a 
"subscribeProxy" method in a sub-classed interface:

def subscribeProxy(wrappedObj):
     """subscribes the wrapped object in an implementation-specific way
     so as to keep the object wrapped when notified"""

That would give us

   eventService.subscribeProxy(myObj)

which does seem like a reasonable gain.

Gary