Файл: pyramid.pdf

CHAPTER

FIFTYTWO

PYRAMID.REGISTRY

class Registry(name=’‘, bases=())

A registry object is an application registry. It is used by the framework itself to perform mappings of URLs to view callables, as well as servicing other various framework duties. A registry has its own internal API, but this API is rarely used by Pyramid application developers (it’s usually only used by developers of the Pyramid framework). But it has a number of attributes that may be useful to application developers within application code, such as settings, which is a dictionary containing application deployment settings.

For information about the purpose and usage of the application registry, see Using the Zope Component Architecture in Pyramid.

The application registry is usually accessed as request.registry in application code.

settings

The dictionary-like deployment settings object. See Deployment Settings for information. This object is often accessed as request.registry.settings or config.registry.settings in a typical Pyramid application.

pyramid.config.Configurator.introspector‘.

When a registry is created “by hand”, however, this attribute will not exist until set up by a configurator.

This attribute is often accessed as request.registry.introspector in a typical Pyramid application.

This attribute is new as of Pyramid 1.3.

611

52. PYRAMID.REGISTRY

class Introspectable

The default implementation of the interface pyramid.interfaces.IIntrospectable used by framework exenders. An instance of this class is is created when pyramid.config.Configurator.introspectable is called.

This class is new as of Pyramid 1.3.

612

CHAPTER

FIFTYTHREE

PYRAMID.RENDERERS

get_renderer(renderer_name, package=None)

Return the renderer object for the renderer named as renderer_name.

You may supply a relative asset spec as renderer_name. If the package argument is supplied, a relative renderer name will be converted to an absolute asset specification by combining the package supplied as package with the relative asset specification supplied as renderer_name. If you do not supply a package (or package is None) the package name of the caller of this function will be used as the package.

render(renderer_name, value, request=None, package=None)

Using the renderer specified as renderer_name (a template or a static renderer) render the value (or set of values) present in value. Return the result of the renderer’s __call__ method (usually a string or Unicode).

If the renderer name refers to a file on disk (such as when the renderer is a template), it’s usually best to supply the name as a asset specification (e.g. packagename:path/to/template.pt).

You may supply a relative asset spec as renderer_name. If the package argument is supplied, a relative renderer path will be converted to an absolute asset specification by combining the package supplied as package with the relative asset specification supplied as renderer_name. If you do not supply a package (or package is None) the package name of the caller of this function will be used as the package.

The value provided will be supplied as the input to the renderer. Usually, for template renderings, this should be a dictionary. For other renderers, this will need to be whatever sort of value the renderer expects.

The ‘system’ values supplied to the renderer will include a basic set of top-level system names, such as request, context, and renderer_name. If renderer globals have been specified, these will also be used to agument the value.

Supply a request parameter in order to provide the renderer with the most correct ‘system’ values (request and context in particular).

613

53. PYRAMID.RENDERERS

render_to_response(renderer_name, value, request=None, package=None)

Using the renderer specified as renderer_name (a template or a static renderer) render the value (or set of values) using the result of the renderer’s __call__ method (usually a string or Unicode) as the response body.

If the renderer name refers to a file on disk (such as when the renderer is a template), it’s usually best to supply the name as a asset specification.

You may supply a relative asset spec as renderer_name. If the package argument is supplied, a relative renderer name will be converted to an absolute asset specification by combining the package supplied as package with the relative asset specification supplied as renderer_name. If you do not supply a package (or package is None) the package name of the caller of this function will be used as the package.

The value provided will be supplied as the input to the renderer. Usually, for template renderings, this should be a dictionary. For other renderers, this will need to be whatever sort of value the renderer expects.

The ‘system’ values supplied to the renderer will include a basic set of top-level system names, such as request, context, and renderer_name. If renderer globals have been specified, these will also be used to agument the value.

Supply a request parameter in order to provide the renderer with the most correct ‘system’ values (request and context in particular). Keep in mind that if the request parameter is not passed in, any changes to request.response attributes made before calling this function will be ignored.

class JSONP(param_name=’callback’)

