# Declarative Configuration using ZCML¶

The mode of configuration detailed in the examples within the Pyramid documentation is “imperative” configuration. This is the configuration mode in which a developer cedes the least amount of control to the framework; it’s “imperative” because you express the configuration directly in Python code, and you have the full power of Python at your disposal as you issue configuration statements. However, another mode of configuration exists For Pyramid within pyramid_zcml named ZCML which is declarative. In ZCML, configuration statements are made via an domain specific language implemented in XML. There is no opportunity for conditionals or loops. Declarative languages are less powerful than their imperative counterparts; this is attractive in environments where consistency is more important than brevity.

A complete listing of ZCML directives is available within ZCML Directives. This chapter provides an overview of how you might get started with ZCML and highlights some common tasks performed when you use ZCML.

## ZCML Configuration¶

A Pyramid application can be configured “declaratively”, if so desired. Declarative configuration relies on declarations made external to the code in a configuration file format named ZCML (Zope Configuration Markup Language), an XML dialect.

A Pyramid application configured declaratively requires not one, but two files: a Python file and a ZCML file.

In a file named helloworld.py:

  1 2 3 4 5 6 7 8 9 10 11 12 13 from paste.httpserver import serve from pyramid.response import Response from pyramid.config import Configurator def hello_world(request): return Response('Hello world!') if __name__ == '__main__': config = Configurator() config.include('pyramid_zcml') config.load_zcml('configure.zcml') app = config.make_wsgi_app() serve(app, host='0.0.0.0') 

In a file named configure.zcml in the same directory as the previously created helloworld.py:

 1 2 3 4 5 6 7 8 9  

This pair of files forms an application functionally equivalent to the application we created earlier in Imperative Configuration. Let’s examine the differences between that code listing and the code above.

In Imperative Configuration, we had the following lines within the if __name__ == '__main__' section of helloworld.py:

 1 2 3 4 5 if __name__ == '__main__': config = Configurator() config.add_view(hello_world) app = config.make_wsgi_app() serve(app, host='0.0.0.0') 

In our “declarative” code, we’ve removed the call to add_view and replaced it with a call to the pyramid_zcml.load_zcml() method so that it now reads as:

 1 2 3 4 5 6 if __name__ == '__main__': config = Configurator() config.include('pyramid_zcml') config.load_zcml('configure.zcml') app = config.make_wsgi_app() serve(app, host='0.0.0.0') 

Everything else is much the same.

The config.include('pyramid_zcml') line makes the load_zcml method available on the configurator. The config.load_zcml('configure.zcml') line tells the configurator to load configuration declarations from the file named configure.zcml which sits next to helloworld.py on the filesystem. Let’s take a look at that configure.zcml file again:

 1 2 3 4 5 6 7 8 9  

Note that this file contains some XML, and that the XML contains a <view> configuration declaration tag that references a dotted Python name. This dotted name refers to the hello_world function that lives in our helloworld Python module.

This <view> declaration tag performs the same function as the add_view method that was employed within Imperative Configuration. In fact, the <view> tag is effectively a “macro” which calls the pyramid.config.Configurator.add_view() method on your behalf.

The <view> tag is an example of a Pyramid declaration tag. Other such tags include <route> and <scan>. Each of these tags is effectively a “macro” which calls methods of a pyramid.config.Configurator object on your behalf.

Essentially, using a ZCML file and loading it from the filesystem allows us to put our configuration statements within this XML file rather as declarations, rather than representing them as method calls to a Configurator object. Otherwise, declarative and imperative configuration are functionally equivalent.

Using declarative configuration has a number of benefits, the primary benefit being that applications configured declaratively can be overridden and extended by third parties without requiring the third party to change application code. If you want to build a framework or an extensible application, using declarative configuration is a good idea.

Declarative configuration has an obvious downside: you can’t use plain-old-Python syntax you probably already know and understand to configure your application; instead you need to use ZCML.

### ZCML Conflict Detection¶

A minor additional feature of ZCML is conflict detection. If you define two declaration tags within the same ZCML file which logically “collide”, an exception will be raised, and the application will not start. For example, the following ZCML file has two conflicting <view> tags:

  1 2 3 4 5 6 7 8 9 10 11 12 13  

If you try to use this ZCML file as the source of ZCML for an application, an error will be raised when you attempt to start the application. This error will contain information about which tags might have conflicted.

## Hello World, Goodbye World (Declarative)¶

Another almost entirely equivalent mode of application configuration exists named declarative configuration. Pyramid can be configured for the same “hello world” application “declaratively”, if so desired.

To do so, first, create a file named helloworld.py:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 from pyramid.config import Configurator from pyramid.response import Response from paste.httpserver import serve def hello_world(request): return Response('Hello world!') def goodbye_world(request): return Response('Goodbye world!') if __name__ == '__main__': config = Configurator() config.include('pyramid_zcml') config.load_zcml('configure.zcml') app = config.make_wsgi_app() serve(app, host='0.0.0.0') 

Then create a file named configure.zcml in the same directory as the previously created helloworld.py:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14  

This pair of files forms an application functionally equivalent to the application we created earlier in Hello World. We can run it the same way.

\$ python helloworld.py
serving on 0.0.0.0:8080 view at http://127.0.0.1:8080


Let’s examine the differences between the code in that section and the code above. In Application Configuration, we had the following lines within the if __name__ == '__main__' section of helloworld.py:

 1 2 3 4 5 6 if __name__ == '__main__': config = Configurator() config.add_view(hello_world) config.add_view(goodbye_world, name='goodbye') app = config.make_wsgi_app() serve(app, host='0.0.0.0') 

In our “declarative” code, we’ve added a call to the pyramid_zcml.load_zcml() method with the value configure.zcml, and we’ve removed the lines which read config.add_view(hello_world) and config.add_view(goodbye_world, name='goodbye'), so that it now reads as:

 1 2 3 4 5 6 if __name__ == '__main__': config = Configurator() config.include('pyramid_zcml') config.load_zcml('configure.zcml') app = config.make_wsgi_app() serve(app, host='0.0.0.0') 

Everything else is much the same.

The config.load_zcml('configure.zcml') line tells the configurator to load configuration declarations from the configure.zcml file which sits next to helloworld.py. Let’s take a look at the configure.zcml file now:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14  

We already understand what the view code does, because the application is functionally equivalent to the application described in Hello World, but use of ZCML is new. Let’s break that down tag-by-tag.

### The <configure> Tag¶

The configure.zcml ZCML file contains this bit of XML:

 1 2 3 4 5  

Because ZCML is XML, and because XML requires a single root tag for each document, every ZCML file used by Pyramid must contain a configure container directive, which acts as the root XML tag. It is a “container” directive because its only job is to contain other directives.

### The <include> Tag¶

The configure.zcml ZCML file contains this bit of XML within the <configure> root tag:

 1  

This self-closing tag instructs Pyramid to load a ZCML file from the Python package with the dotted Python name pyramid_zcml, as specified by its package attribute. This particular <include> declaration is required because it actually allows subsequent declaration tags (such as <view>, which we’ll see shortly) to be recognized. The <include> tag effectively just includes another ZCML file, causing its declarations to be executed. In this case, we want to load the declarations from the file named configure.zcml within the pyramid_zcml Python package. We know we want to load the configure.zcml from this package because configure.zcml is the default value for another attribute of the <include> tag named file. We could have spelled the include tag more verbosely, but equivalently as:

 1 2  

The <include> tag that includes the ZCML statements implied by the configure.zcml file from the Python package named pyramid_zcml is basically required to come before any other named declaration in an application’s configure.zcml. If it is not included, subsequent declaration tags will fail to be recognized, and the configuration system will generate an error at startup. However, the <include package="pyramid_zcml"/> tag needs to exist only in a “top-level” ZCML file, it needn’t also exist in ZCML files included by a top-level ZCML file.

### The <view> Tag¶

The configure.zcml ZCML file contains these bits of XML after the <include> tag, but within the <configure> root tag:

 1 2 3 4 5 6 7 8  

These <view> declaration tags direct Pyramid to create two view configuration registrations. The first <view> tag has an attribute (the attribute is also named view), which points at a dotted Python name, referencing the hello_world function defined within the helloworld package. The second <view> tag has a view attribute which points at a dotted Python name, referencing the goodbye_world function defined within the helloworld package. The second <view> tag also has an attribute called name with a value of goodbye.

These effect of the <view> tag declarations we’ve put into our configure.zcml is functionally equivalent to the effect of lines we’ve already seen in an imperatively-configured application. We’re just spelling things differently, using XML instead of Python.

In our previously defined application, in which we added view configurations imperatively, we saw this code:

 1 2 config.add_view(hello_world) config.add_view(goodbye_world, name='goodbye') 

Each <view> declaration tag encountered in a ZCML file effectively invokes the pyramid.config.Configurator.add_view() method on the behalf of the developer. Various attributes can be specified on the <view> tag which influence the view configuration it creates.

Since the relative ordering of calls to pyramid.config.Configurator.add_view() doesn’t matter (see the sidebar entitled View Dispatch and Ordering within Adding Configuration), the relative order of <view> tags in ZCML doesn’t matter either. The following ZCML orderings are completely equivalent:

Hello Before Goodbye

 1 2 3 4 5 6 7 8  

Goodbye Before Hello

 1 2 3 4 5 6 7 8  

### ZCML Granularity¶

It’s extremely helpful to third party application “extenders” (aka “integrators”) if the ZCML that composes the configuration for an application is broken up into separate files which do very specific things. These more specific ZCML files can be reintegrated within the application’s main configure.zcml via <include file="otherfile.zcml"/> declarations. When ZCML files contain sets of specific declarations, an integrator can avoid including any ZCML he does not want by including only ZCML files which contain the declarations he needs. He is not forced to “accept everything” or “use nothing”.

For example, it’s often useful to put all <route> declarations in a separate ZCML file, as <route> statements have a relative ordering that is extremely important to the application: if an extender wants to add a route to the “middle” of the routing table, he will always need to disuse all the routes and cut and paste the routing configuration into his own application. It’s useful for the extender to be able to disuse just a single ZCML file in this case, accepting the remainder of the configuration from other ZCML files in the original application.

Granularizing ZCML is not strictly required. An extender can always disuse all your ZCML, choosing instead to copy and paste it into his own package, if necessary. However, doing so is considerate, and allows for the best reusability. Sometimes it’s possible to include only certain ZCML files from an application that contain only the registrations you really need, omitting others. But sometimes it’s not. For brute force purposes, when you’re getting view or route registrations that you don’t actually want in your overridden application, it’s always appropriate to just not include any ZCML file from the overridden application. Instead, just cut and paste the entire contents of the configure.zcml (and any ZCML file included by the overridden application’s configure.zcml) into your own package and omit the <include package=""/> ZCML declaration in the overriding package’s configure.zcml.

## Scanning via ZCML¶

ZCML can invoke a scan via its <scan> directive. If a ZCML file is processed that contains a scan directive, the package the ZCML file points to is scanned.

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # helloworld.py from paste.httpserver import serve from pyramid.response import Response from pyramid.view import view_config @view_config() def hello(request): return Response('Hello') if __name__ == '__main__': from pyramid.config import Configurator config = Configurator() config.include('pyramid_zcml') config.load_zcml('configure.zcml') app = config.make_wsgi_app() serve(app, host='0.0.0.0') 
 1 2 3 4 5 6 7 8  

## Which Mode Should I Use?¶

A combination of imperative configuration, declarative configuration via ZCML and scanning can be used to configure any application. They are not mutually exclusive.

Declarative configuraton was the more traditional form of configuration used in Pyramid applications; the first releases of Pyramid and all releases of Pyramid’s predecessor named repoze.bfg included ZCML in the core. However, by virtue of this package, it has been externalized from the Pyramid core because it has proven that imperative mode configuration can be simpler to understand and document.

However, you can choose to use imperative configuration, or declarative configuration via ZCML. Use the mode that best fits your brain as necessary.

### View Configuration Via ZCML¶

You may associate a view with a URL by adding view declarations via ZCML in a configure.zcml file. An example of a view declaration in ZCML is as follows:

 1 2 3 4 5  

The above maps the .views.hello_world view callable function to the following set of resource location results:

• A context object which is an instance (or subclass) of the Python class represented by .resources.Hello
• A view name equalling hello.html.

Note

Values prefixed with a period (.) for the context and view attributes of a view declaration (such as those above) mean “relative to the Python package directory in which this ZCML file is stored”. So if the above view declaration was made inside a configure.zcml file that lived in the hello package, you could replace the relative .resources.Hello with the absolute hello.resources.Hello; likewise you could replace the relative .views.hello_world with the absolute hello.views.hello_world. Either the relative or absolute form is functionally equivalent. It’s often useful to use the relative form, in case your package’s name changes. It’s also shorter to type.

You can also declare a default view callable for a resource type:

 1 2 3 4  

A default view callable simply has no name attribute. For the above registration, when a context is found that is of the type .resources.Hello and there is no view name associated with the result of resource location, the default view callable will be used. In this case, it’s the view at .views.hello_world.

A default view callable can alternately be defined by using the empty string as its name attribute:

 1 2 3 4 5  

You may also declare that a view callable is good for any context type by using the special * character as the value of the context attribute:

 1 2 3 4 5  

This indicates that when Pyramid identifies that the view name is hello.html and the context is of any type, the .views.hello_world view callable will be invoked.

A ZCML view declaration’s view attribute can also name a class. In this case, the rules described in Defining a View Callable as a Class apply for the class which is named.

See view for complete ZCML directive documentation.

## Configuring a Route via ZCML¶

Instead of using the imperative pyramid.config.Configurator.add_route() method to add a new route, you can alternately use ZCML. route statements in a ZCML file. For example, the following ZCML declaration causes a route to be added to the application.

 1 2 3 4 5  

Note

Values prefixed with a period (.) within the values of ZCML attributes such as the view attribute of a route mean “relative to the Python package directory in which this ZCML file is stored”. So if the above route declaration was made inside a configure.zcml file that lived in the hello package, you could replace the relative .views.myview with the absolute hello.views.myview Either the relative or absolute form is functionally equivalent. It’s often useful to use the relative form, in case your package’s name changes. It’s also shorter to type.

The order that routes are evaluated when declarative configuration is used is the order that they appear relative to each other in the ZCML file.

See route for full route ZCML directive documentation.

## Serving Static Assets Using ZCML¶

Use of the static ZCML directive makes static assets available at a name relative to the application root URL, e.g. /static.

Note that the path provided to the static ZCML directive may be a fully qualified asset specification, a package-relative path, or an absolute path. The path with the value a/b/c/static of a static directive in a ZCML file that resides in the “mypackage” package will resolve to a package-qualified assets such as some_package:a/b/c/static.

Here’s an example of a static ZCML directive that will serve files up under the /static URL from the /var/www/static directory of the computer which runs the Pyramid application using an absolute path.

 1 2 3 4  

Here’s an example of a static directive that will serve files up under the /static URL from the a/b/c/static directory of the Python package named some_package using a fully qualified asset specification.

 1 2 3 4  

Here’s an example of a static directive that will serve files up under the /static URL from the static directory of the Python package in which the configure.zcml file lives using a package-relative path.

 1 2 3 4  

Whether you use for path a fully qualified asset specification, an absolute path, or a package-relative path, When you place your static files on the filesystem in the directory represented as the path of the directive, you will then be able to view the static files in this directory via a browser at URLs prefixed with the directive’s name. For instance if the static directive’s name is static and the static directive’s path is /path/to/static, http://localhost:6543/static/foo.js will return the file /path/to/static/dir/foo.js. The static directory may contain subdirectories recursively, and any subdirectories may hold files; these will be resolved by the static view as you would expect.

While the path argument can be a number of different things, the name argument of the static ZCML directive can also be one of a number of things: a view name or a URL. The above examples have shown usage of the name argument as a view name. When name is a URL (or any string with a slash (/) in it), static assets can be served from an external webserver. In this mode, the name is used as the URL prefix when generating a URL using pyramid.url.static_url().

For example, the static ZCML directive may be fed a name argument which is http://example.com/images:

 1 2 3 4  

Because the static ZCML directive is provided with a name argument that is the URL prefix http://example.com/images, subsequent calls to pyramid.url.static_url() with paths that start with the path argument passed to pyramid.url.static_url() will generate a URL something like http://example.com/logo.png. The external webserver listening on example.com must be itself configured to respond properly to such a request. The pyramid.url.static_url() API is discussed in more detail later in this chapter.

The pyramid.config.Configurator.add_static_view() method offers an imperative equivalent to the static ZCML directive. Use of the add_static_view imperative configuration method is completely equivalent to using ZCML for the same purpose. See Serving Static Assets for more information.

### The asset ZCML Directive¶

Instead of using pyramid.config.Configurator.override_asset() during imperative configuration, an equivalent ZCML directive can be used. The ZCML asset tag is a frontend to using pyramid.config.Configurator.override_asset().

An individual Pyramid asset ZCML statement can override a single asset. For example:

 1 2 3 4  

The string value passed to both to_override and override_with attached to an asset directive is called an “asset specification”. The colon separator in a specification separates the package name from the asset name. The colon and the following asset name are optional. If they are not specified, the override attempts to resolve every lookup into a package from the directory of another package. For example:

 1 2 3 4  

Individual subdirectories within a package can also be overridden:

 1 2 3 4  

If you wish to override an asset directory with another directory, you must make sure to attach the slash to the end of both the to_override specification and the override_with specification. If you fail to attach a slash to the end of an asset specification that points to a directory, you will get unexpected results.

