blob: fdc67b19107e829185c85f790f0a13bfddff2bc7 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
Next release
============
Features
--------
- Added "exception views". When you use an exception (anything that
inherits from the Python ``Exception`` builtin) as view context
argument, e.g.::
from repoze.bfg.view import bfg_view
from repoze.bfg.exceptions import NotFound
from webob.exc import HTTPNotFound
@bfg_view(context=NotFound)
def notfound_view(request):
return HTTPNotFound()
For the above example, when the ``repoze.bfg.exceptions.NotFound``
exception is raised by any view or any root factory, the
``notfound_view`` view callable wil be invoked and its response
returned.
Other normal view predicates can also be used in combination with an
exception view registration:
from repoze.bfg.view import bfg_view
from repoze.bfg.exceptions import NotFound
from webob.exc import HTTPNotFound
@bfg_view(context=NotFound, route_name='home')
def notfound_view(request):
return HTTPNotFound()
The above exception view names the ``route_name`` of ``home``,
meaning that it will only be called when the route matched has a
name of ``home``. You can therefore have more than one exception
view for any given exception in the system: the "most specific" one
will be called when the set of request circumstances which match the
view registration. The only predicate that cannot be not be used
successfully is ``name``. The name used to look up an exception
view is always the empty string.
Existing (pre-1.3) normal views registered against objects
inheriting from ``Exception`` will continue to work. Exception
views used for user-defined exceptions and system exceptions used as
contexts will also work.
The feature can be used with any view registration mechanism
(``@bfg_view`` decorator, ZCML, or imperative ``config.add_view``
styles).
This feature was kindly contributed by Andrey Popp.
- Use "Venusian" (`http://docs.repoze.org/venusian
<http://docs.repoze.org/venusian>`_) to perform ``bfg_view``
decorator scanning rather than relying on a BFG-internal decorator
scanner. (Truth be told, Venusian is really just a generalization
of the BFG-internal decorator scanner).
Deprecations
------------
- The exception views feature replaces the need for the
``set_notfound_view`` and ``set_forbidden_view`` methods of the
``Configurator`` as well as the ``notfound`` and ``forbidden`` ZCML
directives. Those methods and directives will continue to work for
the foreseeable future, but they are deprecated in the
documentation.
Dependencies
------------
- A new install-time dependency on the ``venusian`` distribution was
added.
Internal
--------
- View registrations and lookups are now done with three "requires"
arguments instead of two to accomodate orthogonality of exception
views.
- The ``repoze.bfg.interfaces.IForbiddenView`` and
``repoze.bfg.interfaces.INotFoundView`` interfaces were removed;
they weren't APIs and they became vestigial with the addition of
exception views.
- Remove ``repoze.bfg.compat.pkgutil_26.py`` and import alias
``repoze.bfg.compat.walk_packages``. These were only required by
internal scanning machinery; Venusian replaced the internal scanning
machinery, so these are no longer required.
Documentation
-------------
- Exception view documentation was added to the ``Hooks`` narrative
chapter.
|
