[Zope-dev] Re: unregistering components?

[Philipp von Weitershausen]

On 26 Nov 2007, at 18:17 , Chris Withers wrote:
> Philipp von Weitershausen wrote:
>>>> Yes. It returns the one and only global registry.
>>>
>>> Am I right in thinking the global registry is _only_ used if no  
>>> context is supplied?
>> No. One should never have to supply an explicit context.
>
> Surely that's only the case if you're using zope's traversal stuff?

Yup.

> I'm guessing that if you are, you either need to stick with the one  
> global registry or manage either ISites or IComponentLookup's  
> yourself?

Not sure what you mean by "if you are".

>>>>> If so, how come it's not called getGlobalComponentRegistry?
>>>>
>>>> Because component registries used to be called site managers and  
>>>> we can't just change the API at this point anymore.
>>>
>>> Well, getGlobalComponentRegistry could be added as an alternate  
>>> spelling and people could be encouraged to use it ;-)
>> Feel free to submit a patch :)
>
> It's entertaining to get asked to submit a patch *and* told you're  
> not doing anything that belongs on the -dev list in the same email ;-)

Touche ;)

>>> There seems to be comments suggesting getSiteManager is  
>>> deprecated, but maybe I'm not getting exactly what is being  
>>> deprecated...
>> It's not deprecated at all. If it were, it would say so in the code  
>> and emit a deprecation warning when you try to use it.
>
> What's line 37 of component._api on about then?

# SiteManager API. This needs to get deprecated eventually.

It says *eventually*  :)

>>> and by "Site" you mean "something implementing IComponentRegistry"?
>> No, something implementing ISite, which defines a setSiteManager  
>> and getSiteManager for setting and retrieving an IComponentRegistry.
>
> Are you sure you don't mean ISiteManager, which is marked as being  
> deprecated and to be removed in 2007...

Yes, I'm sure I mean ISite.

> If you mean a different ISite, where is it defined?

zope.app.component.interfaces. Well, it moved to  
zope.location.interfaces recently in order to reduce the amount of  
interdependencies between the eggs, but it's still available w/o  
deprecation from zope.app.component.interfaces.

> (and I'm guessing there is an ISite somewhere, as I could find no  
> definition of setSiteManager, but how does IComponentArchitecture's  
> getSiteManager relate to that of ISite?)

zope.component.getSiteManager() will return whichever component  
registry is active.  site.getSiteManager() will return the local  
component registry that has been associated with site (which provides  
ISite).

>>> I'm guessing the adapter to IComponentLookup is what implements  
>>> the search up the object graph to find an IComponentRegistry?
>> Yes, but that's rarely used (only when you pass an explicit context  
>> which we almost never do).
>
> I think I'm misreading the code in _api then. It looks to me that  
> most things use getSiteManager (even though the comment says it  
> needs to be deprecated) which always appears to return either the  
> global registry or do an IComponentLookup adaptation. If no explicit  
> context is supplied, how does anything other than the global  
> registry end up getting used?

getSiteManager is "overloaded" from zope.app.component. See hooks.py.  
Yay for indirection :).

>> Normally, during traversal, an event subscriber reacts to ISites  
>> being traversed and remembers the site's component registry in a  
>> thread-local variable. getSiteManager() will then return whatever  
>> is in the thread-local variable, and therefore getUtility,  
>> getMultiAdapter, etc., will use that local registry.
>>> If so, where do I find that adapter implementation(s)?
>> See zope.app.component (also for the subscriber stuff mentioned  
>> above).
>
> I spent quite a while looking and didn't spot them. Where exactly?

A quick look through zope.app.component/configure.zcml reveals that  
the subscriber is in site.py. The rest of the machinery is in hooks.py.

> (also bear in mind that I don't really want to use any of zope.app...)

Fair enough.

>>> ...however, I'm interested in the mechanics of how zope.component  
>>> handles multiple component registries, in particular how  
>>> registries are added to and removed from the set of registries  
>>> that are searched hen looking for a component and some other bits  
>>> and pieces.
>> Which is the *use* of Zope, not the *development* of Zope.
>
> I'm not really sure why you're quibling over this but I'm quite  
> happy to move this discussion to zope3-users if you're prefer and  
> then move it back to zope-dev if it turns out I need to do  
> *development* of Zope (such as the patch you requested above ;-) )

I guess I'm nitpicking. I would just like to stress the focus of the  
zope-dev list. And regarding the patch, I've encouraged people to  
submit patches on zope3-users before, too ;).