Zope Component Architecture

This package, together with zope.interface, provides facilities for defining, registering and looking up components. There are two basic kinds of components: adapters and utilities.

Utilities

Utilities are just components that provide an interface and that are looked up by an interface and a name. Let’s look at a trivial utility definition:

We can register an instance this class using provideUtility [1]:

In this example we registered the utility as providing the IGreeter interface with a name of ‘bob’. We can look the interface up with either queryUtility or getUtility:

queryUtility and getUtility differ in how failed lookups are handled:

If a component provides only one interface, as in the example above, then we can omit the provided interface from the call to provideUtility:

The name defaults to an empty string:

Adapters

Adapters are components that are computed from other components to adapt them to some interface. Because they are computed from other objects, they are provided as factories, usually classes. Here, we’ll create a greeter for persons, so we can provide personalized greetings for different people:

The class defines a constructor that takes an argument for every object adapted.

We used component.adapts to declare what we adapt. We can find out if an object declares that it adapts anything using adaptedBy:

If an object makes no declaration, then None is returned:

If we declare the interfaces adapted and if we provide only one interface, as in the example above, then we can provide the adapter very simply [1]:

For adapters that adapt a single interface to a single interface without a name, we can get the adapter by simply calling the interface:

We can also provide arguments to be very specific about what how to register the adapter.

The arguments can also be provided as keyword arguments:

For named adapters, use queryAdapter, or getAdapter:

If an adapter can’t be found, queryAdapter returns a default value and getAdapter raises an error:

Adapters can adapt multiple objects:

Note that the declaration-order of the Interfaces beeing adapted to is important for adapter look up. It must be the the same as the order of parameters given to the adapter and used to query the adapter. This is especially the case when different Interfaces are adapt to (opposed to this example).

To look up a multi-adapter, use either queryMultiAdapter or getMultiAdapter:

Adapters need not be classes. Any callable will do. We use the adapter decorator to declare that a callable object adapts some interfaces (or classes):

In this example, the personJob function simply returns the person’s job attribute if present, or None if it’s not present. An adapter factory can return None to indicate that adaptation wasn’t possible. Let’s register this adapter and try it out:

The adaptation failed because sally didn’t have a job. Let’s give her one:

Subscription Adapters

Unlike regular adapters, subscription adapters are used when we want all of the adapters that adapt an object to a particular adapter.

Consider a validation problem. We have objects and we want to assess whether they meet some sort of standards. We define a validation interface:

Perhaps we have documents:

Now, we may want to specify various validation rules for documents. For example, we might require that the summary be a single line:

Or we might require the body to be at least 1000 characters in length:

We can register these as subscription adapters [1]:

We can then use the subscribers to validate objects:

Handlers

Handlers are subscription adapter factories that don’t produce anything. They do all of their work when called. Handlers are typically used to handle events.

Event subscribers are different from other subscription adapters in that the caller of event subscribers doesn’t expect to interact with them in any direct way. For example, an event publisher doesn’t expect to get any return value. Because subscribers don’t need to provide an API to their callers, it is more natural to define them with functions, rather than classes. For example, in a document-management system, we might want to record creation times for documents:

In this example, we have a function that takes an event and performs some processing. It doesn’t actually return anything. This is a special case of a subscription adapter that adapts an event to nothing. All of the work is done when the adapter “factory” is called. We call subscribers that don’t actually create anything “handlers”. There are special APIs for registering and calling them.

To register the subscriber above, we define a document-created event:

We’ll also change our handler definition to:

This marks the handler as an adapter of IDocumentCreated events.

Now we’ll register the handler [1]:

Now, if we can create an event and use the handle function to call handlers registered for the event:

[1]	(1, 2, 3, 4) CAUTION: This API should only be used from test or application-setup code. This API shouldn’t be used by regular library modules, as component registration is a configuration activity.