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 [EMAIL PROTECTED] or [EMAIL PROTECTED] rather than
zope-dev@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 ;-)
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )