diff options
Diffstat (limited to 'CHANGES.txt')
| -rw-r--r-- | CHANGES.txt | 134 |
1 files changed, 122 insertions, 12 deletions
diff --git a/CHANGES.txt b/CHANGES.txt index fc86ac5b6..5dd17f4a4 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,6 +1,117 @@ Next release ============ +- The ``route`` ZCML directive now honors ``view_request_method``, + ``view_request_param`` and ``view_containment`` attributes, which + pass along these values to the associated view if any is provided. + Additionally, the ``request_type`` attribute can now be spelled as + ``view_request_type``, and ``permission`` can be spelled as + ``view_permission``. Any attribute which starts with ``view_`` can + now be spelled without the ``view_`` prefix, so ``view_for`` can be + spelled as ``for`` now, etc. Both forms are documented in the + urldispatch narraitve documentation chapter. + +- The ``request_param`` ZCML view directive attribute (and its + ``bfg_view`` decorator cousin) can now specify both a key and a + value. For example, ``request_param="foo=123"`` means that the foo + key must have a value of ``123`` for the view to "match". + +- Bugfix: the ``discriminator`` for the ZCML "route" directive was + incorrect. It was possible to register two routes that collided + without the system spitting out a ConfigurationConflictError at + startup time. + +- The ``static`` ZCML directive now uses a custom root factory when + constructing a route. + +- The ordering of route declarations vs. the ordering of view + declarations that use a "route_name" in ZCML no longer matters. + Previously it had been impossible to use a route_name from a route + that had not yet been defined in ZCML (order-wise) within a "view" + declaration. + +- The ``@bfg_view`` decorator now accepts three additional arguments: + ``request_method``, ``request_param``, and ``containment``. + ``request_method`` is used when you'd like the view to match only a + request with a particular HTTP ``REQUEST_METHOD``; a string naming + the ``REQUEST_METHOD`` can also be supplied as ``request_type`` for + backwards compatibility. ``request_param`` is used when you'd like + a view to match only a request that contains a particular + ``request.params`` key (with or without a value). ``containment`` + is used when you'd like to match a request that has a context that + has some class or interface in its graph lineage. These are + collectively known as "view predicates". + +- The interface ``IRequestFactories`` was removed from the + repoze.bfg.interfaces module. This interface was never an API. + +- The interfaces ``IPOSTRequest``, ``IGETRequest``, ``IPUTRequest``, + ``IDELETERequest``, and ``IHEADRequest`` have been removed from the + ``repoze.bfg.interfaces`` module. These were not documented as APIs + post-1.0. Instead of using one of these, use a ``request_method`` + ZCML attribute or ``request_method`` bfg_view decorator parameter + containing an HTTP method name (one of ``GET``, ``POST``, ``HEAD``, + ``PUT``, ``DELETE``) instead of one of these interfaces if you were + using one explicitly. Passing a string in the set (``GET``, + ``HEAD``, ``PUT``, ``POST``, ``DELETE``) as a ``request_type`` + argument will work too. Rationale: instead of relying on interfaces + attached to the request object, BFG now uses a "view predicate" to + determine the request type. + +- The function named ``named_request_factories`` and the data + structure named ``DEFAULT_REQUEST_FACTORIES`` have been removed from + the ``repoze.bfg.request`` module. These were never APIs. + +- Feature addition: view predicates. These are exposed as the + ``request_method``, ``request_param``, and ``containment`` + attributes of a ZCML ``view`` declaration, or the respective + arguments to a ``@bfg_view`` decorator. View predicates can be used + to register a view for a more precise set of environment parameters + than was previously possible. For example, you can register two + views with the same ``name`` with different ``request_param`` + attributes. If the ``request.params`` dict contains 'foo' + (request_param="foo"), one view might be called; if it contains + 'bar' (request_param="bar"), another view might be called. + ``request_param`` can also name a key/value pair ala ``foo=123``. + This will match only when the ``foo`` key is in the request.params + dict and it has the value '123'. This particular example makes it + possible to write separate view functions for different form + submissions. The other predicates, ``containment`` and + ``request_method`` work similarly. ``containment`` is a view + predicate that will match only when the context's graph lineage has + an object possessing a particular class or interface, for example. + ``request_method`` is a view predicate that will match when the HTTP + ``REQUEST_METHOD`` equals some string (eg. 'POST'). + +- The repoze.bfg router now catches both + ``repoze.bfg.security.Unauthorized`` and + ``repoze.bfg.view.NotFound`` exceptions while rendering a view. + When the router catches an ``Unauthorized``, it returns the + registered forbidden view. When the router catches a ``NotFound``, + it returns the registered notfound view. + +- Custom ZCML directives which register an authentication or + authorization policy (ala "authtktauthenticationpolicy" or + "aclauthorizationpolicy") should register the policy "eagerly" in + the ZCML directive instead of from within a ZCML action. If an + authentication or authorization policy is not found in the component + registry by the view machinery during deferred ZCML processing, view + security will not work as expected. + +- The API ``repoze.bfg.testing.registerViewPermission`` has been + deprecated. + +- The API ``repoze.bfg.testing.registerView`` now takes a + ``permission`` argument. Use this instead of using + ``repoze.bfg.testing.registerViewPermission``. + +- Removed ViewPermissionFactory from ``repoze.bfg.security``. View + permission checking is now done by registering and looking up an + ISecuredView. + +- Views registered without the help of the ZCML ``view`` directive are + now responsible for performing their own authorization checking. + - The ``repoze.bfg.view.static`` class now accepts a string as its first argument ("root_dir") that represents a package-relative name e.g. ``somepackage:foo/bar/static``. This is now the preferred @@ -975,12 +1086,12 @@ Features policy defaults to an authorization implementation that uses ACLs (``repoze.bfg.authorization.ACLAuthorizationPolicy``). - .. note:: we no longer encourage configuration of "security - policies" using ZCML, as previously we did for - ``ISecurityPolicy``. This is because it's not uncommon to need to - configure settings for concrete authorization or authentication - policies using paste .ini parameters; the app entry point for your - application is the natural place to do this. + We no longer encourage configuration of "security policies" using + ZCML, as previously we did for ``ISecurityPolicy``. This is because + it's not uncommon to need to configure settings for concrete + authorization or authentication policies using paste .ini + parameters; the app entry point for your application is the natural + place to do this. - Two new abstractions have been added in the way of adapters used by the system: an ``IAuthorizationPolicy`` and an @@ -1387,9 +1498,8 @@ Features source at installation time. In particular, ``repoze.bfg`` no longer depends on the ``lxml`` package. - .. note:: this change has introduced some backwards - incompatibilities, described in the "Backwards - Incompatibilities" section below. + This change has introduced some backwards incompatibilities, + described in the "Backwards Incompatibilities" section below. - This release was tested on Windows XP. It appears to work fine and all the tests pass. @@ -1565,7 +1675,7 @@ Backwards Incompatibilities opposed to URL-dispatch), and the root object supplied the``repoze.bfg.interfaces.ILocation`` interface, but the children returned via its ``__getitem__`` returned an object that did not - implement the same interface, :mod:`repoze.bfg` provided some + implement the same interface, ``repoze.bfg`` provided some implicit help during traversal. This traversal feature wrapped subobjects from the root (and thereafter) that did not implement ``ILocation`` in proxies which automatically provided them with a @@ -1815,7 +1925,7 @@ Features - "Virtual root" support for traversal-based applications has been added. Virtual root support is useful when you'd like to host some - model in a :mod:`repoze.bfg` model graph as an application under a + model in a ``repoze.bfg`` model graph as an application under a URL pathname that does not include the model path itself. For more information, see the (new) "Virtual Hosting" chapter in the documentation. @@ -1854,7 +1964,7 @@ Features -------- - You can now override the NotFound and Unauthorized responses that - :mod:`repoze.bfg` generates when a view cannot be found or cannot be + ``repoze.bfg`` generates when a view cannot be found or cannot be invoked due to lack of permission. See the "ZCML Hooks" chapter in the docs for more information. |