| Age | Commit message (Collapse) | Author |
|---|
|
decorator. In 1.1a7, it actually tried to grope every class in
scanned package at startup time looking for methods, which led to
some strange symptoms (e.g. ``AttributeError: object has no
attribute __provides__``). Now, instead of groping methods at
startup time, we just cause the ``bfg_view`` decorator itself to
populate its class' __dict__ when its used inside a class as a
method decorator. This is essentially a reversion back to 1.1a6
"grokking" behavior plus some special magic for using the
``bfg_view`` decorator as method decorator inside the ``bfg_view``
class itself.
|
|
used in ZCML) introduced in 1.1a7. Symptom: ``AttributeError:
object has no attribute __provides__`` raised at startup time.
|
|
slightly earlier now (before a NewRequest event is emitted).
``root`` is the result of the application "root factory".
|
|
|
|
|
|
``repoze.bfg.security.remember`` when the
``authtktauthenticationpolicy`` authentication policy is in effect.
(Patch from Andreas Zeidler).
|
|
|
|
``query`` and ``_anchor`` argument documented as ``anchor``).
|
|
|
|
in the "repoze.bfg.testing" API chapter. This allows for
registration of "settings" values obtained via
``repoze.bfg.settings.get_settings()`` for use in unit tests.
|
|
import. Thanks to Daniel Holth for the initial patch.
|
|
:mod:`repoze.bfg.url.model_url` Generates a URL`` to the "Hooks"
narrative chapter of the docs.
|
|
|
|
|
|
from webob import Response
from repoze.bfg.view import bfg_view
class MyView(object):
def __init__(self, context, request):
self.context = context
self.request = request
@bfg_view(name='hello')
def amethod(self):
return Response('hello from %s!' % self.context)
When the bfg_view decorator is used against a class method, a view
is registered for the *class* (it's a "class view" where the "attr"
happens to be the method they're attached to), so the view class
must have a suitable constructor.
|
|
any number of others. Each invocation of the decorator registers a
single view. For instance, the following combination of decorators
and a function will register two views::
from repoze.bfg.view import bfg_view
@bfg_view(name='edit')
@bfg_view(name='change')
def edit(context, request):
pass
This makes it possible to associate more than one view configuration
for a single callable without requiring ZCML.
|
|
function populates a component registry from a ZCML file for testing
purposes.
|
|
|
|
--------
- 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.
|
|
predicates to ZCML view declaration, ZCML route declaration, and
``bfg_view`` decorator. See the ``Views`` narrative documentation
chapter for more information about these predicates.
|
|
registering routes to satisfy calls to
e.g. ``repoze.bfg.url.route_url`` in unit tests.
|
|
following addtional attributes: ``attr``, ``renderer``, and
``wrapper``. These have the same meaning as they do in the context
of a ZCML ``view`` directive.
|
|
Ditch integration tests.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
``repoze.bfg.view.append_slash_notfound_view`` view as the Not Found
view in your application. When this view is the Not Found view
(indicating that no view was found), and any routes have been
defined in the configuration of your application, if the value of
``PATH_INFO`` does not already end in a slash, and if the value of
``PATH_INFO`` *plus* a slash matches any route's path, do an HTTP
redirect to the slash-appended PATH_INFO. Note that this will
*lose* ``POST`` data information (turning it into a GET), so you
shouldn't rely on this to redirect POST requests.
|
|
``repoze.bfg.exceptions.NotFound``. The old location still
functions, but emits a deprecation warning.
- The import of ``repoze.bfg.security.Unauthorized`` is deprecated in
favor of ``repoze.bfg.exceptions.Forbidden``. The old location
still functions but emits a deprecation warning. The rename from
``Unauthorized`` to ``Forbidden`` brings parity to the the name of
the exception and the system view it invokes when raised.
- New ``repoze.bfg.exceptions`` module was created to house exceptions
that were previously sprinkled through various modules.
- An ``exceptions`` API chapter was added, documenting the new
``repoze.bfg.exceptions`` module.
|
|
|
|
slightly.
|
|
- Speed up ``repoze.bfg.url.route_url`` slightly.
|
|
|
|
- Speed up ``repoze.bfg.url.route_url`` slightly.
|
|
- Speed up ``repoze.bfg.traversal.model_path_tuple`` slightly.
- Speed up ``repoze.bfg.traversal.traverse`` slightly.
- In 0.8a7, the return value expected from an object implementing
``ITraverserFactory`` was changed from a sequence of values to a
dictionary containing the keys ``context``, ``view_name``,
``subpath``, ``traversed``, ``virtual_root``, ``virtual_root_path``,
and ``root``. Until now, old-style traversers which returned a
sequence have continued to work but have generated a deprecation
warning. In this release, traversers which return a sequence
instead of a dictionary will no longer work.
|
|
--------
- Speed up ``repoze.bfg.encode.urlencode`` (nee'
``repoze.bfg.url.urlencode``) slightly.
- Speed up ``repoze.bfg.traversal.model_path`` and
``repoze.bfg.traversal.model_path_tuple`` slightly.
Internal
--------
- Move ``repoze.bfg.traversal._url_quote`` into ``repoze.bfg.encode``
as ``url_quote``.
Backwards Incompatibilities
---------------------------
- We previously had a Unicode-aware wrapper for the
``urllib.urlencode`` function named ``repoze.bfg.url.urlencode``
which delegated to the stdlib function, but which marshalled all
unicode values to utf-8 strings before calling the stdlib version.
A newer replacement now lives in ``repoze.bfg.encode`` (old imports
will still work). The replacement does not delegate to the stdlib.
The replacement diverges from the stdlib implementation and the
previous ``repoze.bfg.url`` url implementation inasmuch as its
``doseq`` argument is a decoy: it always behaves in the
``doseq=True`` way (which is the only sane behavior) for speed
purposes.
The old import location (``repoze.bfg.url.urlencode``) still
functions and has not been deprecated.
|
|
|
|
|
|
|
|
(orderings of views with predicates) were not evaluated in the
proper order. Symptom: in a configuration that had two views with
the same name but one with a ``request_method=POST`` predicate and
one without, the one without the predicate would be called
unconditionally (even if the request was a POST request). Thanks
much to Sebastien Douche for providing the buildbots that pointed
this out.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
