accepts a different ordering of arguments. Previously it was ``(pattern, name, factory=None, predicates=())``. It is now ``(name, pattern, factory=None, predicates=())``. This is in support of consistency with ``configurator.add_route``. - The ``repoze.bfg.urldispatch.RoutesMapper.connect`` method (not an API) now accepts a different ordering of arguments. Previously it was ``(pattern, name, factory=None, predicates=())``. It is now ``(name, pattern, factory=None, predicates=())``. This is in support of consistency with ``configurator.add_route``. - The ``repoze.bfg.urldispatch.RoutesMapper`` object now has a ``get_route`` method which returns a single Route object or ``None``. - A new interface ``repoze.bfg.interfaces.IRoute`` was added. The ``repoze.bfg.urldispatch.Route`` object implements this interface. - The canonical attribute for accessing the routing pattern from a route object is now ``pattern`` rather than ``path``. - The argument to ``repoze.bfg.configuration.Configurator.add_route`` which was previously called ``path`` is now called ``pattern`` for better explicability. For backwards compatibility purposes, passing a keyword argument named ``path`` to ``add_route`` will still work indefinitely. - The ``path`` attribute to the ZCML ``route`` directive is now named ``pattern`` for better explicability. The older ``path`` attribute will continue to work indefinitely. - All narrative, API, and tutorial docs which referred to a route pattern as a ``path`` have now been updated to refer to them as a ``pattern``. - The routesalchemy template has been updated to use ``pattern`` in its route declarations rather than ``path``.
============ Paster Templates ---------------- - The ``bfg_alchemy`` and ``bfg_routesalchemy`` templates no longer register a ``handle_teardown`` event listener which calls ``DBSession.remove``. This was found by Chris Withers to be unnecessary. Documentation ------------- - The "bfgwiki2" (URL dispatch wiki) tutorial code and documentation was changed to remove the ``handle_teardown`` event listener which calls ``DBSession.remove``. - Any mention of the ``handle_teardown`` event listener as used by the paster templates was removed from the URL Dispatch narrative chapter.
clean up the SQLAlchemy connection by registering a ``repoze.tm.after_end`` callback instead of relying on a ``__del__`` method of a ``Cleanup`` class added to the WSFI environment. The ``__del__`` strategy was fragile and caused problems in the wild. Thanks to Daniel Holth for testing.
Fix table.
-------- - The ``Configurator`` object now has two new methods: ``begin`` and ``end``. The ``begin`` method is meant to be called before any "configuration" begins (e.g. before ``add_view``, et. al are called). The ``end`` method is meant to be called after all "configuration" is complete. Previously, before there was imperative configuration at all (1.1 and prior), configuration begin and end was invariably implied by the process of loading a ZCML file. When a ZCML load happened, the threadlocal data structure containing the request and registry was modified before the load, and torn down after the load, making sure that all framework code that needed ``get_current_registry`` for the duration of the ZCML load was satisfied. Some API methods called during imperative configuration, (such as ``Configurator.add_view`` when a renderer is involved) end up for historical reasons calling ``get_current_registry``. However, in 1.2a5 and below, the Configurator supplied no functionality that allowed people to make sure that ``get_current_registry`` returned the registry implied by the configurator being used. ``begin`` now serves this purpose. Inversely, ``end`` pops the thread local stack, undoing the actions of ``begin``. We make this boundary explicit to reduce the potential for confusion when the configurator is used in different circumstances (e.g. in unit tests and app code vs. just in initial app setup). Existing code written for 1.2a1-1.2a5 which does not call ``begin`` or ``end`` continues to work in the same manner it did before. It is however suggested that this code be changed to call ``begin`` and ``end`` to reduce the potential for confusion in the future. - All ``paster`` templates which generate an application skeleton now make use of the new ``begin`` and ``end`` methods of the Configurator they use in their respective copies of ``run.py`` and ``tests.py``. Documentation ------------- - All documentation that makes use of a ``Configurator`` object to do application setup and test setup now makes use of the new ``begin`` and ``end`` methods of the configurator. Bug Fixes --------- - When a ``repoze.bfg.exceptions.NotFound`` or ``repoze.bfg.exceptions.Forbidden`` *class* (as opposed to instance) was raised as an exception within a root factory (or route root factory), the exception would not be caught properly by the ``repoze.bfg.`` Router and it would propagate to up the call stack, as opposed to rendering the not found view or the forbidden view as would have been expected.