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?
I'm guessing that if you are, you either need to stick with the one
global registry or manage either ISites or IComponentLookup's
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 ;-)
There seems to be comments suggesting getSiteManager is
deprecated, but maybe I'm not getting exactly what is being
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* :)
No, something implementing ISite, which defines a setSiteManager
and getSiteManager for setting and retrieving an IComponentRegistry.
and by "Site" you mean "something implementing 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
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.
See zope.app.component (also for the subscriber stuff mentioned
If so, where do I find that adapter implementation(s)?
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...)
...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
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 ;).
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -