Glossary

Request

A WebOb request object.

Response

An object that has three attributes: app_iter (representing an iterable body), headerlist (representing the http headers sent upstream), and status (representing the http status string). This is the interface defined for WebOb response objects.

Setuptools

Setuptools builds on Python’s distutils to provide easier building, distribution, and installation of libraries and applications.

pkg_resources

A module which ships with setuptools that provides an API for addressing “resource files” within Python packages. Resource files are static files, template files, etc; basically anything non-Python-source that lives in a Python package can be considered a resource file. See also PkgResources

Resource

Any file contained within a Python package which is not a Python source code file.

Package

A directory on disk which contains an __init__.py file, making it recognizable to Python as a location which can be import -ed.

Project

(Setuptools/distutils terminology). A directory on disk which contains a setup.py file and one or more Python packages. The setup.py file contains code that allows the package(s) to be installed, distributed, and tested.

Distribution

(Setuptools/distutils terminology). A file representing an installable library or application. Distributions are usually files that have the suffix of .egg, .tar.gz, or .zip. Distributions are the target of Setuptools commands such as easy_install.

Entry Point

A setuptools indirection, defined within a setuptools distribution setup.py. It is usually a name which refers to a function somewhere in a package which is held by the distribution.

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.

View

A “view” is a callable which returns a response object. It should accept two values: context and request. An alternate calling convention allows a view to be defined as a a callable which only accepts a single request argument. A view is the primary mechanism by which a developer writes user interface code within repoze.bfg. See Views for more information about repoze.bfg views.

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”).

Virtualenv

An isolated Python environment. Allows you to control which packages are used on a particular project by cloning your main Python. virtualenv was created by Ian Bicking.

Model

An object representing data in the system. If traversal is used, a model is a node in the object graph traversed by the system. When traversal is used, a model instance becomes the context of a view. If url dispatch is used, a single context (which isn’t really a model, because it contains no data except security elements) is generated for each request and is used as the context of a view.

Traversal

The act of descending “down” a graph of model objects from a root model in order to find a context. The repoze.bfg router performs traversal of model 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).

Router

The WSGI application created when you start a repoze.bfg 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 repoze.bfg application.

URL dispatch

An alternative to graph traversal as a mechanism for locating a context for a view. When you use a route in your repoze.bfg application via a <route> declaration in ZCML, you are using URL dispatch. See the URL Dispatch for more information.

Context

An object in the system that is found during traversal or URL dispatch based on URL data; if it’s found via traversal, it’s usually a model object that is part of an object graph; if it’s found via URL dispatch, it’s a manufactured context object that contains security information. A context becomes the subject of a view, and typically has security information attached to it. See the Traversal chapter and the URL Dispatch chapter for more information about how a URL is resolved to a context.

Application registry

A registry which maps model types to views, as well as performing other application-specific component registrations. Every repoze.bfg application has one (and only one) application registry, which is represented on disk by its configure.zcml file (and any other included .zcml files)

Template

A file with replaceable parts that is capable of representing some text, XML, or HTML when rendered.

Location

The path to an object in a model graph. See Location-Aware Model Instances for more information about how to make a model object location-aware.

Principal

A user id or group id.

Permission

A string or unicode object that represents an action being taken against a context. A permission is associated with a view name and a model type by the developer. Models are decorated with security declarations (e.g. an ACL), which reference these tokens also. Permissions are used by the active to security policy to match the view permission against the model’s statements about which permissions are granted to which principal in a context in order to to answer the question “is this user allowed to do this”. Examples of permissions: read, or view_blog_entries.

ACE

An access control entry. An access control entry is one element in an ACL. An access control entry is a three-tuple that describes three things: an action (one of either Allow or Deny), a principal (a string describing a user or group), and a permission. For example the ACE, (Allow, 'bob', 'read') is a member of an ACL that indicates that the principal bob is allowed the permission read against the context the ACL is attached to.

ACL