The package name in an asset specification may start with a dot, meaning that the package is relative to the package in which the ZCML file resides. For example:

 1 2 3 4  

## Enabling an Authorization Policy Via ZCML¶

If you’d rather use ZCML to specify an authorization policy than imperative configuration, modify the ZCML file loaded by your application (usually named configure.zcml) to enable an authorization policy.

For example, to enable a policy which compares the value of an “auth ticket” cookie passed in the request’s environment which contains a reference to a single principal against the principals present in any ACL found in the resource tree when attempting to call some view, modify your configure.zcml to look something like this:

  1 2 3 4 5 6 7 8 9 10  

“Under the hood”, these statements cause an instance of the class pyramid.authentication.AuthTktAuthenticationPolicy to be injected as the authentication policy used by this application and an instance of the class pyramid.authorization.ACLAuthorizationPolicy to be injected as the authorization policy used by this application.

Pyramid ships with a number of authorization and authentication policy ZCML directives that should prove useful. See Built-In Authentication Policy ZCML Directives and Built-In Authorization Policy ZCML Directives for more information.

## Built-In Authentication Policy ZCML Directives¶

Instead of configuring an authentication policy and authorization policy imperatively, Pyramid ships with a few “pre-chewed” authentication policy ZCML directives that you can make use of within your application.

### authtktauthenticationpolicy¶

When this directive is used, authentication information is obtained from an “auth ticket” cookie value, assumed to be set by a custom login form.

An example of its usage, with all attributes fully expanded:

  1 2 3 4 5 6 7 8 9 10 11 12  

### remoteuserauthenticationpolicy¶

When this directive is used, authentication information is obtained from a REMOTE_USER key in the WSGI environment, assumed to be set by a WSGI server or an upstream middleware component.

An example of its usage, with all attributes fully expanded:

 1 2 3 4  

See remoteuserauthenticationpolicy for detailed information.

### repozewho1authenticationpolicy¶

When this directive is used, authentication information is obtained from a repoze.who.identity key in the WSGI environment, assumed to be set by repoze.who middleware.

An example of its usage, with all attributes fully expanded:

 1 2 3 4  

See repozewho1authenticationpolicy for detailed information.

## Built-In Authorization Policy ZCML Directives¶

aclauthorizationpolicy

When this directive is used, authorization information is obtained from ACL objects attached to resources.

An example of its usage, with all attributes fully expanded:

 1  

In other words, it has no configuration attributes; its existence in a configure.zcml file enables it.

See aclauthorizationpolicy for detailed information.

## Adding and Changing Renderers via ZCML¶

New templating systems and serializers can be associated with Pyramid renderer names. To this end, configuration declarations can be made which change an existing renderer factory and which add a new renderer factory.

Adding or changing an existing renderer via ZCML is accomplished via the renderer ZCML directive.

For example, to add a renderer which renders views which have a renderer attribute that is a path that ends in .jinja2:

 1 2 3 4  

The factory attribute is a dotted Python name that must point to an implementation of a renderer factory.

The name attribute is the renderer name.

### Registering a Renderer Factory¶

See Adding a New Renderer for more information for the definition of a renderer factory. Here’s an example of the registration of a simple renderer factory via ZCML:

 1 2 3 4  

Adding the above ZCML to your application will allow you to use the my.package.MyAMFRenderer renderer factory implementation in view configurations by subseqently referring to it as amf in the renderer attribute of a view configuration:

 1 2 3 4  

Here’s an example of the registration of a more complicated renderer factory, which expects to be passed a filesystem path:

 1 2 3 4  

Adding the above ZCML to your application will allow you to use the my.package.MyJinja2Renderer renderer factory implementation in view configurations by referring to any renderer which ends in .jinja in the renderer attribute of a view configuration:

 1 2 3 4  

When a view configuration which has a name attribute that does contain a dot, such as templates/mytemplate.jinja2 above is encountered at startup time, the value of the name attribute is split on its final dot. The second element of the split is typically the filename extension. This extension is used to look up a renderer factory for the configured view. Then the value of renderer is passed to the factory to create a renderer for the view. In this case, the view configuration will create an instance of a Jinja2Renderer for each view configuration which includes anything ending with .jinja2 as its renderer value. The name passed to the Jinja2Renderer constructor will be whatever the user passed as renderer= to the view configuration.

### Changing an Existing Renderer¶

