repoze.bfg 1.1a1 was released today.

New docs exist at

The 1.0 docs continue to exist at

You can install repoze.bfg 1.1a1 via:

   easy_install -i repoze.bfg

This release is a feature release.  It has the following newish features:

- A <static> ZCML directive for serving static files from a package

- The addition of "view predicates" such as "containment",
"request_param" and "request_method".  These view predicates allow more
fine-grained tuning of request-to-view matches.  See the "Views" chapter
of the documentation
for more information.

The repoze.bfg 1.1 API is 100% backwards compatible with the repoze.bfg
1.0 API.

The raw changelog (from 1.0.1) follows:

1.1a1 (2009-09-06)

- The ``registry_manager`` backwards compatibility alias importable
   from "repoze.bfg.registry", deprecated since repoze.bfg 0.9 has been
   removed.  If you are tring to use the registry manager within a
   debug script of your own, use a combination of the
   "repoze.bfg.paster.get_app" and "repoze.bfg.scripting.get_root" APIs

- The ``IViewPermissionFactory`` interface has been removed.  This was
   never an API.

- The ``INotFoundAppFactory`` interface has been removed; it has
   been deprecated since repoze.bfg 0.9.  If you have something like
   the following in your ``configure.zcml``::

    <utility provides="repoze.bfg.interfaces.INotFoundAppFactory"

   Replace it with something like::


   See "Changing the Not Found View" in the "Hooks" chapter of the
   documentation for more information.

- The ``IUnauthorizedAppFactory`` interface has been removed; it has
   been deprecated since repoze.bfg 0.9.  If you have something like
   the following in your ``configure.zcml``::

    <utility provides="repoze.bfg.interfaces.IUnauthorizedAppFactory"

   Replace it with something like::


   See "Changing the Forbidden View" in the "Hooks" chapter of the
   documentation for more information.

- ``ISecurityPolicy``-based security policies, deprecated since
   repoze.bfg 0.9, have been removed.  If you have something like this
   in your ``configure.zcml``, it will no longer work::


    If ZCML like the above exists in your application, you will receive
    an error at startup time.  Instead of the above, you'll need
    something like::


    This is just an example.  See the "Security" chapter of the
    repoze.bfg documentation for more information about configuring
    security policies.

- 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"

- 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
   ```` 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

- The API ``repoze.bfg.testing.registerView`` now takes a
   ``permission`` argument.  Use this instead of using

- Removed ViewPermissionFactory from ````.  View
   permission checking is now done by registering and looking up an

- 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
   mechanism for spelling package-relative static paths using this
   class.  A ``package_name`` keyword argument has been left around for
   backwards compatibility.  If it is supplied, it will be honored.

- Fixed documentation for ``repoze.bfg.view.static`` (in narrative
   ``Views`` chapter).

- Added ``static`` ZCML directive which registers a route for a view
   that serves up files in a directory.  See the "Views" narrative
   documentation chapter's "Serving Static Resources Using a ZCML
   Directive" section for more information.

- "tests" module removed from the bfg_alchemy paster template; these
   tests didn't work.

- Move (non-API) default_view, default_forbidden_view, and
   default_notfound_view functions into the ``repoze.bfg.view`` module
   (moved from ``repoze.bfg.router``).

- Request-only-convention examples in the "Views" narrative
   documentation were broken.

- Change urldispatch internals: Route object is now constructed using
   a path, a name, and a factory instead of a name, a matcher, a
   generator, and a factory.

- Allow ``repoze.bfg.traversal.find_interface`` API to use a class
   object as the argument to compare against the ``model`` passed in.
   This means you can now do ``find_interface(model, SomeClass)`` and
   the first object which is found in the lineage which has
   ``SomeClass`` as its class (or the first object found which has
   ``SomeClass`` as any of its superclasses) will be returned.

- Fixed documentation bugs related to forget and remember in security API

Repoze-dev mailing list

Reply via email to