WSGI Deliverance Synopsis
A cheat sheet describing the WSGI deliverance_ filter, by which thematic layouts are imposed on pages from WSGI-aware python applications.
WSGI deliverance configuration is intricate and extensive, and i struggle to tie together various bits as they are organized in the deliverance configuration document [as of march, 2010]. so i distilled and often rephrased several parts, particularly those having to do with the transformation rules. i do not address proxy server settings.
the info is derived from v 0.3 of the Deliverance Configuration page. that page includes many illuminating examples not included here.
(emacs table mode was terrifically handy for concocting the tables in the reStructuredText source for this document.)
what is python deliverance?
python deliverance is WSGI middleware (a web service application filtering layer) which applies rules that substitute html content elements into (usually) html theme templates.
see this (old but good) deliverance introduction for more background. see PloneWithWSGI for the context in which i'm exploring deliverance.
key terms
|
---|
the configuration file elements
the deliverance configuration file dictates deliverance transformation and other operations using a set of xml elements within an encompassing <ruleset> element.
the ruleset element
all the deliverance configuration file sections reside within a <ruleset> xml element:
<ruleset>
<theme ...>
<rule ...>
<rule ...>
...
<ruleset>
the theme element
the theme element identifies the page used as the theme layout code.
when a <theme> element resides at the top level of a <ruleset> element it specifies the overall default theme. when residing within a <rule> element, it applies just to that element's set of rules.
|
---|
the rule element
the <rule> element is a container for rule actions. the actions intersperse elements from the content within the theme.
each rule can identify a particular page, distinct from the encompassing ruleset theme, by including a theme element.
rules can be conditioned to apply to specific parts of a site using page classes andrequest/response matching,
by default, the rule element includes several standard rule actions. these default actions can be suppressed by including suppress-standard="1" in the rule:
<rule suppress-standard="1">
rule actions
|
---|
- the actions apply to target elements within the content and/or theme. these targets are designated using rule element selectors
- the rules take optional attributes <#optional_rule_attributes> which adjust their behavior.
rule element selectors
each action specifies target elements within the content and/or the theme using path expressions. there are two types of selector expression paths:
|
---|
rules act on the designated elements or entities related to those elements, according to selection target type. the selection target type is indicated as a prefix on the attribute value, eg <dropcontent="tag:ul">.
rule selection target types
|
---|
not all selection target type combinations across theme and content make sense. eg you can't replace elements with attributes. generally, only elements: and children: work together.
you can specify fall-back selector target types by using the || operators, which yield the effect of the first selector that has a non-empty match.
- eg, content="#content || children:body" will match the element with the idcontent, if any, else all the children of <body>.
- || expressions can include both CSS and !XPath selectors.
- || expressions can only mix elements: and children: selection types
optional rule attributes
rule behavior can be further qualified with some optional attributes:
|
---|
several optional rule action attributes adjust behavior when a selector does not match exactly one element, which is required for all the action types except for <drop>. the default handling is to log the problem at the level "warn", and for unexpected multiple matches, to log and use the first element. these are the four attributes to adjust the default behavior:
|
---|
|
---|
the deliverance documentation rule section includes more info, including particularly examples for each rule.
match and page classes
different sets of rules can be applied to different parts of a site by using page classes.
for example, for a page has the classes trac and default, these rules could be used:
<rule class="trac">...</rule>
<rule class="default">...</rule>
- like CSS, any rules that match any of the classes on a page will be run
- like CSS, you can have multiple classes anywhere, separated by spaces
- unlike CSS, the classes are ordered, and define the run-order of the rules
page classes can be assigned in a few ways:
- via the server adding the response header X-Deliverance-Page-Class to identify each page's classes
- using deliverance' proxy server, adding a class attribute to proxy elements.
- using <match> configuration, discriminating class according to request/response matching on path or domain
request matching is described in request/response matching.
request/response matching
three deliverance configuration elements can be conditionally used according to request or response matches:
- <match>
- <rule>
- <proxy>
all these elements share common behavior and attributes.
several attributes can match against different parts of the request or response. when multiple attribute are provided then they must all match.
|
---|
|
---|
|
---|
request/response matches often involve string patterns to be matched against the target document elements. there are several varieties of match operations, suited to different purposes, that can be employed. in cases where the the pattern type is optional (like the string match target type), the variety of pattern is indicated by prefixing one of the variety types (with the ':' colon) in front of the pattern, itself.
|
---|
proxy and server settings
this section controls deliverance when it is deployed as a proxy server, affecting proxy destinations, server, and security settings.
i use paste rather than the deliverance proxy to incorporate deliverance, so have no experience with the proxy, and no info to offer beyond the link to the deliverance configuration proxy and server-settings section.
pyref python references
extend several elements by plugging in your own python functions via hooks.
debug reporting
deliverance can present some debugging info at the bottom of a visited page, if debugging is turned on. to see a trace of the deliverance actions at the bottom of a deliverance-transformed page, visit the url of the page with ?deliv_log appended. scroll down to the bottom of the page to see a table detailing the deliverance actions.