You can associate more than one filename extension with the same existing renderer implementation as necessary if you need to use a different file extension for the same kinds of templates. For example, to associate the .zpt extension with the Chameleon ZPT renderer factory, use:

 1 2 3 4  

After you do this, Pyramid will treat templates ending in both the .pt and .zpt filename extensions as Chameleon ZPT templates.

To change the default mapping in which files with a .pt extension are rendered via a Chameleon ZPT page template renderer, use a variation on the following in your application’s ZCML:

 1 2 3 4  

After you do this, the renderer factory in my.package.pt_renderer will be used to render templates which end in .pt, replacing the default Chameleon ZPT renderer.

To ochange the default mapping in which files with a .txt extension are rendered via a Chameleon text template renderer, use a variation on the following in your application’s ZCML:

 1 2 3 4  

After you do this, the renderer factory in my.package.text_renderer will be used to render templates which end in .txt, replacing the default Chameleon text renderer.

To associate a default renderer with all view configurations (even ones which do not possess a renderer attribute), use a variation on the following (ie. omit the name attribute to the renderer tag):

 1 2 3  

## Adding a Translation Directory via ZCML¶

You can add a translation directory via ZCML by using the translationdir ZCML directive:

 1  

A message catalog in a translation directory added via translationdir will be merged into translations from a message catalog added earlier if both translation directories contain translations for the same locale and translation domain.

## Adding a Custom Locale Negotiator via ZCML¶

You can add a custom locale negotiator via ZCML by using the localenegotiator ZCML directive:

 1 2 3  

## Configuring an Event Listener via ZCML¶

You can configure an subscriber by modifying your application’s configure.zcml. Here’s an example of a bit of XML you can add to the configure.zcml file which registers the above mysubscriber function, which we assume lives in a subscribers.py module within your application:

 1 2 3 4  

If your application uses ZCML, you can replace the Not Found view by placing something like the following ZCML in your configure.zcml file.

 1 2 3 4  

Replace helloworld.views.notfound_view with the Python dotted name to the notfound view you want to use.

## Configuring a Forbidden View via ZCML¶

If your application uses ZCML, you can replace the Forbidden view by placing something like the following ZCML in your configure.zcml file.

 1 2 3 4  

Replace helloworld.views.forbidden_view with the Python dotted name to the forbidden view you want to use.

## Configuring an Alternate Traverser via ZCML¶

Use an adapter stanza in your application’s configure.zcml to change the default traverser:

 1 2 3 4 5  

Or to register a traverser for a specific resource type:

 1 2 3 4 5  

## Using features to make ZCML configurable¶

Using features you can make ZCML somewhat configurable. That is, you can exclude or include parts of a ZCML configuration using the features argument to pyramid_zcml.load_zcml(). For example:

 1 config.load_zcml('configure.zcml', features=['my_feature']) 

With this ZCML file:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22  

Will configure the views always_configured and alternate_hello_world but NOT hello_world.

## Changing resource_url URL Generation via ZCML¶

You can change how pyramid.url.resource_url() generates a URL for a specific type of resource by adding an adapter statement to your configure.zcml.

 1 2 3 4 5  

## Changing the Request Factory via ZCML¶

A MyRequest class can be registered via ZCML as a request factory through the use of the ZCML utility directive. In the below, we assume it lives in a package named mypackage.mymodule.

 1 2 3 4  

## Changing the Renderer Globals Factory via ZCML¶

A renderer globals factory can be registered via ZCML as a through the use of the ZCML utility directive. In the below, we assume a renderers_globals_factory function lives in a package named mypackage.mymodule.

 1 2 3 4  

Some Zope and third-party ZCML directives use the zope.component.getGlobalSiteManager API to get “the registry” when they should actually be calling zope.component.getSiteManager.
zope.component.getSiteManager can be overridden by Pyramid via pyramid.config.Configurator.hook_zca(), while zope.component.getGlobalSiteManager cannot. Directives that use zope.component.getGlobalSiteManager are effectively broken; no ZCML directive should be using this function to find a registry to populate.
You cannot use ZCML directives which use zope.component.getGlobalSiteManager within a Pyramid application without passing the ZCA global registry to the Configurator constructor at application startup, as per Enabling the ZCA global API by using the ZCA global registry.
One alternative exists: fix the ZCML directive to use getSiteManager rather than getGlobalSiteManager. If a directive disuses getGlobalSiteManager, the hook_zca method of using a component registry as documented in Enabling the ZCA global API by using hook_zca will begin to work, allowing you to make use of the ZCML directive without also using the ZCA global registry.