30.3. PYRAMID INTROSPECTION CATEGORIES
renderer
The pyramid.interfaces.IRendererInfo object which represents this template’s renderer.
view mapper
Each introspectable in the permissions category represents a call to pyramid.config.Configurator.add_view() that has an explicit mapper argument to or a call to pyramid.config.Configurator.set_view_mapper(); each will have the following data.
mapper
The (resolved) mapper argument passed to add_view or set_view_mapper.
asset overrides
Each introspectable in the asset overrides category represents a call to pyramid.config.Configurator.override_asset(); each will have the following data.
to_override
The to_override argument (an asset spec) passed to override_asset.
override_with
The override_with argument (an asset spec) passed to override_asset.
translation directories |
|
|
|
|
|
|
|
Each |
introspectable |
in |
the |
asset overrides |
category |
|
repre- |
sents |
an individual element in a specs argument passed |
to to |
pyramid.config.Configurator.add_translation_dirs(); |
each |
will |
have the following data. |
|
|
|
|
|
|
|
directory
The absolute path of the translation directory.
spec
30. PYRAMID CONFIGURATION INTROSPECTION
The asset specification passed to add_translation_dirs.
tweens
Each introspectable in the tweens category represents a call to pyramid.config.Configurator.add_tween(); each will have the following data.
name
The dotted name to the tween factory as a string (passed as the tween_factory argument to add_tween).
factory
The (resolved) tween factory object.
type
implict or explicit as a string.
under
The under argument passed to add_tween (a string).
over
The over argument passed to add_tween (a string).
static views
Each introspectable in the static views category represents a call to pyramid.config.Configurator.add_static_view(); each will have the following data.
name
The name argument provided to add_static_view.
spec
A normalized version of the spec argument provided to add_static_view.
traversers
30.3. PYRAMID INTROSPECTION CATEGORIES
Each introspectable in the traversers category represents a call to pyramid.config.Configurator.add_traverser(); each will have the following data.
iface
The (resolved) interface or class object that represents the return value of a root factory that this traverser will be used for.
adapter
The (resolved) traverser class.
resource url adapters
Each introspectable in the resource url adapters category represents a call to pyramid.config.Configurator.add_resource_url_adapter(); each will have the following data.
adapter
The (resolved) resource URL adapter class.
resource_iface
The (resolved) interface or class object that represents the resource interface that this url adapter is registered for.
request_iface
The (resolved) interface or class object that represents the request interface that this url adapter is registered for.
30. PYRAMID CONFIGURATION INTROSPECTION
30.4 Introspection in the Toolbar
The Pyramid debug toolbar (part of the pyramid_debugtoolbar package) provides a canned view of all registered introspectables and their relationships. It looks something like this:
30.5 Disabling Introspection
You can disable Pyramid introspection by passing the flag introspection=False to the Configurator constructor in your application setup:
from pyramid.config import Configurator
config = Configurator(..., introspection=False)
When introspection is False, all introspectables generated by configuration directives are thrown away.
CHAPTER
THIRTYONE
EXTENDING AN EXISTING
PYRAMID APPLICATION
If a Pyramid developer has obeyed certain constraints while building an application, a third party should be able to change the application’s behavior without needing to modify its source code. The behavior of a Pyramid application that obeys certain constraints can be overridden or extended without modification.
We’ll define some jargon here for the benefit of identifying the parties involved in such an effort.
Developer The original application developer.
Integrator Another developer who wishes to reuse the application written by the original application developer in an unanticipated context. He may also wish to modify the original application without changing the original application’s source code.
31.1The Difference Between “Extensible” and “Pluggable” Applications
Other web frameworks, such as Django, advertise that they allow developers to create “pluggable applications”. They claim that if you create an application in a certain way, it will be integratable in a sensible, structured way into another arbitrarily-written application or project created by a third-party developer.
Pyramid, as a platform, does not claim to provide such a feature. The platform provides no guarantee that you can create an application and package it up such that an arbitrary integrator can use it as a subcomponent in a larger Pyramid application or project. Pyramid does not mandate the constraints necessary
31. EXTENDING AN EXISTING PYRAMID APPLICATION
for such a pattern to work satisfactorily. Because Pyramid is not very “opinionated”, developers are able to use wildly different patterns and technologies to build an application. A given Pyramid application may happen to be reusable by a particular third party integrator, because the integrator and the original developer may share similar base technology choices (such as the use of a particular relational database or ORM). But the same application may not be reusable by a different developer, because he has made different technology choices which are incompatible with the original developer’s.
As a result, the concept of a “pluggable application” is left to layers built above Pyramid, such as a “CMS” layer or “application server” layer. Such layers are apt to provide the necessary “opinions” (such as mandating a storage layer, a templating system, and a structured, well-documented pattern of registering that certain URLs map to certain bits of code) which makes the concept of a “pluggable application” possible. “Pluggable applications”, thus, should not plug in to Pyramid itself but should instead plug into a system written atop Pyramid.
Although it does not provide for “pluggable applications”, Pyramid does provide a rich set of mechanisms which allows for the extension of a single existing application. Such features can be used by frameworks built using Pyramid as a base. All Pyramid applications may not be pluggable, but all Pyramid applications are extensible.
31.2 Rules for Building An Extensible Application
There is only one rule you need to obey if you want to build a maximally extensible Pyramid application: as a developer, you should factor any overrideable imperative configuration you’ve created into functions which can be used via pyramid.config.Configurator.include() rather than inlined as calls to methods of a Configurator within the main function in your application’s __init__.py. For example, rather than:
from pyramid.config import Configurator
if __name__ == ’__main__’: config = Configurator()
config.add_view(’myapp.views.view1’, name=’view1’) config.add_view(’myapp.views.view2’, name=’view2’)
You should do move the calls to add_view outside of the (non-reusable) if __name__ == ’__main__’ block, and into a reusable function:
from pyramid.config import Configurator
if __name__ == ’__main__’: