1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
|
.. _glossary:
============================
Glossary
============================
.. 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 <http://peak.telecommunity.com/DevCenter/setuptools>`_
builds on Python's ``distutils`` to provide easier building,
distribution, and installation of libraries and applications.
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``.
View
A "view" is a callable which returns a response object. It should
accept two values: context and request.
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 <http://pypi.python.org/pypi/virtualenv>`_
was created by Ian Bicking.
Model
An object representing data in the system. A model is part of the
object graph traversed by the system. Models are traversed to
determine a context.
Traversal
The act of descending "down" a graph of model objects from a root
model in order to find a :term:`context`. The :mod:`repoze.bfg`
*router* performs traversal of model objects. See the
:ref:`traversal_chapter` chapter for more information.
URL dispatch
An alternative to graph traversal as a mechanism for locating a
:term:`context` for a :term:`view`. When you use :term:`Routes`
in your :mod:`repoze.bfg` application, you are using URL dispatch.
See the :ref:`urldispatch_module` for more information.
Context
A :term:`model` in the system that is "found" during
:term:`traversal` or :term:`URL dispatch`; it becomes the subject
of a :term:`view`. See the :ref:`traversal_chapter` chapter for
more information.
Application registry
A registry which maps model types to views, as well as performing
other application-specific component registrations. Every
:mod:`repoze.bfg` application has one (and only one) application
registry, which is represented on disk by its ``configure.zcml``
file.
Template
A file with replaceable parts that is capable of representing some
text, XML, or HTML when rendered.
Interface
An attribute of an object that determines its type.
Location
The path to an object in a model graph. See :ref:`location_aware`
for more information about how to make a model object *location-aware*.
Security policy
An object that provides a mechanism to check authorization using
authentication data and a permission associated with a model. It
essentially returns "true" if the combination of the authorization
information in the model (e.g. an :term:`ACL`) and the
authentication data in the request (e.g. the ``REMOTE_USER``
environment variable) allow the action implied by the permission
associated with the view (e.g. ``add`` or ``read``).
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 :term:`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 :term:`ACL`. An access control entry is a three-tuple that
describes three things: an *action* (one of either ``Allow`` or
``Deny``), a :term:`principal` (a string describing a user or
group), and a :term:`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 :term:`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 :term:`authentication` information in the request.
Authentication
The act of determining that the credentials a user presents during
a particular request are "good". :mod:`repoze.bfg` does not
perfom authentication: it leaves it up to an upstream component
such as :term:`repoze.who`. :mod:`repoze.bfg` uses the
:term:`authentication` data supplied by the upstream component as
one input during :term:`authorization`.
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 :term:`principal` (or principals) associated with the
request have the requisite :term:`permission` to allow the request
to continue.
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
:term:`authentication` machinery "upstream", typically (such as
:term:`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".
Security Policy
A security policy in bfg terms is a bit of code which accepts a
request, the :term:`ACL` associated with a context, and the
:term:`permission` associated with a particular view, and
subsequently determines whether or not the principals associated
with the request can perform the action associated with the
permission based on the ACL found on the :term:`context` (or any
of its parents).
WSGI
`Web Server Gateway Interface <http://wsgi.org/>`_. 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 :term:`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 <http://wsgi.org>`_
or `PyPI <http://python.org/pypi>`_ to find middleware for your
application.
Zope
`The Z Object Publishing Framework <http://zope.org>`_. The granddaddy
of Python web frameworks.
ZODB
`Zope Object Database <http://wiki.zope.org/ZODB/FrontPage>`_, a
persistent Python object store.
WebOb
`WebOb <http://pythonpaste.org/webob/>`_ is a WSGI request/response
library created by Ian Bicking.
Paste
`Paste <http://pythonpaste.org>`_ is a WSGI development and
deployment system developed by Ian Bicking.
PasteDeploy
`PasteDeploy <http://pythonpaste.org>`_ is a library used by
:mod:`repoze.bfg` which makes it possible to configure
:term:`WSGI` components together declaratively within an ``.ini``
file. It was developed by Ian Bicking as part of :term:`Paste`.
LXML
`lxml <http://codespeak.net/lxml/>`_ is a XML processing library
for Python by Martijn Faassen and others.
XSLT
`XSL Transformations <http://www.w3.org/TR/xslt>`_. A language
for transforming XML documents into other XML documents.
z3c.pt
`z3c.pt <http://pypi.python.org/pypi/z3c.pt>`_ is an
implementation of :term:`ZPT` by Malthe Borch. It has serveral
extensions, such as the ability to use bracketed- ``${name}``
syntax. It is also much faster than the reference implementation
of ZPT. :mod:`repoze.bfg` offers z3c.pt templating out of the
box.
ZPT
The `Zope Page Template <http://wiki.zope.org/ZPT/FrontPage>`_
templating language.
METAL
`Macro Expansion for TAL <http://wiki.zope.org/ZPT/METAL>`_, a
part of :term:`ZPT` which makes it possible to share common look
and feel between templates. :term:`z3c.pt`, the implementation of
ZPT that :mod:`repoze.bfg` ships with does not implement the METAL
specification.
Routes
A `system by Ben Bangert <http://routes.groovie.org/>`_ which
parses URLs and compares them against a number of user defined
mappings. In terms of :mod:`repoze.bfg`, a Route can supplant
graph traversal when deciding which *view* should be called. See
:ref:`urldispatch_module` for more information about (optional)
Routes integration in bfg.
ZCML
`Zope Configuration Markup Language
<http://www.muthukadan.net/docs/zca.html#zcml>`_, the XML dialect
used by Zope and :mod:`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
:mod:`repoze.bfg` is to perform view mappings via the ``bfg:view``
declaration. The ``configure.zcml`` file in a :mod:`repoze.bfg`
application represents the application's :term:`application
registry`.
repoze.who
`Authentication middleware <http://static.repoze.org/whodocs>`_
for :term:`WSGI` applications. It can be used by
:mod:`repoze.bfg` to provide authentication information.
ReStructuredText
A `plain text format <http://docutils.sourceforge.net/rst.html>`_
that is the defacto standard for descriptive text shipped in
:term:`distribution` files, and Python docstrings.
|
