| Age | Commit message (Collapse) | Author |
|---|
|
``setup.py`` ``tests_require`` argument (Twill will only be
downloaded when :mod:`repoze.bfg` ``setup.py test`` or ``setup.py
nosetests`` is invoked).
|
|
of a ``Configurator`` is now importable as
``repoze.bfg.exceptions.ConfigurationError``.
|
|
|
|
``repoze.bfg.configuration`` module began to attempt to import the
``repoze.bfg.chameleon_zpt`` and ``repoze.bfg.chameleon_text``
modules, and these cannot be used on non-CPython platforms. It now
tolerates startup time import failures for these modules, and only
raise an import error when a template from one of these packages is
actually used.
|
|
keyword argument: ``__provides__``. If this constructor argument is
provided, it should be an interface or a tuple of interfaces. The
resulting model will then provide these interfaces (they will be
attached to the constructed model via
``zope.interface.alsoProvides``).
|
|
or classes, and the ``for`` of first view registered was a
superclass of the second, the ``repoze.bfg` view machinery would
incorrectly associate the two views with the same "multiview".
Multiviews are meant to be collections of views that have *exactly*
the same for/request/viewname values, without taking inheritance
into account. Symptom: wrong view callable found even when you had
correctly specified a ``for_`` interface/class during view
configuration for one or both view configurations.
|
|
along ``_query`` and/or ``_anchor`` arguments to the
``mapper.generate`` function, resulting in blowups.
|
|
quoting or the url
|
|
|
|
|
|
``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``.
|
|
|
|
Allow path specifications for renderers which are already resource specifications.
|
|
|
|
context.path.
|
|
|
|
Remove set_security_policies configurator API method.
|
|
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.
|
|
|
|
the load_zcml API.
Get rid of hook_zca argument in configurator constructor in favor of a ``hook_zca`` method.
Provide an ``unhook_zca`` method.
|
|
|
|
but were otherwise registered with the same arguments, if a request
entered the application which had an ``Accept`` header that accepted
*either* of the media types defined by the set of views registered
with predicates that otherwise matched, a more or less "random" one
view would "win". Now, we try harder to use the view callable
associated with the view configuration that has the most specific
``accept`` argument. Thanks to Alberto Valverde for an initial
patch.
|
|
|
|
functionality is replaced internally).
|
|
|
|
|
|
|
|
removed; it has become unused.
- Change imperative API.
|
|
an IDebugLogger unnamed utility. A named utility with the old name
is registered for b/w compat.
|
|
|
|
``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.
|
|
|
|
|
|
traversal *after* url dispatch via ``<route>`` paths containing the
``*traverse`` element) were broken in 1.1-final and all 1.1 alpha
and beta releases. Views registered without a ``route_name`` route
shadowed views registered with a ``route_name`` inappropriately.
|
|
to Configurator in closures.
|
|
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).
|