JSONP renderer factory helper which implements a hybrid json/jsonp renderer. JSONP is useful for making cross-domain AJAX requests.

Configure a JSONP renderer using the pyramid.config.Configurator.add_renderer()

API at application startup time:

from pyramid.config import Configurator

config = Configurator()

config.add_renderer(’jsonp’, JSONP(param_name=’callback’))

Once this renderer is registered via add_renderer() as above, you can use jsonp as the renderer= parameter to @view_config or pyramid.config.Configurator.add_view‘():

614

from pyramid.view import view_config

@view_config(renderer=’jsonp’) def myview(request):

return {’greeting’:’Hello world’}

When a view is called that uses the JSONP renderer:

•If there is a parameter in the request’s HTTP query string that matches the param_name of the registered JSONP renderer (by default, callback), the renderer will return a JSONP response.

•If there is no callback parameter in the request’s query string, the renderer will return a ‘plain’ JSON response.

latex-note.png

This feature is new in Pyramid 1.1.

See also: JSONP Renderer.

null_renderer

An object that can be used in advanced integration cases as input to the view configuration renderer= argument. When the null renderer is used as a view renderer argument, Pyramid avoids converting the view callable result into a Response object. This is useful if you want to reuse the view configuration and lookup machinery outside the context of its use by the Pyramid router.

615

53. PYRAMID.RENDERERS

616

CHAPTER

FIFTYFOUR

PYRAMID.REQUEST

class Request(environ, charset=None, unicode_errors=None, decode_param_names=None,

**kw)

A subclass of the WebOb Request class. An instance of this class is created by the router and is provided to a view callable (and to other subsystems) as the request argument.

The documentation below (save for the add_response_callback and add_finished_callback methods, which are defined in this subclass itself, and the attributes context, registry, root, subpath, traversed, view_name, virtual_root , and virtual_root_path, each of which is added to the request by the router at request ingress time) are autogenerated from the WebOb source code used when this documentation was generated.

Due to technical constraints, we can’t yet display the WebOb version number from which this documentation is autogenerated, but it will be the ‘prevailing WebOb version’ at the time of the release of this Pyramid version. See http://pythonpaste.org/webob/ for further information.

context

The context will be available as the context attribute of the request object. It will be the context object implied by the current request. See Traversal for information about context objects.

registry

The application registry will be available as the registry attribute of the request object. See Using the Zope Component Architecture in Pyramid for more information about the application registry.

root

The root object will be available as the root attribute of the request object. It will be the resource object at which traversal started (the root). See Traversal for information about root objects.

617

54. PYRAMID.REQUEST

subpath

The traversal subpath will be available as the subpath attribute of the request object. It will be a sequence containing zero or more elements (which will be Unicode objects). See Traversal for information about the subpath.

traversed

The “traversal path” will be available as the traversed attribute of the request object. It will be a sequence representing the ordered set of names that were used to traverse to the context, not including the view name or subpath. If there is a virtual root associated with the request, the virtual root path is included within the traversal path. See Traversal for more information.

view_name

The view name will be available as the view_name attribute of the request object. It will be a single string (possibly the empty string if we’re rendering a default view). See Traversal for information about view names.

virtual_root

The virtual root will be available as the virtual_root attribute of the request object. It will be the virtual root object implied by the current request. See Virtual Hosting for more information about virtual roots.

virtual_root_path

The virtual root path will be available as the virtual_root_path attribute of the request object. It will be a sequence representing the ordered set of names that were used to traverse to the virtual root object. See Virtual Hosting for more information about virtual roots.

exception

If an exception was raised by a root factory or a view callable, or at various other points where Pyramid executes user-defined code during the processing of a request, the exception object which was caught will be available as the exception attribute of the request within a exception view, a response callback or a finished callback. If no exception occurred, the value of request.exception will be None within response and finished callbacks.

exc_info

If an exception was raised by a root factory or a view callable, or at various other points where Pyramid executes user-defined code during the processing of a request, result of sys.exc_info() will be available as the exc_info attribute of the request within a exception view, a response callback or a finished callback. If no exception occurred, the value of request.exc_info will be None within response and finished callbacks.

618