[Zope3-dev] Re: Heads up: Adapter registry api restructuring

Jim Fulton jim at zope.com
Thu Mar 18 07:46:23 EST 2004


This work is done.  I ended up with a slightly different interface.
See zope.interface.interfaces.

Also note that I decided *not* to manage utilities in the adapter service.
Rather, you can define adapters that adapt no objects. These are objects
that are created when you do something like:

    queryMultiAdapter((), IFoo)

a factory is called with no arguments to create a new object.
This is different than:

    queryUtiltity(self, IFoo)

which always returns the same object.

I decided to do it this way for two reasons:

1. To have consistent semantics: getting an adapter
    always creates a new object. (Registering adapter
    always registers a factory)

2. This provides a way to register a factory according to
    the interface of the things it creates.

    So, for example, Sidnei could register the various Field
    classes as named IField adapters requireing no interfaces
    and then use queryMultiAdapter to look them up.

BTW, note that queryMultiAdapter is the most general form of adapter
lookup.  It handles adapters with 0, 1, or multiple required
specifications. It handles named or unnamed (name='') adapters.

Jim

Jim Fulton wrote:
> 
> The API adapter registry, used by the adapter and other services is
> going through some restructuring. This will mainly affect the adapter
> service and those other few bits of application that use this registry.
> 
> This registry was recently known as the surrogate registry. I never defined
> an interface for this thing. Here's one that I plan to change the 
> implementation
> to conform to:
> 
> 
> class IAdapterRegistry(Interface):
>     """Provide an interface-based registry for adapters
> 
>     This registry registers objects that are in some sense "from" a
>     sequence of specification to an interface and a name.
> 
>     No specific semantics are assumed for the registered objects,
>     however, the most common application will be to register factories
>     that adapt objects providing required specifications to a provided
>     interface.
> 
>     """
> 
>     def register(required, provided, name, value):
>         """Register a value
> 
>         A value is registered for a *sequence* of required 
> specifications, a
>         provided interface, and a name.
>         """
> 
>     def lookup(required, provided, name, default=None):
>         """Lookup a value
> 
>         A value is looked up based on a *sequence* of required
>         specifications, a provided interface, and a name.
>         """
> 
>     def subscribe(required, provided, name, subscriber):
>         """Register a subscriber
> 
>         A subscriber is registered for a *sequence* of required
>         specifications, a provided interface, and a name.
> 
>         Multiple subscribers may be registered for the same (or
>         equivalent) interfaces.
>         """
> 
>     def subscribers(required, provided, name):
>         """Get a sequence of subscribers
> 
>         Subscribers for a *sequence* of required interfaces, a provided
>         interface, and a name are returned.
>         """
> 
> This change represents a shift of some responsibilities out of
> the registry.  In particular:
> 
> - In the special case of a single object being adapter, the registry
>   does not consider whether the object provides the desired interface.
>   This is already the case for the adapter register.
> 
> - The registry no longer tries to call the registered values. In other
>   words, there is no special factory interpretation given to the registered
>   objects. That's the job of the service using the registry.
> 
> Note that the required argument can be an empty tuple.  Yes, this
> unifies adapters and utilities at the registry level. :)
> 
> This probably spells the end of the utility service, but *not* the end
> of getUtility and queryUtility. These functions will simply use the adapter
> service.
> 
> Jim
> 


-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org




More information about the Zope3-dev mailing list