| Age | Commit message (Collapse) | Author |
|---|
|
deprecated in 1.1 and hasn't possessed any APIs since before 1.0.
|
|
|
|
"the old way" an application constructor worked.
|
|
|
|
|
|
``request_type`` predicate caused a startup time failure when it was
encountered in imperative configuration or in a decorator (symptom:
``Type Error: Required specification must be a specification``).
This now works again, although ``request_method`` is a more modern
predicate.
|
|
|
|
|
|
purpose of isolating tests from one another may now begin to fail
due to lack of isolation between tests.
Here's why: In repoze.bfg 1.1 and prior, the registry returned by
``repoze.bfg.threadlocal.get_current_registry`` when no other
registry had been pushed on to the threadlocal stack was the
``zope.component.globalregistry.base`` global registry (aka the
result of ``zope.component.getGlobalSiteManager()``). In repoze.bfg
1.2+, however, the registry returned in this situation is the new
module-scope ``repoze.bfg.registry.global_registry`` object. The
``zope.testing.cleanup.cleanUp`` function clears the
``zope.component.globalregistry.base`` global registry
unconditionally. However, it does not know about the
``repoze.bfg.registry.global_registry`` object, so it does not clear
it.
If you use the ``zope.testing.cleanup.cleanUp`` function in the
``setUp`` of test cases in your unit test suite instead of using the
(more correct as of 1.1) ``repoze.bfg.testing.setUp``, you will need
to replace all calls to ``zope.testing.cleanup.cleanUp`` with a call
to ``repoze.bfg.testing.setUp``.
If replacing all calls to ``zope.testing.cleanup.cleanUp`` with a
call to ``repoze.bfg.testing.setUp`` is infeasible, you can put this
bit of code somewhere that is executed exactly **once** (*not* for
each test in a test suite; in the `` __init__.py`` of your
package would be a reasonable place)::
import zope.testing.cleanup
from repoze.bfg.testing import setUp
zope.testing.cleanup.addCleanUp(setUp)
- When there is no "current registry" in the
``repoze.bfg.threadlocal.manager`` threadlocal data structure (this
is the case when there is no "current request" or we're not in the
midst of a ``r.b.testing.setUp``-bounded unit test), the ``.get``
method of the manager returns a data structure containing a *global*
registry. In previous releases, this function returned the global
Zope "base" registry: the result of
``zope.component.getGlobalSiteManager``, which is an instance of the
``zope.component.registry.Component`` class. In this release,
however, the global registry returns a globally importable instance
of the ``repoze.bfg.registry.Registry`` class. This registry
instance can always be imported as
``repoze.bfg.registry.global_registry``.
Effectively, this means that when you call
``repoze.bfg.threadlocal.get_current_registry`` when no request or
``setUp`` bounded unit test is in effect, you will always get back
the global registry that lives in
``repoze.bfg.registry.global_registry``. It also means that
:mod:`repoze.bfg` APIs that *call* ``get_current_registry`` will use
this registry.
This change was made because :mod:`repoze.bfg` now expects the
registry it uses to have a slightly different API than a bare
instance of ``zope.component.registry.Components``.
|
|
|
|
|
|
|
|
unittesting chapter.
|
|
optional keyword arguments: ``registry``, ``request`` and
``hook_zca``.
If the ``registry`` argument is not ``None``, the argument will be
treated as the registry that is set as the "current registry" (it
will be returned by ``repoze.bfg.threadlocal.get_current_registry``)
for the duration of the test. If the ``registry`` argument is
``None`` (the default), a new registry is created and used for the
duration of the test.
The value of the ``request`` argument is used as the "current
request" (it will be returned by
``repoze.bfg.threadlocal.get_current_request``) for the duration of
the test; it defaults to ``None``.
If ``hook_zca`` is ``True`` (the default), the
``zope.component.getSiteManager`` function will be hooked with a
function that returns the value of ``registry`` (or the
default-created registry if ``registry`` is ``None``) instead of the
registry returned by ``zope.component.getGlobalSiteManager``,
causing the Zope Component Architecture API (``getSiteManager``,
``getAdapter``, ``getUtility``, and so on) to use the registry we're
using for testing instead of the global ZCA registry.
- The ``repoze.bfg.testing.tearDown`` function now accepts an
``unhook_zca`` argument. If this argument is ``True`` (the
default), ``zope.component.getSiteManager.reset()`` will be called,
causing the "base" registry to once again start returnining the
result of ``zope.component.getSiteManager``.
- Remove hook_zca and unhook_zca methods from Configurator.
|
|
|
|
functionality is replaced internally).
|
|
|
|
|
|
removed; it has become unused.
- Change imperative API.
|
|
|
|
deprecated. Its import and usage does not throw a warning, nor will
it probably ever disappear. However, using a
``repoze.bfg.configuration.Configurator`` class is now the preferred
way to generate a WSGI application.
- The ``run.py`` module in various ``repoze.bfg`` ``paster`` templates
now use a ``repoze.bfg.configuration.Configurator`` class instead of
the (now-legacy) ``repoze.bfg.router.make_app`` function to produce
a WSGI application.
|
|
an IDebugLogger unnamed utility. A named utility with the old name
is registered for b/w compat.
|
|
Update text files.
|
|
``getUtility``, ``getAdapter``, ``getMultiAdapter`` threadlocal API)
have been removed from the core. Instead, when a threadlocal is
necessary, the core uses the
``repoze.bfg.threadlocal.get_current_registry`` API to obtain the
registry.
|
|
request rather than a FakeRequest when it sets up the request as a
threadlocal.
- The ``repoze.bfg.traversal.traverse`` API now uses a 'real' WebOb
request rather than a FakeRequest when it calls the traverser.
- The ``repoze.bfg.request.FakeRequest`` class has been removed.
``repoze.bfg.url.route_url``
``repoze.bfg.url.model_url``
``repoze.bfg.url.static_url``
``repoze.bfg.traversal.virtual_root``
Each of these functions now expects to be called with a request
object that has a ``registry`` attribute which represents the
current ZCA registry.
Get rid of extraneous uses of ZCA threadlocal API.
|
|
``repoze.bfg.security.authenticated_userid``
``repoze.bfg.security.effective_principals``
``repoze.bfg.security.view_execution_permitted``
``repoze.bfg.security.remember``
``repoze.bfg.security.forget``
Each of these functions now expects to be called with a request
object that has a ``registry`` attribute which represents the
current ZCA registry. Previously these functions used the ZCA
threadlocal API to get the current registry.
|
|
|
|
ZCML directives which accept paths now register absolute paths, while
imperative registrations now register resource specifications.
|
|
|
|
|
|
|
|
``repoze.bfg.view.render_view_to_iterable``,
``repoze.bfg.view.render_view_to_response``,
``repoze.bfg.view.append_slash_notfound_view``,
``repoze.bfg.view.default_notfound_view``,
``repoze.bfg.view.default_forbidden_view``, and the
``repoze.bfg.configuration.rendered_response`` functions now expects
to be called with a request object that has a ``registry`` attribute
which represents the current ZCA registry. This should only be a
problem when passing a custom request object to code which ends up
calling these functions in a unit test. To retrofit tests that end
up calling these functions which expect to be able to use a
non-registry-aware request object, use the
``repoze.bfg.threadlocal.get_current_request`` API in the test to
create the request; this will return a
``repoze.bfg.testing.DummyRequest`` that has the current registry as
its ``registry`` attribute. Alternatively, use the
``repoze.bfg.threadlocal.get_current_registry`` API: call this
function and add an attribute to your unit test request object named
``registry`` with the result.
- The ``repoze.bfg.view.derive_view`` callable has been removed. Use
``repoze.bfg.configuration.Configurator.derive_view`` instead (still
not an API, however).
|
|
|
|
``debug_authorization`` consule debugging output was turned on
wasn't as clear as it could have been when a view execution was
denied due to an authorization failure resulting from the set of
principals passed never having matched any ACE in any ACL in the
lineage. Now in this case, we report ``<default deny>`` as the ACE
value and either the root ACL or ``<No ACL found on any object in
model lineage>`` if no ACL was found.
|
|
``repoze.bfg.configuration.rendered_response``.
- The ``repoze.bfg.view.decorate_view`` function has been moved to
``repoze.bfg.configuration.decorate_view``.
- The ``repoze.bfg.view.MultiView`` class has been moved to
``repoze.bfg.configuration.MultiView``.
- Fix argument ordering bug in r.b.configuration.Configurator.resource.
|
|
Shuffle Configurator around so that not passing a registry makes a default one.
|
|
|
|
|
|
- The ``repoze.bfg.view.map_view`` callable has been removed.
- The ``repoze.bfg.view.owrap_view`` callable has been removed.
- The ``repoze.bfg.view.predicate_wrap`` callable has been removed.
- The ``repoze.bfg.view.secure_view`` callable has been removed.
- The ``repoze.bfg.view.authdebug_view`` callable has been removed.
- The ``repoze.bfg.view.renderer_from_name`` callable has been removed.
- Coverage.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
interface to the request rather than ``directlyProvides`` to avoid
disturbing interfaces set in a NewRequest event handler.
|
|
|
|
---------
- 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.
|
|
|
