If the developer of a repoze.bfg application has obeyed certain constraints while building that application, a third party should be able to change its behavior without needing to modify its source code. The behavior of a repoze.bfg application that obeys certain constraints can be overridden or extended without modification.
There’s only one rule you need to obey if you want to build a maximally extensible repoze.bfg application: you should not use any configuration decoration or imperative configuration. This means the application developer should avoid relying on configuration decoration meant to be detected via a scan, and you mustn’t configure your repoze.bfg application imperatively by using any code which configures the application through methods of the Configurator (except for the repoze.bfg.configuration.Configurator.load_zcml() method).
Instead, you must always use ZCML for the equivalent purposes. ZCML declarations that belong to an application can be “overridden” by integrators as necessary, but decorators and imperative code which perform the same tasks cannot. Use only ZCML to configure your application if you’d like it to be extensible.
The fundamental “plug points” of an application developed using repoze.bfg are routes, views, and resources. Routes are declarations made using the ZCML <route> directive. Views are declarations made using the ZCML <view> directive (or the @bfg_view decorator). Resources are files that are accessed by repoze bfg using the pkg_resources API such as static files and templates.
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.
The steps for extending an existing application depend largely on whether the application does or does not use configuration decorators and/or imperative code.
If you’ve inherited a repoze.bfg application which uses repoze.bfg.view.bfg_view decorators or which performs configuration imperatively, one of two things may be true:
If you just want to extend the application, you can write additional ZCML that registers more views or routes, loading any existing ZCML and continuing to use any existing imperative configuration done by the original application.
If you want to override configuration in the application, you may need to change the source code of the original application.
If the only source of trouble is the existence of repoze.bfg.view.bfg_view decorators, you can just prevent a scan from happening (by omitting the <scan> declaration from ZCML or omitting any call to the repoze.bfg.configuration.Configurator.scan() method). This will cause the decorators to do nothing. At this point, you will need to convert all the configuration done in decorators into equivalent ZCML and add that ZCML to a separate Python package as described in Extending an Application Which Does Not Possess Configuration Decorators or Imperative Configuration.
If the source of trouble is configuration done imperatively in a function called during application startup, you’ll need to change the code: convert imperative configuration statements into equivalent ZCML declarations.
Once this is done, you should be able to extend or override the application like any other (see Extending an Application Which Does Not Possess Configuration Decorators or Imperative Configuration).
To extend or override the behavior of an existing application, you will need to write some ZCML, and perhaps some implementations of the types of things you’d like to override (such as views), which are referred to within that ZCML.
The general pattern for extending an existing application looks something like this:
The ZCML <view> declarations you make which override application behavior will usually have the same context and name (and predicate attributes, if used) as the original. These <view> declarations will point at “new” view code. The new view code itself will usually be cut-n-paste copies of view callables from the original application with slight tweaks. For example:
1 2 3 4
<view context="theoriginalapplication.models.SomeModel" name="theview" view=".views.a_view_that_does_something_slightly_different" />
A similar pattern can be used to extend the application with <view> declarations. Just register a new view against some existing model type and make sure the URLs it implies are available on some other page rendering.
Route setup is currently typically performed in a sequence of ordered ZCML <route> declarations. Because these declarations are ordered relative to each other, and because this ordering is typically important, you should retain the relative ordering of these declarations when performing an override. Typically, this means copying all the <route> declarations into an external ZCML file and changing them as necessary. Then disinclude any ZCML from the original application which contains the original declarations.
“Resource” files are static files on the filesystem that are accessible within a Python package. An entire chapter is devoted to resources: Resources. Within this chapter is a section named Overriding Resources. This section of that chapter describes in detail how to override package resources with other resources by using ZCML <resource> declarations. Add such <resource> declarations to your override package’s configure.zcml to perform overrides.
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.