[z3-five] context-based utility lookup

[Philipp von Weitershausen]

On 13 Feb 2007, at 09:14 , Chris Withers wrote:
> Philipp von Weitershausen wrote:
>>> Indeed, but can you override the context that gets used to figure  
>>> out what utility gets picked up?
>> Yes, you can always pass in a context explicitly in which case the  
>> closest site to that context will be used for the lookup.
>
> Good stuff :-)
>
> Out of curiosity, is it acquisition or __parent__ that's used to  
> find the "closest" site?

Lacking acquisition, Zope 3 uses __parent__. In Zope 2 we use  
aq_parent if there's no __parent__.

>> Actually, the publication is quite agnostic of sites, fortunately.  
>> All the publication does is send out an IBeforeTraverseEvent for  
>> each object it is about to traverse. zope.app.component has a  
>> subscriber for that event on ISites that "remembers" the site in a  
>> thread local.
>
> Hmm, that brings me to another minor bug bear: I hadto step through  
> the event process a week or so ago in pdb and was pretty horrified  
> as to how many function calls were involved from the time  
> event.notify() got called to when my event subscriber code was  
> actually called.

For a standard event it's 2 functions before your subscriber gets  
called:

   1. zope.event.notify
   2. zope.component.event.dispatch

For an object event there's a third:

   3. zope.component.event.objectEventNotify

I guess it depends on one's point of view if that's "many" or not.

> Not only does it make pdb'ing a pain, but I also wonder how much of  
> a performance hurt that's going to be in a high volume application  
> with a lot of events being fired?

Well, if you wonder, I suggest some profiling. I'd be surprised if  
this were actually a big performance problem, but there's only one  
way to find that out for sure.

As for pdb'ing, I cannot exactly recommend stepping through  
zope.component lookup calls. I've found it more effective to query  
the component registries for their registrations (getSiteManager 
().registeredAdapters(), registeredUtilities(), etc.). This typically  
reveals the problem much quicker, without getting lost in the  
(sometimes optimized and therefore inscrutable) CA code. The only  
thing I'm missing there is a set of filters that one can apply when  
querying the registries, though those shouldn't be too hard to write.