repoze.bfg 0.7.1 has been released.  This will almost certainly be the last 
release in the 0.7 series; the next release will be 0.8.  0.8 will drop all 
dependencies on packages that require compilation of C code (lxml, 
zope.deferredimport, zope.hookable, etc).  0.7.1 is also likely the last 
that will support any version or feature of Chameleon that depends on lxml.  
will drop support for chameleon.genshi and xslt (these both depend on lxml). 
Add-on packages will provide that functionality (and *those* will depend on 

Some backwards incompatibilies are in the 0.7.1 release, mostly as preparation 
for the 0.8 release.  In particular, 0.7.1 package drops direct support for 
"location proxies" in order to shed a direct dependency on the zope.proxy 
package; you will be able to readd location proxies as an addon package (which 
will itself depend on zope.proxy) named "repoze.bfg.traversalwrapper".

Please note also that the canonical BFG package index location has changed, as 
described in the following.



- The canonical package index location for ``repoze.bfg`` has changed.
   The "old" index ( has
   been superseded by a new index location
   <>`_).  The installation
   documentation has been updated as well as the ``setup.cfg`` file in
   this package.  The "lemonade" index still exists, but it is not
   guaranteed to have the latest BFG software in it, nor will it be
   maintained in the future.


- The "paster create" templates have been modified to use links to the
   new "" and "" websites.

- Added better documentation for virtual hosting at a URL prefix
   within the virtual hosting docs chapter.

- The interface for ``repoze.bfg.interfaces.ITraverser`` and the
   built-in implementations that implement the interface
   (``repoze.bfg.traversal.ModelGraphTraverser``, and
   ``repoze.bfg.urldispatch.RoutesModelTraverser``) now expect the
   ``__call__`` method of an ITraverser to return 3 additional
   arguments: ``traversed``, ``virtual_root``, and
   ``virtual_root_path`` (the old contract was that the ``__call__``
   method of an ITraverser returned; three arguments, the contract new
   is that it returns six).  ``traversed`` will be a sequence of
   Unicode names that were traversed (including the virtual root path,
   if any) or ``None`` if no traversal was performed, ``virtual_root``
   will be a model object representing the virtual root (or the
   physical root if traversal was not performed), and
   ``virtual_root_path`` will be a sequence representing the virtual
   root path (a sequence of Unicode names) or ``None`` if traversal was
   not performed.

   Six arguments are now returned from BFG ITraversers.  They are
   returned in this order: ``context``, ``view_name``, ``subpath``,
   ``traversed``, ``virtual_root``, and ``virtual_root_path``.

   Places in the BFG code which called an ITraverser continue to accept
   a 3-argument return value, although BFG will generate and log a
   warning when one is encountered.

- The request object now has the following attributes: ``traversed``
   (the sequence of names traversed or ``None`` if traversal was not
   performed), ``virtual_root`` (the model object representing the
   virtual root, including the virtual root path if any), and
   ``virtual_root_path`` (the seuquence of names representing the
   virtual root path or ``None`` if traversal was not performed).

- A new decorator named ``wsgiapp2`` was added to the
   ``repoze.bfg.wsgi`` module.  This decorator performs the same
   function as ``repoze.bfg.wsgi.wsgiapp`` except it fixes up the
   ``SCRIPT_NAME``, and ``PATH_INFO`` environment values before
   invoking the WSGI subapplication.

- The ``repoze.bfg.testing.DummyRequest`` object now has default
   attributes for ``traversed``, ``virtual_root``, and

- The RoutesModelTraverser now behaves more like the Routes
   "RoutesMiddleware" object when an element in the match dict is named
   ``path_info`` (usually when there's a pattern like
   ``http://foo/*path_info``).  When this is the case, the
   ``PATH_INFO`` environment variable is set to the value in the match
   dict, and the ``SCRIPT_NAME`` is appended to with the prefix of the
   original ``PATH_INFO`` not including the value of the new variable.

- The notfound debug now shows the traversed path, the virtual root,
   and the virtual root path too.

- Speed up / clarify 'traversal' module's 'model_path', 'model_path_tuple',
   and '_model_path_list' functions.

Backwards Incompatibilities

- In previous releases, the ``repoze.bfg.url.model_url``,
   ``repoze.bfg.traversal.model_path`` and
   ``repoze.bfg.traversal.model_path_tuple`` functions always ignored
   the ``__name__`` argument of the root object in a model graph (
   effectively replacing it with a leading ``/`` in the returned value)
   when a path or URL was generated.  The code required to perform this
   operation was not efficient.  As of this release, the root object in
   a model graph *must* have a ``__name__`` attribute that is either
   ``None`` or the empty string (``''``) for URLs and paths to be
   generated properly from these APIs.  If your root model object has a
   ``__name__`` argument that is not one of these values, you will need
   to change your code for URLs and paths to be generated properly.  If
   your model graph has a root node with a string ``__name__`` that is
   not null, the value of ``__name__`` will be prepended to every path
   and URL generated.

- The ``repoze.bfg.location.LocationProxy`` class and the
   ``repoze.bfg.location.ClassAndInstanceDescr`` class have both been
   removed in order to be able to eventually shed a dependency on
   ``zope.proxy``.  Neither of these classes was ever an API.

- In all previous releases, the ``repoze.bfg.location.locate``
   function worked like so: if a model did not explicitly provide the
   ``repoze.bfg.interfaces.ILocation`` interface, ``locate`` returned a
   ``LocationProxy`` object representing ``model`` with its
   ``__parent__`` attribute assigned to ``parent`` and a ``__name__``
   attribute assigned to ``__name__``.  In this release, the
   ``repoze.bfg.location.locate`` function simply jams the ``__name__``
   and ``__parent__`` attributes on to the supplied model
   unconditionally, no matter if the object implements ILocation or
   not, and it never returns a proxy.  This was done because the
   LocationProxy behavior has now moved into an add-on package
   (``repoze.bfg.traversalwrapper``), in order to eventually be able to
   shed a dependency on ``zope.proxy``.

- In all previous releases, by default, if traversal was used (as
   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
   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
   ``__name__`` and ``__parent__`` attribute based on the name being
   traversed and the previous object traversed.  This feature has now
   been removed from the base ``repoze.bfg`` package for purposes of
   eventually shedding a dependency on ``zope.proxy``.

   In order to re-enable the wrapper behavior for older applications
   which cannot be changed, register the "traversalwrapper"
   ``ModelGraphTraverser`` as the traversal policy, rather than the
   default ``ModelGraphTraverser``. To use this feature, you will need
   to install the ``repoze.bfg.traversalwrapper`` package (an add-on
   package, available at Then change your
   application's ``configure.zcml`` to include the following stanza:


    When this ITraverserFactory is used instead of the default, no
    object in the graph (even the root object) must supply a
    ``__name__`` or ``__parent__`` attribute.  Even if subobjects
    returned from the root *do* implement the ILocation interface,
    these will still be wrapped in proxies that override the object's
    "real" ``__parent__`` and ``__name__`` attributes.

    See also changes to the "Models" chapter of the documentation (in
    the "Location-Aware Model Instances") section.

Repoze-dev mailing list

Reply via email to