Glossary
- application registry
- A registry of configuration information consulted by
Pyramid while servicing an application. An application
registry maps resource types to views, as well as housing other
application-specific component registrations. Every
Pyramid application has one (and only one) application
registry.
- asset
- Any file contained within a Python package which is not
a Python source code file.
- asset specification
- A colon-delimited identifier for an asset. The colon separates
a Python package name from a package subpath. For example, the
asset specification
my.package:static/baz.css
identifies the file
named baz.css
in the static
subdirectory of the my.package
Python package. See Understanding Asset Specifications for more info.
- asset specification
- A colon-delimited identifier for an asset. The colon separates
a Python package name from a package subpath. For example, the
asset specification
my.package:static/baz.css
identifies the file
named baz.css
in the static
subdirectory of the my.package
Python package. See Understanding Asset Specifications for more info.
- authentication policy
- An authentication policy in Pyramid terms is a bit of
code which has an API which determines the current
principal (or principals) associated with a request.
- authorization policy
- An authorization policy in Pyramid terms is a bit of
code which has an API which determines whether or not the
principals associated with the request can perform an action
associated with a permission, based on the information found on the
context resource.
- configuration declaration
- An individual method call made to an instance of a Pyramid
Configurator object which performs an arbitrary action, such as
registering a view configuration (via the
add_view
method of
the configurator) or route configuration (via the add_route
method of the configurator).
- configuration decoration
- Metadata implying one or more configuration declaration
invocations. Often set by configuration Python decorator
attributes, such as
pyramid.view.view_config
, aka
@view_config
.
- configurator
- An object used to do configuration declaration within an
application. The most common configurator is an instance of the
pyramid.config.Configurator
class.
- decorator
- A wrapper around a Python function or class which accepts the function
or class as its first argument and which returns an arbitrary object.
Pyramid provides several decorators, used for configuration and return
value modification purposes. See also PEP 318.
- Default Locale Name
- The locale name used by an application when no explicit
locale name is set. See Localization-Related Deployment Settings.
- default permission
- A permission which is registered as the default for an
entire application. When a default permission is in effect,
every view configuration registered with the system will
be effectively amended with a
permission
argument that will
require that the executing user possess the default permission in
order to successfully execute the associated view
callable See also Setting a Default Permission.
- Default view
- The default view of a resource is the view invoked when the
view name is the empty string (
''
). This is the case when
traversal exhausts the path elements in the PATH_INFO of a
request before it returns a context resource.
- dotted Python name
- A reference to a Python object by name using a string, in the form
path.to.modulename:attributename
. Often used in Paste and
setuptools configurations. A variant is used in dotted names
within ZCML attributes that name objects (such as the ZCML
“view” directive’s “view” attribute): the colon (:
) is not
used; in its place is a dot.
- Exception view
- An exception view is a view callable which may be
invoked by Pyramid when an exception is raised during
request processing. See Custom Exception Views for more
information.
- Forbidden view
- An exception view invoked by Pyramid when the
developer explicitly raises a
pyramid.exceptions.Forbidden
exception from within
view code or root factory code, or when the
view configuration and authorization policy
found for a request disallows a particular view invocation.
Pyramid provides a default implementation of a
forbidden view; it can be overridden. See
Changing the Forbidden View.
- imperative configuration
- The configuration mode in which you use Python to call methods on
a Configurator in order to add each configuration
declaration required by your application.
- Locale Name
- A string like
en
, en_US
, de
, or de_AT
which
uniquely identifies a particular locale.
- Locale Negotiator
- An object supplying a policy determining which locale
name best represents a given request. It is used by the
pyramid.i18n.get_locale_name()
, and
pyramid.i18n.negotiate_locale_name()
functions, and
indirectly by pyramid.i18n.get_localizer()
. The
pyramid.i18n.default_locale_negotiator()
function
is an example of a locale negotiator.
- module
- A Python source file; a file on the filesystem that typically ends with
the extension
.py
or .pyc
. Modules often live in a
package.
- Not Found view
- An exception view invoked by Pyramid when the
developer explicitly raises a
pyramid.exceptions.NotFound
exception from within view code or root factory
code, or when the current request doesn’t match any view
configuration. Pyramid provides a default
implementation of a not found view; it can be overridden. See
Changing the Not Found View.
- package
- A directory on disk which contains an
__init__.py
file, making
it recognizable to Python as a location which can be import
-ed.
A package exists to contain module files.
- Pylons
- A lightweight Python web framework.
- Pyramid
- A web framework.
- renderer
- A serializer that can be referred to via view
configuration which converts a non-Response return
values from a view into a string (and ultimately a
response). Using a renderer can make writing views that require
templating or other serialization less tedious. See
Writing View Callables Which Use a Renderer for more information.
- renderer factory
- A factory which creates a renderer. See
Adding and Changing Renderers for more information.
- request
- A
WebOb
request object. See Request and Response Objects (narrative)
and pyramid.request (API documentation) for information
about request objects.
- Resource Location
- The act of locating a context resource given a request.
Traversal and URL dispatch are the resource location
subsystems used by Pyramid.
- root factory
- The “root factory” of an Pyramid application is called
on every request sent to the application. The root factory
returns the traversal root of an application. It is
conventionally named
get_root
. An application may supply a
root factory to Pyramid during the construction of a
Configurator. If a root factory is not supplied, the
application uses a default root object. Use of the default root
object is useful in application which use URL dispatch for
all URL-to-view code mappings.
- route
- A single pattern matched by the url dispatch subsystem, which
generally resolves to one or more view callable objects. See
also url dispatch.
- route configuration
- Route configuration is the act of using imperative
configuration or a ZCML
<route>
statement to
associate request parameters with a particular route using
pattern matching and route predicate statements. See
URL Dispatch for more information about route
configuration.
- route predicate
- An argument to a route configuration which implies a value
that evaluates to
True
or False
for a given
request. All predicates attached to a route
configuration must evaluate to True
for the associated route
to “match” the current request. If a route does not match the
current request, the next route (in definition order) is
attempted.
- router
- The WSGI application created when you start a
Pyramid application. The router intercepts requests,
invokes traversal and/or URL dispatch, calls view functions, and
returns responses to the WSGI server on behalf of your
Pyramid application.
- scan
- The term used by Pyramid to define the process of
importing and examining all code in a Python package or module for
configuration decoration.
- Translation Directory
- A translation directory is a gettext translation
directory. It contains language folders, which themselves
contain
LC_MESSAGES
folders, which contain .mo
files.
Each .mo
file represents a set of translations for a language
in a translation domain. The name of the .mo
file
(minus the .mo extension) is the translation domain name.
- Translation Domain
- A string representing the “context” in which a translation was
made. For example the word “java” might be translated
differently if the translation domain is “programming-languages”
than would be if the translation domain was “coffee”. A
translation domain is represnted by a collection of
.mo
files
within one or more translation directory directories.
- traversal
- The act of descending “up” a tree of resource objects from a root
resource in order to find a context resource. The Pyramid
router performs traversal of resource objects when a root
factory is specified. See the Traversal chapter for
more information. Traversal can be performed instead of URL
dispatch or can be combined with URL dispatch. See
Combining Traversal and URL Dispatch for more information about combining traversal and
URL dispatch (advanced).
- URL dispatch
- An alternative to traversal as a mechanism for locating a a
view callable. When you use a route in your Pyramid
application via a route configuration, you are using URL
dispatch. See the URL Dispatch for more information.
- view
- Common vernacular for a view callable.
- view callable
- A “view callable” is a callable Python object which is associated with a
view configuration; it returns a response object . A
view callable accepts a single argument:
request
, which will be an
instance of a request object. A view callable is the primary
mechanism by which a developer writes user interface code within
Pyramid. See Views for more information about Pyramid
view callables.
- view configuration
- View configuration is the act of associating a view callable
with configuration information. This configuration information helps
map a given request to a particular view callable and it can
influence the response of a view callable. Pyramid views can be
configured via imperative configuration, ZCML or by a
special
@view_config
decorator coupled with a scan. See
View Configuration for more information about view
configuration.
- View handler
- A view handler ties together
pyramid.config.Configurator.add_route()
and
pyramid.config.Configurator.add_view()
to make it more
convenient to register a collection of views as a single class when
using url dispatch. See also Views.
- view mapper
- A view mapper is a class which implements the
pyramid.interfaces.IViewMapperFactory
interface, which performs
view argument and return value mapping. This is a plug point for
extension builders, not normally used by “civilians”.
- view name
- The “URL name” of a view, e.g
index.html
. If a view is
configured without a name, its name is considered to be the empty
string (which implies the default view).
- view predicate
- An argument to a view configuration which evaluates to
True
or False
for a given request. All predicates
attached to a view configuration must evaluate to true for the
associated view to be considered as a possible callable for a
given request.
- WSGI
- Web Server Gateway Interface. This is a
Python standard for connecting web applications to web servers,
similar to the concept of Java Servlets. Pyramid requires
that your application be served as a WSGI application.
- ZCML
- Zope Configuration Markup Language, an XML dialect
used by Zope and Pyramid for configuration tasks. ZCML
is capable of performing different types of configuration
declaration, but its primary purpose in Pyramid is to
perform view configuration and route configuration
within the
configure.zcml
file in a Pyramid
application. You can use ZCML as an alternative to
imperative configuration.
- ZCML declaration
- The concrete use of a ZCML directive within a ZCML file.
- ZCML directive
- A ZCML “tag” such as
<view>
or <route>
.
- Zope Component Architecture
- The Zope Component Architecture (aka ZCA) is a system
which allows for application pluggability and complex dispatching
based on objects which implement an interface.
Pyramid uses the ZCA “under the hood” to perform view
dispatching and other application configuration tasks.