pylons.templating includes several basic render functions,
render_mako(), render_genshi() and render_jinja2()
that render templates from the file-system with the assumption that
variables intended for the will be attached to tmpl_context
(hereafter referred to by its short name of c which it is
commonly imported as).
The default render functions work with the template language loader
object that is setup on the app_globals object in the project’s
config/environment.py.
Generally, one of the render functions will be imported in the
controller. Variables intended for the template are attached to the
c object. The render functions return unicode (they actually
return literal objects, a subclass of
unicode).
Tip
tmpl_context (template context) is abbreviated to c
instead of its full name since it will likely be used extensively
and it’s much faster to use c. Of course, for users that
can’t tolerate one-letter variables, feel free to not import
tmpl_context as c since both names are available in
templates as well.
Example of rendering a template with some variables:
Templates rendered in Pylons should include the default Pylons globals
as the render_mako(), render_genshi() and
render_jinja2() functions. The full list of Pylons globals that
are included in the template’s namespace are:
The template engine is created in the projects
config/environment.py and attached to the app_globals (g)
instance. Configuration options can be directly passed into the
template engine, and are used by the render functions.
Warning
Don’t change the variable name on app_globals that the
template loader is attached to if you want to use the render_*
functions that pylons.templating comes with. The render_*
functions look for the template loader to render the template.
Cache a template to the namespace template_name, along with a
specific key if provided.
Basic Options
template_name
Name of the template, which is used as the template namespace.
render_func
Function used to generate the template should it no longer be
valid or doesn’t exist in the cache.
ns_options
Tuple of strings, that should correspond to keys likely to be
in the kwargs that should be used to construct the
namespace used for the cache. For example, if the template
language supports the ‘fragment’ option, the namespace should
include it so that the cached copy for a template is not the
same as the fragment version of it.
Caching options (uses Beaker caching middleware)
cache_key
Key to cache this copy of the template under.
cache_type
Valid options are dbm, file, memory, database,
or memcached.
cache_expire
Time in seconds to cache this template with this cache_key
for. Or use ‘never’ to designate that the cache should never
expire.
The minimum key required to trigger caching is
cache_expire='never' which will cache the template forever
seconds with no key.
Accepts the cache options cache_key, cache_type, and
cache_expire in addition to method which are passed to Genshi’s
render function.
app_globals
One instance of Globals is created during application
initialization and is available during requests via the
‘app_globals’ variable. Useful for any given object which
should be shared across the application.
c
The template context object, available when a template is
being processed. c is an alias for
tmpl_context
g
The application globals object. g is an alias for
app_globals
h
A reference to the project helpers module.
tmpl_context
The template context object, a place to store all the data for
use in a template. This includes form data, user identity, and
the like.