[Zope3-Users] Re: Use Case for a Tree of Adapter Registries?

[Philipp von Weitershausen]

Jeff Rush wrote:
> I've read the code for adapter registries, how there is a global one and
> any number of local ones, arranged in a tree and that each can be disabled.
> 
> But I can't figure out when you'd want to make use of such an
> arrangement. The docstrings and .txt files use abstract examples, for
> unit testing, and don't provide a motivation for this feature.
> 
> Related to that, the global registry is loaded at server startup time
> from the various .zcml directives, and I presume that the only way to
> loaded up a local registry is thru-the-web, right?  Which means all
> local registries are persistent in the ZODB, I think.
> 
> Can anyone nudge me onto the right path?

This is going to change with Zope 3.3 so unless you really need to
understand how Zope 3.1 and 3.2 work in this respect, I recommend you
take a look at the zope.component package in the jim-adapter branch of
Zope 3 in SVN.

The ideas behind the simplifications in this branch are:

- There's one global component registry.

- There can be other registries (no relation implied now).

- If registries want to imply a relation, they can refer to other
registries in their __bases__ attribute so that component lookup will
cascade to those.

- Registries *can* be persistent, but don't have to be. A persistent
registry will typically adjust its __bases__ so that it refers to the
next site's registry or, in case that doesn't exist, to the global registry.

The result is that you will be able to register things to a
non-persistent, but also non-global registry. This registry *could* be
identified with a site. This essentially means that some local
configuration can be expressed through ZCML and doesn't need persistent,
TTW management.

There's also a more low-level advantage. All those component registries
are essentially one implementation with some very tiny variations. The
code is very compact. The high-level advantage is that the APIs for
global, local and/or persistent registrations are identical.

HTH.

Philipp