An access control list. An ACL is a sequence of ACE tuples. An ACL is attached to a model instance. An example of an ACL is [ (Allow, 'bob', 'read'), (Deny, 'fred', 'write')]. If an ACL is attached to a model instance, and that model instance is findable via the context, it will be consulted any active security policy to determine wither a particular request can be fulfilled given the authentication information in the request.

Authentication

The act of determining that the credentials a user presents during a particular request are “good”. repoze.bfg does not perfom authentication: it leaves it up to an upstream component such as repoze.who. repoze.bfg uses the authentication data supplied by the upstream component as one input during authorization. Authentication in repoze.bfg is performed via an authentication policy.

Authorization

The act of determining whether a user can perform a specific action. In bfg terms, this means determining whether, for a given context, any principal (or principals) associated with the request have the requisite permission to allow the request to continue. Authorization in repoze.bfg is performed via its authorization policy.

Principal

A principal is a string or unicode object representing a user or a user’s membership in a group. It is provided by the authentication machinery “upstream”, typically (such as repoze.who). For example, if a user had the user id “bob”, and Bob was part of two groups named “group foo” and “group bar”, the request might have information attached to it that would indictate that Bob was represented by three principals: “bob”, “group foo” and “group bar”.

Authorization Policy

An authorization policy in repoze.bfg 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.

Authentication Policy

An authentication policy in repoze.bfg terms is a bit of code which has an API which determines the current principal (or principals) associated with a 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. repoze.bfg requires that your application be served as a WSGI application.

Middleware

Middleware is a WSGI concept. It is a WSGI component that acts both as a server and an application. Interesting uses for middleware exist, such as caching, content-transport encoding, and other functions. See WSGI.org or PyPI to find middleware for your application.

Pipeline

The Paste term for a single configuration of a WSGI server, a WSGI application, with a set of middleware in-between.

mod_wsgi

An Apache module for hosting Python WSGI applications.

Zope

The Z Object Publishing Framework, a full-featured Python web framework.

Grok

A web framework based on Zope 3.

Django

A full-featured Python web framework.

Pylons

A lightweight Python web framework.

ZODB

Zope Object Database, a persistent Python object store.

WebOb

WebOb is a WSGI request/response library created by Ian Bicking.

Paste

Paste is a WSGI development and deployment system developed by Ian Bicking.

PasteDeploy

PasteDeploy is a library used by repoze.bfg which makes it possible to configure WSGI components together declaratively within an .ini file. It was developed by Ian Bicking as part of Paste.

Chameleon

chameleon is an attribute language template compiler which supports both the ZPT and Genshi templating specifications. It is written and maintained by Malthe Borch. It has serveral extensions, such as the ability to use bracketed (Genshi-style) ${name} syntax, even within ZPT. It is also much faster than the reference implementations of both ZPT and Genshi. repoze.bfg offers Chameleon templating out of the box in ZPT flavor and offers the Genshi flavor as an add on within the repoze.bfg.chameleon_genshi package.

chameleon.zpt

chameleon.zpt is the package which provides ZPT templating support under the Chameleon templating engine.

z3c.pt

This was the previous name for Chameleon, and is now a Zope 3 compatibility package for Chameleon.

ZPT

The Zope Page Template templating language.

METAL

Macro Expansion for TAL, a part of ZPT which makes it possible to share common look and feel between templates.

Genshi

An XML templating language by Christopher Lenz.

Jinja2

A text templating language by Armin Ronacher.

Routes

A system by Ben Bangert which parses URLs and compares them against a number of user defined mappings. The URL pattern matching syntax in repoze.bfg is inspired by the Routes syntax (which was inspired by Ruby On Rails pattern syntax).

Route

A single pattern matched by the url dispatch subsystem, which generally resolves to a root factory (and then ultimately a view). See also url dispatch.

ZCML

Zope Configuration Markup Language, the XML dialect used by Zope and repoze.bfg to describe associating a view with a model type. ZCML is capable of performing many different registrations and declarations, but its primary purpose in repoze.bfg is to perform view mappings via the view declaration. The configure.zcml file in a repoze.bfg application represents the application’s application registry. You can also use decorators to configure views in repoze.bfg; see Mapping Views to URLs Using a Decorator.

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. repoze.bfg uses the ZCA “under the hood” to perform view dispatching and other application configuration tasks.

ReStructuredText

A plain text format that is the defacto standard for descriptive text shipped in distribution files, and Python docstrings. This documentation is authored in ReStructuredText format.

Root

The object at which traversal begins when repoze.bfg searches for a context (for URL Dispatch, the root is always the context).

Subpath

A list of element “left over” after the router has performed a successful traversal to a view. The subpath is a sequence of strings, e.g. ['left', 'over', 'names']. Within BFG applications that use URL dispatch rather than traversal, you can use *subpath in the route pattern to influence the subpath. See Using *subpath in a Route Path for more information.

Interface

A Zope interface object. In repoze.bfg, an interface may be attached to an model object or a request object in order to identify that the object is “of a type”. Interfaces are used internally by repoze.bfg to perform view lookups and other policy lookups. Interfaces are exposed to application programmers by the view ZCML directive or the corresponding bfg_view decorator in the form of both the for attribute and the request_type attribute. They may be exposed to application developers when using the event system as well. Fundamentally, repoze.bfg programmers can think of an interface as something that they can attach to an object that stamps it with a “type” unrelated to its underlying Python type. Interfaces can also be used to describe the behavior of an object (its methods and attributes), but unless they choose to, repoze.bfg programmers do not need to understand or use this feature of interfaces. In other words, bfg developers need to only understand “marker” interfaces.

Event

An object broadcast to zero or more subscriber callables during normal system operations. repoze.bfg emits events during its lifetime routine. Application code can subscribe to these events by using the subscriber functionality described in Using Events. Application code can also generate its own events using the zope.component.event.dispatch function. Application-code generated events may be subscribed to in the same way as system-generated events.

Subscriber

A callable which receives an event. A callable becomes a subscriber through an application registry registration. See Using Events for more information.

Request type

An attribute of a request that allows for specialization of view code based on arbitrary categorization. The every request object that bfg generates and manipulates has one or more interface objects attached to it. The default interface attached to a request object is repoze.bfg.interfaces.IRequest. When a user writes view code, and registers a view without specifying a particular request type, the view is assumed to be registered for requests that have repoze.bfg.interfaces.IRequest attached to them. However if the view is registered with a different interface as its request type, the view will be invoked only when the request possesses that particular interface. Application code can cause requests to possess a different interface by adding the interface to the request object within a subscriber to the repoze.bfg.interfaces.INewRequest event type. String aliases such as GET, POST, etc. representing HTTP method names may be used in place of an interface specification in the request_type argument passed to view declarations. GET is aliased to repoze.bfg.interfaces.IGETRequest, POST is aliased to repoze.bfg.interfaces.IPOSTRequest, and so on.

repoze.lemonade

Zope2 CMF-like data structures and helper facilities for CA-and-ZODB-based applications useful within bfg applications.

repoze.catalog

An indexing and search facility (fielded and full-text) based on zope.index. See the documentation for more information.

repoze.who

Authentication middleware for WSGI applications. It can be used by repoze.bfg to provide authentication information.

repoze.workflow

Barebones workflow for Python apps . It can be used by repoze.bfg to form a workflow system.

Virtual root

A model object representing the “virtual” root of a request; this is typically the physical root object (the object returned by the application root factory) unless Virtual Hosting is in use.

Lineage

An ordered sequence of objects based on a “location -aware” context. The lineage of any given context is composed of itself, its parent, its parent’s parent, and so on. The order of the sequence is context-first, then the parent of the context, then its parent’s parent, and so on.

Root Factory

The “root factory” of an repoze.bfg 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 must supply a root factory to repoze.bfg within a call to repoze.bfg.router.make_app; however, an application’s root factory may be passed to make_app as None, in which case the application uses a default root object (this pattern is often used in application which use URL dispatch for all URL-to-view code mappings).

SQLAlchemy

SQLAlchemy’ is an object relational mapper used in tutorials within this documentation.