Navigation

repoze.bfg.view

render_view_to_response(context, request, name='', secure=True)

Call the view callable configured with a view configuration that matches the view name name registered against the specified context and request and return a response object. This function will return None if a corresponding view callable cannot be found (when no view configuration matches the combination of name / context / and request).

If secure` is True, and the view callable found is protected by a permission, the permission will be checked before calling the view function. If the permission check disallows view execution (based on the current authorization policy), a repoze.bfg.exceptions.Forbidden exception will be raised. The exception’s args attribute explains why the view access was disallowed.

If secure is False, no permission checking is done.

render_view_to_iterable(context, request, name='', secure=True)

Call the view callable configured with a view configuration that matches the view name name registered against the specified context and request and return an iterable object which represents the body of a response. This function will return None if a corresponding view callable cannot be found (when no view configuration matches the combination of name / context / and request). Additionally, this function will raise a ValueError if a view function is found and called but the view function’s result does not have an app_iter attribute.

You can usually get the string representation of the return value of this function by calling ''.join(iterable), or just use repoze.bfg.view.render_view() instead.

If secure is True, and the view is protected by a permission, the permission will be checked before the view function is invoked. If the permission check disallows view execution (based on the current authentication policy), a repoze.bfg.exceptions.Forbidden exception will be raised; its args attribute explains why the view access was disallowed.

If secure is False, no permission checking is done.

render_view(context, request, name='', secure=True)

Call the view callable configured with a view configuration that matches the view name name registered against the specified context and request and unwind the view response’s app_iter (see View Callable Responses) into a single string. This function will return None if a corresponding view callable cannot be found (when no view configuration matches the combination of name / context / and request). Additionally, this function will raise a ValueError if a view function is found and called but the view function’s result does not have an app_iter attribute. This function will return None if a corresponding view cannot be found.

If secure is True, and the view is protected by a permission, the permission will be checked before the view is invoked. If the permission check disallows view execution (based on the current authorization policy), a repoze.bfg.exceptions.Forbidden exception will be raised; its args attribute explains why the view access was disallowed.

If secure is False, no permission checking is done.

is_response(ob)

Return True if ob implements the interface implied by View Callable Responses. False if not.

Note

this isn’t a true interface check (in Zope terms), it’s a duck-typing check, as response objects are not obligated to actually implement a Zope interface.

class bfg_view(name='', request_type=None, for_=None, permission=None, route_name=None, request_method=None, request_param=None, containment=None, attr=None, renderer=None, wrapper=None, xhr=False, accept=None, header=None, path_info=None, custom_predicates=(), context=None)

A function, class or method decorator which allows a developer to create view registrations nearer to a view callable definition than use of ZCML or imperative configuration to do the same.

For example, this code in a module views.py:

from models import MyModel

@bfg_view(name='my_view', context=MyModel, permission='read',
          route_name='site1')
def my_view(context, request):
    return 'OK'

Might replace the following call to the repoze.bfg.configuration.Configurator.add_view() method:

import views
import models
config.add_view(views.my_view, context=models.MyModel, name='my_view',
                permission='read', 'route_name='site1')

Or might replace the following ZCML view declaration:

<view
 for='.models.MyModel'
 view='.views.my_view'
 name='my_view'
 permission='read'
 route_name='site1'
 />

The following arguments are supported as arguments to bfg_view: context, permission, name, request_type, route_name, request_method, request_param, containment, xhr, accept, header and path_info.

If context is not supplied, the interface zope.interface.Interface (matching any context) is used. An alias for context is for_.

If permission is not supplied, no permission is registered for this view (it’s accessible by any caller).

If name is not supplied, the empty string is used (implying the default view name).

If attr is not supplied, None is used (implying the function itself if the view is a function, or the __call__ callable attribute if the view is a class).

If renderer is not supplied, None is used (meaning that no renderer is associated with this view).

If wrapper is not supplied, None is used (meaning that no view wrapper is associated with this view).

If request_type is not supplied, the interface repoze.bfg.interfaces.IRequest is used, implying the standard request interface type.

If route_name is not supplied, the view configuration is considered to be made against a URL that doesn’t match any defined route. The use of a route_name is an advanced feature, useful only if you’re also using url dispatch.

If request_method is not supplied, this view will match a request with any HTTP REQUEST_METHOD (GET/POST/PUT/HEAD/DELETE). If this parameter is supplied, it must be a string naming an HTTP REQUEST_METHOD, indicating that this view will only match when the current request has a REQUEST_METHOD that matches this value.

If request_param is not supplied, this view will be called when a request with any (or no) request GET or POST parameters is encountered. If the value is present, it must be a string. If the value supplied to the parameter has no = sign in it, it implies that the key must exist in the request.params dictionary for this view to ‘match’ the current request. If the value supplied to the parameter has a = sign in it, e.g. request_params="foo=123", then the key (foo) must both exist in the request.params dictionary, and the value must match the right hand side of the expression (123) for the view to “match” the current request.

If containment is not supplied, this view will be called when the context of the request has any (or no) lineage. If containment is supplied, it must be a class or interface, denoting that the view ‘matches’ the current request only if any graph lineage node possesses this class or interface.

If xhr is specified, it must be a boolean value. If the value is True, the view will only be invoked if the request’s X-Requested-With header has the value XMLHttpRequest.

If accept is specified, it must be a mimetype value. If accept is specified, the view will only be invoked if the Accept HTTP header matches the value requested. See the description of accept in view for information about the allowable composition and matching behavior of this value.

If header is specified, it must be a header name or a headername:headervalue pair. If header is specified, and possesses a value the view will only be invoked if an HTTP header matches the value requested. If header is specified without a value (a bare header name only), the view will only be invoked if the HTTP header exists with any value in the request. See the description of header in view for information about the allowable composition and matching behavior of this value.

If path_info is specified, it must be a regular expression. The view will only be invoked if the PATH_INFO WSGI environment variable matches the expression.

If custom_predicates is specified, it must be a sequence of predicate callables (a predicate callable accepts two arguments: context and request and returns True or False). The view will only be invoked if all custom predicates return True.

Any individual or all parameters can be omitted. The simplest bfg_view declaration is:

@bfg_view()
def my_view(...):
    ...

Such a registration implies that the view name will be my_view, registered for any context object, using no permission, registered against all non-URL-dispatch-based requests, with any REQUEST_METHOD, any set of request.params values, without respect to any object in the lineage.

The bfg_view decorator can also be used as a class decorator in Python 2.6 and better (Python 2.5 and below do not support class decorators):

from webob import Response
from repoze.bfg.view import bfg_view

@bfg_view()
class MyView(object):
    def __init__(self, context, request):
        self.context = context
        self.request = request
    def __call__(self):
        return Response('hello from %s!' % self.context)

In Python 2.5 and below, the bfg_view decorator can still be used against a class, although not in decorator form:

from webob import Response
from repoze.bfg.view import bfg_view

class MyView(object):
    def __init__(self, context, request):
        self.context = context
        self.request = request
    def __call__(self):
        return Response('hello from %s!' % self.context)

MyView = bfg_view()(MyView)

Note

When a view is a class, the calling semantics are different than when it is a function or another non-class callable. See Defining a View Callable as a Class for more information.

Warning

Using a class as a view is a new feature in 0.8.1+.

The bfg_view decorator can also be used against a class method:

from webob import Response
from repoze.bfg.view import bfg_view

class MyView(object):
    def __init__(self, context, request):
        self.context = context
        self.request = request

    @bfg_view(name='hello')
    def amethod(self):
        return Response('hello from %s!' % self.context)

When the bfg_view decorator is used against a class method, a view is registered for the class (as described above), so the class constructor must accept either request or context, request. The method which is decorated must return a response (or rely on a renderer to generate one). Using the decorator against a particular method of a class is equivalent to using the attr parameter in a decorator attached to the class itself. For example, the above registration implied by the decorator being used against the amethod method could be spelled equivalently as:

from webob import Response
from repoze.bfg.view import bfg_view

@bfg_view(attr='amethod', name='hello')
class MyView(object):
    def __init__(self, context, request):
        self.context = context
        self.request = request

    def amethod(self):
        return Response('hello from %s!' % self.context)

Warning

The ability to use the bfg_view decorator as a method decorator is new in repoze.bfg version 1.1.

To make use of any bfg_view declaration, you must perform a scan. To do so, either insert the following boilerplate into your application registry’s ZCML:

<scan package="."/>

See scan for more information about the ZCML scan directive.

Or, if you don’t use ZCML, use the repoze.bfg.configuration.Configurator.scan() method:

config.scan()
class static(root_dir, cache_max_age=3600, package_name=None)

An instance of this class is a callable which can act as a repoze.bfg view callable; this view will serve static files from a directory on disk based on the root_dir you provide to its constructor.

The directory may contain subdirectories (recursively); the static view implementation will descend into these directories as necessary based on the components of the URL in order to resolve a path into a response.

You may pass an absolute or relative filesystem path or a resource specification representing the directory containing static files as the root_dir argument to this class’ constructor.

If the root_dir path is relative, and the package_name argument is None, root_dir will be considered relative to the directory in which the Python file which calls static resides. If the package_name name argument is provided, and a relative root_dir is provided, the root_dir will be considered relative to the Python package specified by package_name (a dotted path to a Python package).

cache_max_age influences the Expires and Max-Age response headers returned by the view (default is 3600 seconds or five minutes).

Note

If the root_dir is relative to a package, or is a resource specification the repoze.bfg resource ZCML directive or repoze.bfg.configuration.Configurator method can be used to override resources within the named root_dir package-relative directory. However, if the root_dir is absolute, the resource directive will not be able to override the resources it contains.

append_slash_notfound_view(context, request)

For behavior like Django’s APPEND_SLASH=True, use this view as the Not Found view in your application.

When this view is the Not Found view (indicating that no view was found), and any routes have been defined in the configuration of your application, if the value of the PATH_INFO WSGI environment variable does not already end in a slash, and if the value of PATH_INFO plus a slash matches any route’s path, do an HTTP redirect to the slash-appended PATH_INFO. Note that this will lose POST data information (turning it into a GET), so you shouldn’t rely on this to redirect POST requests.

If you use ZCML, add the following to your application’s configure.zcml to use this view as the Not Found view:

<notfound
   view="repoze.bfg.view.append_slash_notfound_view"/>

Or use the repoze.bfg.configuration.Configurator.set_notfound_view() method if you don’t use ZCML:

from repoze.bfg.view import append_slash_notfound_view
config.set_notfound_view(append_slash_notfound_view)

See also Changing the Not Found View.

Note

This function is new as of repoze.bfg version 1.1.

Previous topic

repoze.bfg.url

Next topic

repoze.bfg.wsgi

This Page

Navigation

© Copyright 2008-2010, Agendaless Consulting. Last updated on May 01, 2010. Created using Sphinx 0.6.3.