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.
