| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
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``.
|
|
(docs/tutorials/bfgwiki2) was changed to demonstrate authorization
via a group rather than via a direct username.
|
|
============
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.
|
|
the "phash" branch.
|
|
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.
|
|
|
|
|
|
|
|
---------
- Remove ``ez_setup.py`` and its import from all paster templates,
samples, and tutorials for ``distribute`` compatibility. The
documentation already explains how to install virtualenv (which will
include some ``setuptools`` package), so these files, imports and
usages were superfluous.
Deprecations
------------
- The ``options`` kw arg to the ``repoze.bfg.router.make_app``
function is deprecated. In its place is the keyword argument
``settings``. The ``options`` keyword continues to work, and a
deprecation warning is not emitted when it is detected. However,
the paster templates, code samples, and documentation now make
reference to ``settings`` rather than ``options``. This
change/deprecation was mainly made for purposes of clarity and
symmetry with the ``get_settings()`` API and dicussions of
"settings" in various places in the docs: we want to use the same
name to refer to the same thing everywhere.
|
|
|
|
``<route>`` ZCML directive (in-the-wild 1.1a bw compat).
- ``bfg_routesalchemy`` paster template: change ``<route>``
declarations: rename ``renderer`` attribute to ``view_renderer``.
- In ``<route>`` declarations in tutorial ZCML, rename ``renderer``
attribute to ``view_renderer`` (fwd compat).
|
|
|
|
--------
- Add ``setUp`` and ``tearDown`` functions to the
``repoze.bfg.testing`` module. Using ``setUp`` in a test setup and
``tearDown`` in a test teardown is now the recommended way to do
component registry setup and teardown. Previously, it was
recommended that a single function named
``repoze.bfg.testing.cleanUp`` be called in both the test setup and
tear down. ``repoze.bfg.testing.cleanUp`` still exists (and will
exist "forever" due to its widespread use); it is now just an alias
for ``repoze.bfg.testing.setUp`` and is nominally deprecated.
- The BFG component registry is now available in view and event
subscriber code as an attribute of the request
ie. ``request.registry``. This fact is currently undocumented
except for this note, because BFG developers never need to interact
with the registry directly anywhere else.
- The BFG component registry now inherits from ``dict``, meaning that
it can optionally be used as a simple dictionary. *Component*
registrations performed against it via e.g. ``registerUtility``,
``registerAdapter``, and similar API methods are kept in a
completely separate namespace than its dict members, so using the
its component API methods won't effect the keys and values in the
dictionary namespace. Likewise, though the component registry
"happens to be" a dictionary, use of mutating dictionary methods
such as ``__setitem__`` will have no influence on any component
registrations made against it. In other words, the registry object
you obtain via e.g. ``repoze.bfg.threadlocal.get_current_registry``
or ``request.registry`` happens to be both a component registry and
a dictionary, but using its component-registry API won't impact data
added to it via its dictionary API and vice versa. This is a
forward compatibility move based on the goals of "marco".
Documentation
-------------
- Various tutorial test modules updated to use
``repoze.bfg.testing.setUp`` and ``repoze.bfg.testing.tearDown``
methods in order to encourage this as best practice going forward.
Backwards Incompatibilities
---------------------------
- Importing ``getSiteManager`` and ``get_registry`` from
``repoze.bfg.registry`` is no longer supported. These imports were
deprecated in repoze.bfg 1.0. Import of ``getSiteManager`` should
be done as ``from zope.component import getSiteManager``. Import of
``get_registry`` should be done as ``from repoze.bfg.threadlocal
import get_current_registry``. This was done to prevent a circular
import dependency.
- Code bases which alternately invoke both
``zope.testing.cleanup.cleanUp`` and ``repoze.bfg.testing.cleanUp``
(treating them equivalently, using them interchangeably) in the
setUp/tearDown of unit tests will begin to experience test failures
due to lack of test isolation. The "right" mechanism is
``repoze.bfg.testing.cleanUp`` (or the combination of
``repoze.bfg.testing.setUp`` and
``repoze.bfg.testing.tearDown``). but a good number of legacy
codebases will use ``zope.testing.cleanup.cleanUp`` instead. We
support ``zope.testing.cleanup.cleanUp`` but not in combination with
``repoze.bfg.testing.cleanUp`` in the same codebase. You should use
one or the other test cleanup function in a single codebase, but not
both.
Internal
--------
- Created new ``repoze.bfg.configuration`` module which assumes
responsibilities previously held by the ``repoze.bfg.registry`` and
``repoze.bfg.router`` modules (avoid a circular import dependency).
- The result of the ``zope.component.getSiteManager`` function in unit
tests set up with ``repoze.bfg.testing.cleanUp`` or
``repoze.bfg.testing.setUp`` will be an instance of
``repoze.bfg.registry.Registry`` instead of the global
``zope.component.globalregistry.base`` registry. This also means
that the threadlocal ZCA API functions such as ``getAdapter`` and
``getUtility`` as well as internal BFG machinery (such as
``model_url`` and ``route_url``) will consult this registry within
unit tests. This is a forward compatibility move based on the goals
of "marco".
- Removed ``repoze.bfg.testing.addCleanUp`` function and associated
module-scope globals. This was never an API.
|
|
|
|
|
|
Add tests.
|
|
|
|
|
|
Use request.url as "referrer" as we're no longer redirecting.
|
|
arguments to ``repoze.bfg.router.make_app``. Instead, developers
should use the various authentication policy ZCML directives
(``repozewho1authenticationpolicy``,
``remoteuserauthenticationpolicy`` and
``authtktauthenticationpolicy``) and the `aclauthorizationpolicy``
authorization policy directive as described in the changes to the
"Security" narrative documentation chapter and the wiki tutorials.
|
|
|
|
|
|
|
|
``url_for`` API.
|
|
|
|
|
|
Ignores.
|
|
|
|
on the request as the ``matchdict`` attribute:
``request.matchdict``. If no route matched, this attribute will be
None.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
