11.2. SYSTEM VALUES USED DURING RENDERING
If you need more control over the status code and content-type, or other response attributes from views that use direct templating, you may set attributes on the response that influence these values.
Here’s an example of changing the content-type and status of the response object returned by render_to_response():
1 from pyramid.renderers import render_to_response
2
3 def sample_view(request):
4response = render_to_response(’templates/foo.pt’,
5 |
|
{’foo’:1, ’bar’:2}, |
6 |
|
request=request) |
7 |
response.content_type |
= ’text/plain’ |
8 |
response.status_int = |
204 |
9return response
Here’s an example of manufacturing a response object using the result of render() (a string):
1 |
from pyramid.renderers import render |
2 |
from pyramid.response import Response |
3 |
|
4 |
def sample_view(request): |
5result = render(’mypackage:templates/foo.pt’,
6 |
{’foo’:1, ’bar’:2}, |
7 |
request=request) |
8response = Response(result)
9 response.content_type = ’text/plain’
10 return response
11.2 System Values Used During Rendering
When a template is rendered using render_to_response() or render(), the renderer representing the template will be provided with a number of system values. These values are provided in a dictionary to the renderer and include:
context The current Pyramid context if request was provided as a keyword argument, or None.
request The request provided as a keyword argument.
125
11. TEMPLATES
renderer_name The renderer name used to perform the rendering, e.g. mypackage:templates/foo.pt.
renderer_info An object implementing the pyramid.interfaces.IRendererInfo interface. Basically, an object with the following attributes: name, package and type.
You can define more values which will be passed to every template executed as a result of rendering by defining renderer globals.
What any particular renderer does with these system values is up to the renderer itself, but most template renderers, including Chameleon and Mako renderers, make these names available as top-level template variables.
11.3 Templates Used as Renderers via Configuration
An alternative to using render_to_response() to render templates manually in your view callable code, is to specify the template as a renderer in your view configuration. This can be done with any of the templating languages supported by Pyramid.
To use a renderer via view configuration, specify a template asset specification as the renderer argument, or attribute to the view configuration of a view callable. Then return a dictionary from that view callable. The dictionary items returned by the view callable will be made available to the renderer template as top-level names.
The association of a template as a renderer for a view configuration makes it possible to replace code within a view callable that handles the rendering of a template.
Here’s an example of using a view_config decorator to specify a view configuration that names a template renderer:
1
2
3
4
5
from pyramid.view import view_config
@view_config(renderer=’templates/foo.pt’) def my_view(request):
return {’foo’:1, ’bar’:2}
126
11.3. TEMPLATES USED AS RENDERERS VIA CONFIGURATION
latex-note.png
You do not need to supply the request value as a key in the dictionary result returned from a renderer-configured view callable. Pyramid automatically supplies this value for you so that the “most correct” system values are provided to the renderer.
latex-warning.png
The renderer argument to the @view_config configuration decorator shown above is the template path. In the example above, the path templates/foo.pt is relative. Relative to what, you ask? Because we’re using a Chameleon renderer, it means “relative to the directory in which the file which defines the view configuration lives”. In this case, this is the directory containing the file that defines the my_view function. View-configuration-relative asset specifications work only in Chameleon, not in Mako templates.
Similar renderer configuration can be done imperatively. See Writing View Callables Which Use a Renderer. See also Built-In Renderers.
Although a renderer path is usually just a simple relative pathname, a path named as a renderer can be absolute, starting with a slash on UNIX or a drive letter prefix on Windows. The path can alternately be an asset specification in the form some.dotted.package_name:relative/path, making it possible to address template assets which live in another package.
Not just any template from any arbitrary templating system may be used as a renderer. Bindings must exist specifically for Pyramid to use a templating language template as a renderer. Currently, Pyramid has built-in support for two Chameleon templating languages: ZPT and text, and the Mako templating system. See Built-In Renderers for a discussion of their details. Pyramid also supports the use of Jinja2 templates as renderers. See Available Add-On Template System Bindings.
127