[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

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

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

[Martin Aspeli]

On Fri, 14 Apr 2006 11:07:42 +0100, Jeff Rush  
[EMAIL PROTECTED] 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?


I'm most definitely not the right person to make an authoritative  
statement on this, but something that we're struggling with in Plone's  
adoption of Zope 3 technologies is that CMF/Plone works on the principle  
that things aren't active until you've installed something in the site.  
For example, I may have two Plone sites in the same Zope instance. If I  
want to install a product that uses an adapter registration to override  
something in one site, but not the other, global adapter registrations  
don't work.


I can imagine this going further, so that for a specific content type I  
need a more specific override for that adapter that can't be tied to an  
interface only (e.g. in MyCrazyFolder the adapter for IDocument is  
different than it is for IDocument everywhere else).


Martin

--
(muted)

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users