[Zope-dev] Re: unregistering components?

[Philipp von Weitershausen]

Chris Withers wrote:
> Philipp von Weitershausen wrote:
>> On 25 Nov 2007, at 13:37 , Chris Withers wrote:
>>> Philipp von Weitershausen wrote:
>>>>>> class IComponentRegistry(interface.Interface):
>>>> I think you should use zope.component.getGlobalSiteManager() for this.
>>>
>>> So getGlobalSiteManager returns a component registry?
>>
>> 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.

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

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

>>> How do you set up nested registries? For example, if a certain area 
>>> of a site should have a registry which overrides the global one, but 
>>> only for that area, and should fall back on it if not adapter could 
>>> be found?
>>
>> You use sites. Sites are places (usually containers) in the component 
>> hierarchy that have (local) component registries associated with them. 
> 
> So, by "component heirarchy" I'm guessing you really mean "object 
> hierarchy"

Yeah, sorry.

> and by "Site" you mean "something implementing IComponentRegistry"?

No, something implementing ISite, which defines a setSiteManager and 
getSiteManager for setting and retrieving an IComponentRegistry.

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

>> And yes, the name "site" is misleading, but again, we have it as 
>> legacy now. How to work with sites, how to set them up, etc. is all 
>> explained in my book. I'm sure you have a copy :)
> 
> I do, and I'm very greatful for it...
> 
>> (Btw, this thread has nothing to do with the development *of* Zope and 
>> is therefore zope at zope.org or zope3-users at zope.org rather than 
>> zope-dev at zope.org material.)
> 
> ...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.

> In short, if the current zope.component implementation already does what 
> I want, or whether I need to do work on the development *of* it it order 
> to get what I'm after...
> 
> ...of course, I don't know exactly what I'm after yet, but I hope you'll 
> bear with my questions in the meantime ;-)