[Zope-dev] Re: unregistering components?

[Chris Withers]

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?
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?

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

>> 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?

>> 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...

If you mean a different ISite, where is it defined?
(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?)

>> 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?

> 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?

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

>> ...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 ;-) )

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk