[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