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 )

Reply via email to