Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
100644 895 lines (749 sloc) 39.725 kb
86cfd11 @mcdonc - Moved "Using ZODB With ZEO" and "Using repoze.catalog Within Pyramid"
mcdonc authored
1 .. _glossary:
3 Glossary
4 ========
6 .. glossary::
7 :sorted:
9 request
10 A ``WebOb`` request object. See :ref:`webob_chapter` (narrative)
11 and :ref:`request_module` (API documentation) for information
12 about request objects.
14 request factory
15 An object which, provided a WSGI environment as a single
16 positional argument, returns a ``WebOb`` compatible request.
18 response
19 An object that has three attributes: ``app_iter`` (representing an
20 iterable body), ``headerlist`` (representing the http headers sent
21 to the user agent), and ``status`` (representing the http status
22 string sent to the user agent). This is the interface defined for
23 ``WebOb`` response objects. See :ref:`webob_chapter` for
24 information about response objects.
26 Repoze
27 "Repoze" is essentially a "brand" of software developed by `Agendaless
28 Consulting <>`_ and a set of contributors. The
29 term has no special intrinsic meaning. The project's `website
30 <>`_ has more information. The software developed
31 "under the brand" is available in a `Subversion repository
32 <>`_. Pyramid was originally known as
33 :mod:`repoze.bfg`.
35 setuptools
36 `Setuptools <>`_
37 builds on Python's ``distutils`` to provide easier building,
38 distribution, and installation of libraries and applications.
40 pkg_resources
41 A module which ships with :term:`setuptools` that provides an API for
42 addressing "asset files" within a Python :term:`package`. Asset files
43 are static files, template files, etc; basically anything
44 non-Python-source that lives in a Python package can be considered a
45 asset file. See also `PkgResources
46 <>`_
48 asset
49 Any file contained within a Python :term:`package` which is *not*
50 a Python source code file.
52 asset specification
53 A colon-delimited identifier for an :term:`asset`. The colon
54 separates a Python :term:`package` name from a package subpath.
55 For example, the asset specification
56 ``my.package:static/baz.css`` identifies the file named
57 ``baz.css`` in the ``static`` subdirectory of the ``my.package``
58 Python :term:`package`. See :ref:`asset_specifications` for more
59 info.
61 package
62 A directory on disk which contains an ```` file, making
63 it recognizable to Python as a location which can be ``import`` -ed.
64 A package exists to contain :term:`module` files.
66 module
67 A Python source file; a file on the filesystem that typically ends with
68 the extension ``.py`` or ``.pyc``. Modules often live in a
69 :term:`package`.
71 project
72 (Setuptools/distutils terminology). A directory on disk which
73 contains a ```` file and one or more Python packages. The
74 ```` file contains code that allows the package(s) to be
75 installed, distributed, and tested.
77 distribution
78 (Setuptools/distutils terminology). A file representing an
79 installable library or application. Distributions are usually
80 files that have the suffix of ``.egg``, ``.tar.gz``, or ``.zip``.
81 Distributions are the target of Setuptools commands such as
82 ``easy_install``.
84 entry point
85 A :term:`setuptools` indirection, defined within a setuptools
86 :term:`distribution` It is usually a name which refers
87 to a function somewhere in a package which is held by the
88 distribution.
90 dotted Python name
91 A reference to a Python object by name using a string, in the form
92 ````. Often used in Paste and
93 setuptools configurations. A variant is used in dotted names within
94 configurator method arguments that name objects (such as the "add_view"
95 method's "view" and "context" attributes): the colon (``:``) is not
96 used; in its place is a dot.
98 view
99 Common vernacular for a :term:`view callable`.
101 view callable
102 A "view callable" is a callable Python object which is associated
103 with a :term:`view configuration`; it returns a :term:`response`
104 object . A view callable accepts a single argument: ``request``,
105 which will be an instance of a :term:`request` object. An
106 alternate calling convention allows a view to be defined as a
107 callable which accepts a pair of arguments: ``context`` and
108 ``request``: this calling convention is useful for
109 traversal-based applications in which a :term:`context` is always
110 very important. A view callable is the primary mechanism by
111 which a developer writes user interface code within
112 :app:`Pyramid`. See :ref:`views_chapter` for more information
113 about :app:`Pyramid` view callables.
115 view configuration
116 View configuration is the act of associating a :term:`view callable`
117 with configuration information. This configuration information helps
118 map a given :term:`request` to a particular view callable and it can
119 influence the response of a view callable. :app:`Pyramid` views can be
120 configured via :term:`imperative configuration`, or by a special
121 ``@view_config`` decorator coupled with a :term:`scan`. See
122 :ref:`view_config_chapter` for more information about view
123 configuration.
125 view name
126 The "URL name" of a view, e.g ``index.html``. If a view is
127 configured without a name, its name is considered to be the empty
128 string (which implies the :term:`default view`).
130 Default view
131 The default view of a :term:`resource` is the view invoked when the
132 :term:`view name` is the empty string (``''``). This is the case when
133 :term:`traversal` exhausts the path elements in the PATH_INFO of a
134 request before it returns a :term:`context` resource.
136 virtualenv
137 An isolated Python environment. Allows you to control which
138 packages are used on a particular project by cloning your main
139 Python. `virtualenv <>`_
140 was created by Ian Bicking.
142 resource
143 An object representing a node in the :term:`resource tree` of an
144 application. If :mod:`traversal` is used, a resource is an element in
145 the resource tree traversed by the system. When traversal is used, a
146 resource becomes the :term:`context` of a :term:`view`. If :mod:`url
147 dispatch` is used, a single resource is generated for each request and
148 is used as the context resource of a view.
150 resource tree
151 A nested set of dictionary-like objects, each of which is a
152 :term:`resource`. The act of :term:`traversal` uses the resource tree
153 to find a :term:`context` resource.
155 domain model
156 Persistent data related to your application. For example, data stored
157 in a relational database. In some applications, the :term:`resource
158 tree` acts as the domain model.
160 traversal
161 The act of descending "up" a tree of resource objects from a root
162 resource in order to find a :term:`context` resource. The
163 :app:`Pyramid` :term:`router` performs traversal of resource objects
164 when a :term:`root factory` is specified. See the
165 :ref:`traversal_chapter` chapter for more information. Traversal can be
166 performed *instead* of :term:`URL dispatch` or can be combined *with*
167 URL dispatch. See :ref:`hybrid_chapter` for more information about
168 combining traversal and URL dispatch (advanced).
170 router
171 The :term:`WSGI` application created when you start a
172 :app:`Pyramid` application. The router intercepts requests,
173 invokes traversal and/or URL dispatch, calls view functions, and
174 returns responses to the WSGI server on behalf of your
175 :app:`Pyramid` application.
177 URL dispatch
178 An alternative to :term:`traversal` as a mechanism for locating a
179 :term:`context` resource for a :term:`view`. When you use a
180 :term:`route` in your :app:`Pyramid` application via a :term:`route
181 configuration`, you are using URL dispatch. See the
182 :ref:`urldispatch_chapter` for more information.
184 context
185 An resource in the resource tree that is found during :term:`traversal`
186 or :term:`URL dispatch` based on URL data; if it's found via traversal,
187 it's usually a :term:`resource` object that is part of a resource tree;
188 if it's found via :term:`URL dispatch`, it's a object manufactured on
189 behalf of the route's "factory". A context resource becomes the subject
190 of a :term:`view`, and often has security information attached to
191 it. See the :ref:`traversal_chapter` chapter and the
192 :ref:`urldispatch_chapter` chapter for more information about how a URL
193 is resolved to a context resource.
195 application registry
196 A registry of configuration information consulted by
197 :app:`Pyramid` while servicing an application. An application
198 registry maps resource types to views, as well as housing other
199 application-specific component registrations. Every
200 :app:`Pyramid` application has one (and only one) application
201 registry.
203 template
204 A file with replaceable parts that is capable of representing some
205 text, XML, or HTML when rendered.
207 location
208 The path to an object in a :term:`resource tree`. See
209 :ref:`location_aware` for more information about how to make a resource
210 object *location-aware*.
212 permission
213 A string or unicode object that represents an action being taken against
214 a :term:`context` resource. A permission is associated with a view name
215 and a resource type by the developer. Resources are decorated with
216 security declarations (e.g. an :term:`ACL`), which reference these
217 tokens also. Permissions are used by the active to security policy to
218 match the view permission against the resources's statements about which
219 permissions are granted to which principal in a context in order to to
220 answer the question "is this user allowed to do this". Examples of
221 permissions: ``read``, or ``view_blog_entries``.
223 default permission
224 A :term:`permission` which is registered as the default for an
225 entire application. When a default permission is in effect,
226 every :term:`view configuration` registered with the system will
227 be effectively amended with a ``permission`` argument that will
228 require that the executing user possess the default permission in
229 order to successfully execute the associated :term:`view
230 callable` See also :ref:`setting_a_default_permission`.
232 ACE
233 An *access control entry*. An access control entry is one element
234 in an :term:`ACL`. An access control entry is a three-tuple that
235 describes three things: an *action* (one of either ``Allow`` or
236 ``Deny``), a :term:`principal` (a string describing a user or
237 group), and a :term:`permission`. For example the ACE, ``(Allow,
238 'bob', 'read')`` is a member of an ACL that indicates that the
239 principal ``bob`` is allowed the permission ``read`` against the
240 resource the ACL is attached to.
242 ACL
243 An *access control list*. An ACL is a sequence of :term:`ACE` tuples.
244 An ACL is attached to a resource instance. An example of an ACL is ``[
245 (Allow, 'bob', 'read'), (Deny, 'fred', 'write')]``. If an ACL is
246 attached to a resource instance, and that resource is findable via the
247 context resource, it will be consulted any active security policy to
248 determine wither a particular request can be fulfilled given the
249 :term:`authentication` information in the request.
251 authentication
252 The act of determining that the credentials a user presents
253 during a particular request are "good". Authentication in
254 :app:`Pyramid` is performed via an :term:`authentication
255 policy`.
257 authorization
258 The act of determining whether a user can perform a specific action. In
259 pyramid terms, this means determining whether, for a given resource, any
260 :term:`principal` (or principals) associated with the request have the
261 requisite :term:`permission` to allow the request to continue.
262 Authorization in :app:`Pyramid` is performed via its
263 :term:`authorization policy`.
265 principal
266 A *principal* is a string or unicode object representing a userid
267 or a group id. It is provided by an :term:`authentication
268 policy`. For example, if a user had the user id "bob", and Bob
269 was part of two groups named "group foo" and "group bar", the
270 request might have information attached to it that would
271 indicate that Bob was represented by three principals: "bob",
272 "group foo" and "group bar".
274 authorization policy
275 An authorization policy in :app:`Pyramid` terms is a bit of
276 code which has an API which determines whether or not the
277 principals associated with the request can perform an action
278 associated with a permission, based on the information found on the
279 :term:`context` resource.
281 authentication policy
282 An authentication policy in :app:`Pyramid` terms is a bit of
283 code which has an API which determines the current
284 :term:`principal` (or principals) associated with a request.
286 WSGI
287 `Web Server Gateway Interface <>`_. This is a
288 Python standard for connecting web applications to web servers,
289 similar to the concept of Java Servlets. :app:`Pyramid` requires
290 that your application be served as a WSGI application.
292 middleware
293 *Middleware* is a :term:`WSGI` concept. It is a WSGI component
294 that acts both as a server and an application. Interesting uses
295 for middleware exist, such as caching, content-transport
296 encoding, and other functions. See ` <>`_
297 or `PyPI <>`_ to find middleware for your
298 application.
300 pipeline
301 The :term:`Paste` term for a single configuration of a WSGI
302 server, a WSGI application, with a set of middleware in-between.
304 Zope
305 `The Z Object Publishing Framework <>`_, a
306 full-featured Python web framework.
308 Grok
309 `A web framework based on Zope 3 <>`_.
311 Django
312 `A full-featured Python web framework <>`_.
314 Pylons
315 `A lightweight Python web framework <>`_ and a
316 predecessor of Pyramid.
318 ZODB
319 `Zope Object Database <>`_, a
320 persistent Python object store.
322 ZEO
323 `Zope Enterprise Objects
324 <>`_
325 allows multiple simultaneous processes to access a single
326 :term:`ZODB` database.
328 WebOb
329 `WebOb <>`_ is a WSGI request/response
330 library created by Ian Bicking.
332 Paste
333 `Paste <>`_ is a WSGI development and
334 deployment system developed by Ian Bicking.
336 PasteDeploy
337 `PasteDeploy <>`_ is a library used by
338 :app:`Pyramid` which makes it possible to configure
339 :term:`WSGI` components together declaratively within an ``.ini``
340 file. It was developed by Ian Bicking as part of :term:`Paste`.
342 Chameleon
343 `chameleon <>`_ is an attribute
344 language template compiler which supports both the :term:`ZPT` and
345 :term:`Genshi` templating specifications. It is written and
346 maintained by Malthe Borch. It has several extensions, such as
347 the ability to use bracketed (Genshi-style) ``${name}`` syntax,
348 even within ZPT. It is also much faster than the reference
349 implementations of both ZPT and Genshi. :app:`Pyramid` offers
350 Chameleon templating out of the box in ZPT and text flavors.
352 ZPT
353 The `Zope Page Template <>`_
354 templating language.
357 `Macro Expansion for TAL <>`_, a
358 part of :term:`ZPT` which makes it possible to share common look
359 and feel between templates.
361 Genshi
362 An `XML templating language <>`_
363 by Christopher Lenz.
365 Jinja2
366 A `text templating language <>`_ by Armin
367 Ronacher.
369 Routes
370 A `system by Ben Bangert <>`_ which
371 parses URLs and compares them against a number of user defined
372 mappings. The URL pattern matching syntax in :app:`Pyramid` is
373 inspired by the Routes syntax (which was inspired by Ruby On
374 Rails pattern syntax).
376 route
377 A single pattern matched by the :term:`url dispatch` subsystem,
378 which generally resolves to a :term:`root factory` (and then
379 ultimately a :term:`view`). See also :term:`url dispatch`.
381 route configuration
382 Route configuration is the act of associating request parameters with a
383 particular :term:`route` using pattern matching and :term:`route
384 predicate` statements. See :ref:`urldispatch_chapter` for more
385 information about route configuration.
387 Zope Component Architecture
388 The `Zope Component Architecture
389 <>`_ (aka ZCA) is a system
390 which allows for application pluggability and complex dispatching
391 based on objects which implement an :term:`interface`.
392 :app:`Pyramid` uses the ZCA "under the hood" to perform view
393 dispatching and other application configuration tasks.
395 reStructuredText
396 A `plain text format <>`_
397 that is the defacto standard for descriptive text shipped in
398 :term:`distribution` files, and Python docstrings. This
399 documentation is authored in ReStructuredText format.
401 root
402 The object at which :term:`traversal` begins when :app:`Pyramid`
403 searches for a :term:`context` resource (for :term:`URL Dispatch`, the
404 root is *always* the context resource unless the ``traverse=`` argument
405 is used in route configuration).
407 subpath
408 A list of element "left over" after the :term:`router` has
409 performed a successful traversal to a view. The subpath is a
410 sequence of strings, e.g. ``['left', 'over', 'names']``. Within
411 Pyramid applications that use URL dispatch rather than traversal, you
412 can use ``*subpath`` in the route pattern to influence the
413 subpath. See :ref:`star_subpath` for more information.
415 interface
416 A `Zope interface <>`_
417 object. In :app:`Pyramid`, an interface may be attached to a
418 :term:`resource` object or a :term:`request` object in order to
419 identify that the object is "of a type". Interfaces are used
420 internally by :app:`Pyramid` to perform view lookups and other
421 policy lookups. The ability to make use of an interface is
422 exposed to an application programmers during :term:`view
423 configuration` via the ``context`` argument, the ``request_type``
424 argument and the ``containment`` argument. Interfaces are also
425 exposed to application developers when they make use of the
426 :term:`event` system. Fundamentally, :app:`Pyramid`
427 programmers can think of an interface as something that they can
428 attach to an object that stamps it with a "type" unrelated to its
429 underlying Python type. Interfaces can also be used to describe
430 the behavior of an object (its methods and attributes), but
431 unless they choose to, :app:`Pyramid` programmers do not need
432 to understand or use this feature of interfaces.
434 event
435 An object broadcast to zero or more :term:`subscriber` callables
436 during normal :app:`Pyramid` system operations during the
437 lifetime of an application. Application code can subscribe to
438 these events by using the subscriber functionality described in
439 :ref:`events_chapter`.
441 subscriber
442 A callable which receives an :term:`event`. A callable becomes a
443 subscriber via :term:`imperative configuration` or via
444 :term:`configuration decoration`. See :ref:`events_chapter` for more
445 information.
447 request type
448 An attribute of a :term:`request` that allows for specialization
449 of view invocation based on arbitrary categorization. The every
450 :term:`request` object that :app:`Pyramid` generates and
451 manipulates has one or more :term:`interface` objects attached to
452 it. The default interface attached to a request object is
453 ``pyramid.interfaces.IRequest``.
455 repoze.lemonade
456 Zope2 CMF-like `data structures and helper facilities
457 <>`_ for CA-and-ZODB-based
458 applications useful within :app:`Pyramid` applications.
460 repoze.catalog
461 An indexing and search facility (fielded and full-text) based on
462 `zope.index <>`_. See `the
463 documentation <>`_ for more
464 information. A tutorial for its usage in :app:`Pyramid`
465 exists in :ref:`catalog_tutorial`.
467 repoze.who
468 `Authentication middleware <>`_ for
469 :term:`WSGI` applications. It can be used by :app:`Pyramid` to
470 provide authentication information.
472 repoze.workflow
473 `Barebones workflow for Python apps
474 <>`_ . It can be used by
475 :app:`Pyramid` to form a workflow system.
477 virtual root
478 A resource object representing the "virtual" root of a request; this
479 is typically the physical root object (the object returned by the
480 application root factory) unless :ref:`vhosting_chapter` is in
481 use.
483 lineage
484 An ordered sequence of objects based on a ":term:`location` -aware"
485 resource. The lineage of any given :term:`resource` is composed of
486 itself, its parent, its parent's parent, and so on. The order of the
487 sequence is resource-first, then the parent of the resource, then its
488 parent's parent, and so on. The parent of a resource in a lineage is
489 available as its ``__parent__`` attribute.
491 root factory
492 The "root factory" of an :app:`Pyramid` application is called
493 on every request sent to the application. The root factory
494 returns the traversal root of an application. It is
495 conventionally named ``get_root``. An application may supply a
496 root factory to :app:`Pyramid` during the construction of a
497 :term:`Configurator`. If a root factory is not supplied, the
498 application uses a default root object. Use of the default root
499 object is useful in application which use :term:`URL dispatch` for
500 all URL-to-view code mappings.
502 SQLAlchemy
503 `SQLAlchemy <>`_ is an object
504 relational mapper used in tutorials within this documentation.
506 JSON
507 `JavaScript Object Notation <>`_ is a data
508 serialization format.
510 renderer
511 A serializer that can be referred to via :term:`view
512 configuration` which converts a non-:term:`Response` return
513 values from a :term:`view` into a string (and ultimately a
514 response). Using a renderer can make writing views that require
515 templating or other serialization less tedious. See
516 :ref:`views_which_use_a_renderer` for more information.
518 renderer factory
519 A factory which creates a :term:`renderer`. See
520 :ref:`adding_and_overriding_renderers` for more information.
522 mod_wsgi
523 `mod_wsgi <>`_ is an Apache
524 module developed by Graham Dumpleton. It allows :term:`WSGI`
525 applications (such as applications developed using
526 :app:`Pyramid`) to be served using the Apache web server.
528 view predicate
529 An argument to a :term:`view configuration` which evaluates to
530 ``True`` or ``False`` for a given :term:`request`. All predicates
531 attached to a view configuration must evaluate to true for the
532 associated view to be considered as a possible callable for a
533 given request.
535 route predicate
536 An argument to a :term:`route configuration` which implies a value
537 that evaluates to ``True`` or ``False`` for a given
538 :term:`request`. All predicates attached to a :term:`route
539 configuration` must evaluate to ``True`` for the associated route
540 to "match" the current request. If a route does not match the
541 current request, the next route (in definition order) is
542 attempted.
544 routes mapper
545 An object which compares path information from a request to an
546 ordered set of route patterns. See :ref:`urldispatch_chapter`.
548 predicate
549 A test which returns ``True`` or ``False``. Two different types
550 of predicates exist in :app:`Pyramid`: a :term:`view predicate`
551 and a :term:`route predicate`. View predicates are attached to
552 :term:`view configuration` and route predicates are attached to
553 :term:`route configuration`.
555 decorator
556 A wrapper around a Python function or class which accepts the
557 function or class as its first argument and which returns an
558 arbitrary object. :app:`Pyramid` provides several decorators,
559 used for configuration and return value modification purposes. See
560 also `PEP 318 <>`_.
562 configuration declaration
563 An individual method call made to an instance of a :app:`Pyramid`
564 :term:`Configurator` object which performs an arbitrary action, such as
565 registering a :term:`view configuration` (via the ``add_view`` method of
566 the configurator) or :term:`route configuration` (via the ``add_route``
567 method of the configurator). A set of configuration declarations is
568 also implied by the :term:`configuration decoration` detected by a
569 :term:`scan` of code in a package.
571 configuration decoration
572 Metadata implying one or more :term:`configuration declaration`
573 invocations. Often set by configuration Python :term:`decorator`
574 attributes, such as :class:`pyramid.view.view_config`, aka
575 ``@view_config``.
577 scan
578 The term used by :app:`Pyramid` to define the process of
579 importing and examining all code in a Python package or module for
580 :term:`configuration decoration`.
582 configurator
583 An object used to do :term:`configuration declaration` within an
584 application. The most common configurator is an instance of the
585 ``pyramid.config.Configurator`` class.
587 imperative configuration
588 The configuration mode in which you use Python to call methods on
589 a :term:`Configurator` in order to add each :term:`configuration
590 declaration` required by your application.
592 declarative configuration
593 The configuration mode in which you use :term:`ZCML` to make a set of
594 :term:`configuration declaration` statements. See :term:`pyramid_zcml`.
596 Not Found view
597 An :term:`exception view` invoked by :app:`Pyramid` when the
598 developer explicitly raises a ``pyramid.exceptions.NotFound``
599 exception from within :term:`view` code or :term:`root factory`
600 code, or when the current request doesn't match any :term:`view
601 configuration`. :app:`Pyramid` provides a default
602 implementation of a not found view; it can be overridden. See
603 :ref:`changing_the_notfound_view`.
605 Forbidden view
606 An :term:`exception view` invoked by :app:`Pyramid` when the
607 developer explicitly raises a
608 ``pyramid.exceptions.Forbidden`` exception from within
609 :term:`view` code or :term:`root factory` code, or when the
610 :term:`view configuration` and :term:`authorization policy`
611 found for a request disallows a particular view invocation.
612 :app:`Pyramid` provides a default implementation of a
613 forbidden view; it can be overridden. See
614 :ref:`changing_the_forbidden_view`.
616 Exception view
617 An exception view is a :term:`view callable` which may be
618 invoked by :app:`Pyramid` when an exception is raised during
619 request processing. See :ref:`exception_views` for more
620 information.
622 thread local
623 A thread-local variable is one which is essentially a global variable
624 in terms of how it is accessed and treated, however, each `thread
625 <>`_ used by the
626 application may have a different value for this same "global" variable.
627 :app:`Pyramid` uses a small number of thread local variables, as
628 described in :ref:`threadlocals_chapter`. See also the `threading.local
629 documentation
630 <>`_ for
631 more information.
633 multidict
634 An ordered dictionary that can have multiple values for each
635 key. Adds the methods ``getall``, ``getone``, ``mixed``, and
636 ``add`` to the normal dictionary interface. See
639 PyPI
640 `The Python Package Index <>`_, a
641 collection of software available for Python.
643 Agendaless Consulting
644 A consulting organization formed by Paul Everitt, Tres Seaver,
645 and Chris McDonough. See also .
647 Jython
648 A `Python implementation <>`_ written for
649 the Java Virtual Machine.
651 Python
652 The `programming language <>`_ in which
653 :app:`Pyramid` is written.
655 CPython
656 The C implementation of the Python language. This is the
657 reference implementation that most people refer to as simply
658 "Python"; :term:`Jython`, Google's App Engine, and `PyPy
659 <>`_ are examples of
660 non-C based Python implementations.
662 View Lookup
663 The act of finding and invoking the "best" :term:`view callable`
664 given a :term:`request` and a :term:`context` resource.
666 Resource Location
667 The act of locating a :term:`context` resource given a :term:`request`.
668 :term:`Traversal` and :term:`URL dispatch` are the resource location
669 subsystems used by :app:`Pyramid`.
671 Google App Engine
672 `Google App Engine <>`_ (aka
673 "GAE") is a Python application hosting service offered by Google.
674 :app:`Pyramid` runs on GAE.
676 Venusian
677 `Venusian <>`_ is a library which
678 allows framework authors to defer decorator actions. Instead of
679 taking actions when a function (or class) decorator is executed
680 at import time, the action usually taken by the decorator is
681 deferred until a separate "scan" phase. :app:`Pyramid` relies
682 on Venusian to provide a basis for its :term:`scan` feature.
684 Translation String
685 An instance of :class:`pyramid.i18n.TranslationString`, which
686 is a class that behaves like a Unicode string, but has several
687 extra attributes such as ``domain``, ``msgid``, and ``mapping``
688 for use during translation. Translation strings are usually
689 created by hand within software, but are sometimes created on the
690 behalf of the system for automatic template translation. For
691 more information, see :ref:`i18n_chapter`.
693 Translation Domain
694 A string representing the "context" in which a translation was
695 made. For example the word "java" might be translated
696 differently if the translation domain is "programming-languages"
697 than would be if the translation domain was "coffee". A
698 translation domain is represnted by a collection of ``.mo`` files
699 within one or more :term:`translation directory` directories.
701 Translator
702 A callable which receives a :term:`translation string` and
703 returns a translated Unicode object for the purposes of
704 internationalization. A :term:`localizer` supplies a
705 translator to a :app:`Pyramid` application accessible via its
706 ``translate`` method.
708 Translation Directory
709 A translation directory is a :term:`gettext` translation
710 directory. It contains language folders, which themselves
711 contain ``LC_MESSAGES`` folders, which contain ``.mo`` files.
712 Each ``.mo`` file represents a set of translations for a language
713 in a :term:`translation domain`. The name of the ``.mo`` file
714 (minus the .mo extension) is the translation domain name.
716 Localizer
717 An instance of the class :class:`pyramid.i18n.Localizer` which
718 provides translation and pluralization services to an
719 application. It is retrieved via the
720 :func:`pyramid.i18n.get_localizer` function.
722 Locale Name
723 A string like ``en``, ``en_US``, ``de``, or ``de_AT`` which
724 uniquely identifies a particular locale.
726 Default Locale Name
727 The :term:`locale name` used by an application when no explicit
728 locale name is set. See :ref:`localization_deployment_settings`.
730 Locale Negotiator
731 An object supplying a policy determining which :term:`locale
732 name` best represents a given :term:`request`. It is used by the
733 :func:`pyramid.i18n.get_locale_name`, and
734 :func:`pyramid.i18n.negotiate_locale_name` functions, and
735 indirectly by :func:`pyramid.i18n.get_localizer`. The
736 :func:`pyramid.i18n.default_locale_negotiator` function
737 is an example of a locale negotiator.
739 Gettext
740 The GNU `gettext <>`_
741 library, used by the :app:`Pyramid` translation machinery.
743 Babel
744 A `collection of tools <>`_ for
745 internationalizing Python applications. :app:`Pyramid` does
746 not depend on Babel to operate, but if Babel is installed,
747 additional locale functionality becomes available to your
748 application.
750 Message Identifier
751 A string used as a translation lookup key during localization.
752 The ``msgid`` argument to a :term:`translation string` is a
753 message identifier. Message identifiers are also present in a
754 :term:`message catalog`.
756 Message Catalog
757 A :term:`gettext` ``.mo`` file containing translations.
759 Internationalization
760 The act of creating software with a user interface that can
761 potentially be displayed in more than one language or cultural
762 context. Often shortened to "i18n" (because the word
763 "internationalization" is I, 18 letters, then N). See also:
764 :term:`Localization`.
766 Localization
767 The process of displaying the user interface of an
768 internationalized application in a particular language or
769 cultural context. Often shortened to "l10" (because the word
770 "localization" is L, 10 letters, then N). See also:
771 :term:`Internationalization`.
773 renderer globals
774 Values injected as names into a renderer based on application
775 policy. See :ref:`adding_renderer_globals` for more
776 information.
778 response callback
779 A user-defined callback executed by the :term:`router` at a
780 point after a :term:`response` object is successfully created.
781 See :ref:`using_response_callbacks`.
783 finished callback
784 A user-defined callback executed by the :term:`router`
785 unconditionally at the very end of request processing . See
786 :ref:`using_finished_callbacks`.
788 pregenerator
789 A pregenerator is a function associated by a developer with a
790 :term:`route`. It is called by :func:`pyramid.url.route_url`
791 in order to adjust the set of arguments passed to it by the user
792 for special purposes. It will influence the URL returned by
793 ``route_url``. See
794 :class:`pyramid.interfaces.IRoutePregenerator` for more
795 information.
797 session
798 A namespace that is valid for some period of continual activity
799 that can be used to represent a user's interaction with a web
800 application.
802 session factory
803 A callable, which, when called with a single argument named
804 ``request`` (a :term:`request` object), returns a
805 :term:`session` object.
807 Mako
808 `Mako <>`_ is a template language language
809 which refines the familiar ideas of componentized layout and inheritance
810 using Python with Python scoping and calling semantics.
812 View handler
813 A view handler ties together
814 :meth:`pyramid.config.Configurator.add_route` and
815 :meth:`pyramid.config.Configurator.add_view` to make it more convenient
816 to register a collection of views as a single class when using
817 :term:`url dispatch`. View handlers ship as part of the
818 :term:`pyramid_handlers` add-on package.
820 Deployment settings
821 Deployment settings are settings passed to the :term:`Configurator` as a
822 ``settings`` argument. These are later accessible via a
823 ``request.registry.settings`` dictionary. Deployment settings can be
824 used as global application values.
826 WebTest
827 `WebTest <>`_ is a package which can help
828 you write functional tests for your WSGI application.
830 WebError
831 WSGI middleware which can display debuggable traceback information in
832 the browser when an exception is raised by a Pyramid application. See
833 .
835 view mapper
836 A view mapper is a class which implements the
837 :class:`pyramid.interfaces.IViewMapperFactory` interface, which performs
838 view argument and return value mapping. This is a plug point for
839 extension builders, not normally used by "civilians".
841 matchdict
842 The dictionary attached to the :term:`request` object as
843 ``request.matchdict`` when a :term:`URL dispatch` route has been matched.
844 Its keys are names as identified within the route pattern; its values are
845 the values matched by each pattern name.
847 pyramid_zcml
848 An add-on package to :app:`Pyramid` which allows applications to be
849 configured via ZCML. It is available on :term:`PyPI`. If you use
850 ``pyramid_zcml``, you can use ZCML as an alternative to
851 :term:`imperative configuration`.
853 ZCML
854 `Zope Configuration Markup Language
855 <>`_, an XML dialect
856 used by Zope and :term:`pyramid_zcml` for configuration tasks.
858 ZCML directive
859 A ZCML "tag" such as ``<view>`` or ``<route>``.
861 ZCML declaration
862 The concrete use of a :term:`ZCML directive` within a ZCML file.
864 pyramid_handlers
865 An add-on package which allows :app:`Pyramid` users to create classes
866 that are analogues of Pylons 1 "controllers". See
867 .
869 pyramid_jinja2
870 :term:`Jinja2` templating system bindings for Pyramid, documented at
871 . This
872 package also includes a paster template named
873 ``pyramid_jinja2_starter``, which creates an application package based
874 on the Jinja2 templating system.
876 pyramid_sqla
877 A package which provides a Pylons-esque paster template which sports
878 support for :term:`view handler` application development,
879 :term:`SQLAlchemy` support, and other Pylons-like features. See
880 for more
881 information.
883 Pyramid Cookbook
884 An additional documentation resource for Pyramid which presents topical,
885 practical usages of Pyramid available via
886 .
888 distutils
889 The standard system for packaging and distributing Python packages. See
890 for more information.
891 :term:`setuptools` is actually an *extension* of the Distutils.
Something went wrong with that request. Please try again.