 |
 |
 |
Aspen |  |
|
|
|
|
|
Aspen | |
|
|
Aspen uses Python's WSGI specification for its extension architecture. There are three categories of extension:
| Category | Explanation |
|---|---|
| applications | applications are connected to directories within the site hierarchy; only one app touches any given request |
| handlers | handlers are tied to individual resources (i.e., files) based on extensible rules; only one handler touches any given request |
| middleware | one or many middleware applications may be specified; all middleware generally touches every request |
All extensions are WSGI callables, connected to the above entry points with three configuration files in __/etc:
Where called for in these files, objects are specified in a notation derived
from setuptools' entry_points feature: a dotted module name, followed by a colon
and a dotted identifier naming an object within the module. This is referred to
below as colon notation. The following example would import the bar
object from example.package.foo, and use its baz attribute (a WSGI
callable):
example.package.foo:bar.baz
For applications and handlers, when names in colon notation point to a class,
Aspen attempts to instantiate the class with the current Website
instance as its sole positional argument. Failing this, Aspen instantiates the
class without any arguments. The instance is then used as the named object. At
run-time, applications and handlers can also access the Website instance
at environ['aspen.website'].
Middleware constructors are always called with one positional argument, which is the next middleware on the stack.
The comment character for these files is #, and comments can be included in-line. Blank lines are ignored, as is initial and trailing whitespace per-line. Where section names are called for, they are given in brackets.
|
|
|
Aspen | |
|
|