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

[Steve Alexander]

> I don't think "subscribeLocation" is a big improvement, though. 
> Basically, you are substituting
> 
>   eventService.subscribeLocation(locationAsTuple(myObj))

You can't use locationAsTuple like that. It only takes a location as an 
argument. I guess you want getPhysicalPath(myObj).

In any case, it should simply be:

   eventService.subscribeLocation(myObj)

where myObj is context-wrapped, or

   eventService.subscribeLocation(some_location)


> 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 :-)

I would say "yes" :-)

This means another import for client code.

Also, it is not good for security.

I'd better explain what I mean.

When you offer programmers a choice between a verbose-but-secure call 
and a simple-but-insecure call, they will generally choose the 
simple-but-insecure one. So, our job as framework designers is to play 
upon the laziness of software developers, and make it easier to write 
secure code than insecure code, where we can do so.

Subscription by direct reference is insecure, unless the person writing 
the subscriber really knows what they are doing, because the notify() of 
the subscriber is called without a proper context, and called in 
response to third-party actions.

This is tricky stuff, and in general, writing an event subscriber 
shouldn't be tricky. So, I'd like the simple default 
eventService.subscribe(object) to actually subscribe the object by 
location, and to traverse to that location prior to notifying the object 
of events.

There could be a longer method name for subscribing directly. This will 
be used much more rarely, as measured by lines of developer code.

--
Steve Alexander