| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
This testing function registers a routes "mapper" object in the
registry, for tests which require its presence. This function is
documented in the ``repoze.bfg.testing`` API documentation.
|
|
solved the reissue_time authentication policy issue a different way).
|
|
|
|
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.
|
|
|
|
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.
|
|
registering routes to satisfy calls to
e.g. ``repoze.bfg.url.route_url`` in unit 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.
|
|
generating URLs to static resources defined by the ``<static>`` ZCML
directive. See the "Views" narrative chapter's section titled
"Generating Static Resource URLs" for more information.
|
|
deprecated in favor of
``repoze.bfg.testing.registerTemplateRenderer``. A deprecation
warning is *not* issued at import time for the former name; it will
exist "forever".
- The ``repoze.bfg.templating.renderer_from_cache`` function has been
moved to ``repoze.bfg.renderer.template_renderer_factory``. This
was never an API, but code in the wild was spotted that used it. A
deprecation warning is issued at import time for the former.
- Better error message when a wrapper view returns None.
|
|
|
|
|
|
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.
|
|
"front" for the Routes ``url_for`` API. See the URL Dispatch
narrative chapter and the "repoze.bfg.url" module API documentation
for more information.
|
|
|
|
|
|
derivation of values passed as the ``options`` value of
``repoze.bfg.router.make_app``. This API should be preferred
instead of using getUtility(ISettings). I added a new
``repoze.bfg.settings`` API document as well.
|
|
enough to be very helpful and had a misleading name.
|
|
|
|
should be used (**very sparingly**) to retrieve the "current"
request. See the ``repoze.bfg.request`` API documentation for more
information.
|
|
|
|
credentials from an auth_tkt cookie managed by the application
itself (instead of relying on an upstream data source for
authentication data). See the Security API chapter of the
documentation for more info.
- Allow RemoteUserAuthenticationPolicy and
RepozeWho1AuthenticationPolicy to accept various constructor
arguments. See the Security API chapter of the documentation for
more info.
|
|
obtains a WSGI application from a config file given a config file
name and a section name. See the ``repoze.bfg.paster`` API docs for
more information.
- Add a new module named ``scripting``. It contains a ``get_root``
API function, which, provided a Router instance, returns a traversal
root object and a "closer". See the ``repoze.bfg.scripting`` API
docs for more info.
|
|
|
|
--------
- Added a ``traverse`` function to the ``repoze.bfg.traversal``
module. This function may be used to retrieve certain values
computed during path resolution. See the Traversal API chapter of
the documentation for more information about this function.
Deprecations
------------
- Internal: ``ITraverser`` callables should now return a dictionary
rather than a tuple. Up until 0.7.0, all ITraversers were assumed
to return a 3-tuple. In 0.7.1, ITraversers were assumed to return a
6-tuple. As (by evidence) it's likely we'll need to add further
information to the return value of an ITraverser callable, 0.8
assumes that an ITraverser return a dictionary with certain elements
in it. See the ``repoze.bfg.interfaces.ITraverser`` interface for
the list of keys that should be present in the dictionary.
``ITraversers`` which return tuples will still work, although a
deprecation warning will be issued.
Backwards Incompatibilities
---------------------------
- If your code used the ITraverser interface directly (not via an API
function such as ``find_model``) via an adapter lookup, you'll need
to change your code to expect a dictionary rather than a 3- or
6-tuple if your code ever gets return values from the default
ModelGraphTraverser or RoutesModelTraverser adapters.
|
|
|
|
``registerAdapter``, ``registerUtiity``, ``registerSubscriber``, and
``cleanUp``.
- Added glossary entry for "root factory".
|
|
--------
- Two new security policies were added:
RemoteUserInheritingACLSecurityPolicy and
WhoInheritingACLSecurityPolicy. These are security policies which
take into account *all* ACLs defined in the lineage of a context
rather than stopping at the first ACL found in a lineage. See the
"Security" chapter of the API documentation for more information.
- The API and narrative documentation dealing with security was
changed to introduce the new "inheriting" security policy variants.
- Added glossary entry for "lineage".
Deprecations
------------
- The security policy previously named
``RepozeWhoIdentityACLSecurityPolicy`` now has the slightly saner
name of ``WhoACLSecurityPolicy``. A deprecation warning is emitted
when this policy is imported under the "old" name; usually this is
due to its use in ZCML within your application. If you're getting
this deprecation warning, change your ZCML to use the new name,
e.g. change::
<utility
provides="repoze.bfg.interfaces.ISecurityPolicy"
factory="repoze.bfg.security.RepozeWhoIdentityACLSecurityPolicy"
/>
To::
<utility
provides="repoze.bfg.interfaces.ISecurityPolicy"
factory="repoze.bfg.security.WhoACLSecurityPolicy"
/>
|
|
|
|
built-in implementations that implement the interface
(``repoze.bfg.traversal.ModelGraphTraverser``, and
``repoze.bfg.urldispatch.RoutesModelTraverser``) now expect the
``__call__`` method of an ITraverser to return 3 additional
arguments: ``traversed``, ``virtual_root``, and
``virtual_root_path`` (the old contract was that the ``__call__``
method of an ITraverser returned; three arguments, the contract new
is that it returns six). ``traversed`` will be a sequence of
Unicode names that were traversed (including the virtual root path,
if any) or ``None`` if no traversal was performed, ``virtual_root``
will be a model object representing the virtual root (or the
physical root if traversal was not performed), and
``virtual_root_path`` will be a sequence representing the virtual
root path (a sequence of Unicode names) or ``None`` if traversal was
not performed.
Six arguments are now returned from BFG ITraversers. They are
returned in this order: ``context``, ``view_name``, ``subpath``,
``traversed``, ``virtual_root``, and ``virtual_root_path``.
Places in the BFG code which called an ITraverser continue to accept
a 3-argument return value, although BFG will generate and log a
warning when one is encountered.
- The request object now has the following attributes: ``traversed``
(the sequence of names traversed or ``None`` if traversal was not
performed), ``virtual_root`` (the model object representing the
virtual root, including the virtual root path if any), and
``virtual_root_path`` (the seuquence of names representing the
virtual root path or ``None`` if traversal was not performed).
- A new decorator named ``wsgiapp2`` was added to the
``repoze.bfg.wsgi`` module. This decorator performs the same
function as ``repoze.bfg.wsgi.wsgiapp`` except it fixes up the
``SCRIPT_NAME``, and ``PATH_INFO`` environment values before
invoking the WSGI subapplication.
- The ``repoze.bfg.testing.DummyRequest`` object now has default
attributes for ``traversed``, ``virtual_root``, and
``virtual_root_path``.
- The RoutesModelTraverser now behaves more like the Routes
"RoutesMiddleware" object when an element in the match dict is named
``path_info`` (usually when there's a pattern like
``http://foo/*path_info``). When this is the case, the
``PATH_INFO`` environment variable is set to the value in the match
dict, and the ``SCRIPT_NAME`` is appended to with the prefix of the
original ``PATH_INFO`` not including the value of the new variable.
- The notfound debug now shows the traversed path, the virtual root,
and the virtual root path too.
|
|
|
|
now still returns a string; albeit a quoted one. An additional API
(model_path_tuple) now also exists which can be used to get a model
path as a tuple.
- The ``repoze.bfg.traversal.model_path`` API now returns a *quoted*
string rather than a string represented by series of unquoted
elements joined via ``/`` characters. Previously it returned a
string or unicode object representing the model path, with each
segment name in the path joined together via ``/`` characters,
e.g. ``/foo /bar``. Now it returns a string, where each segment is
a UTF-8 encoded and URL-quoted element e.g. ``/foo%20/bar``. This
change was (as discussed briefly on the repoze-dev maillist)
necessary to accomodate model objects which themselves have
``__name__`` attributes that contain the ``/`` character.
For people that have no models that have high-order Unicode
``__name__`` attributes or ``__name__`` attributes with values that
require URL-quoting with in their model graphs, this won't cause any
issue. However, if you have code that currently expects
``model_path`` to return an unquoted string, or you have an existing
application with data generated via the old method, and you're too
lazy to change anything, you may wish replace the BFG-imported
``model_path`` in your code with this function (this is the code of
the "old" ``model_path`` implementation)::
from repoze.bfg.location import lineage
def i_am_too_lazy_to_move_to_the_new_model_path(model, *elements):
rpath = []
for location in lineage(model):
if location.__name__:
rpath.append(location.__name__)
path = '/' + '/'.join(reversed(rpath))
if elements:
suffix = '/'.join(elements)
path = '/'.join([path, suffix])
return path
- The ``repoze.bfg.traversal.find_model`` API no longer implicitly
converts unicode representations of a full path passed to it as a
Unicode object into a UTF-8 string. Callers should either use
prequoted path strings returned by
``repoze.bfg.traversal.model_path``, or tuple values returned by the
result of ``repoze.bfg.traversal.model_path_tuple`` or they should
use the guidelines about passing a string ``path`` argument
described in the ``find_model`` API documentation.
- Each argument contained in ``elements`` passed to
``repoze.bfg.traversal.model_path`` will now have any ``/``
characters contained within quoted to ``%2F`` in the returned
string. Previously, ``/`` characters in elements were left unquoted
(a bug).
- A ``repoze.bfg.traversal.model_path_tuple`` API was added. This API
is an alternative to ``model_path`` (which returns a string);
``model_path_tuple`` returns a model path as a tuple (much like
Zope's ``getPhysicalPath``).
- A ``repoze.bfg.traversal.quote_path_segment`` API was added. This
API will quote an individual path segment (string or unicode
object). See the ``repoze.bfg.traversal`` API documentation for
more information.
|
|
--------
- The ``repoze.bfg.url.model_url`` API now works against contexts
derived from Routes URL dispatch (``Routes.util.url_for`` is called
under the hood).
- "Virtual root" support for traversal-based applications has been
added. Virtual root support is useful when you'd like to host some
model in a :mod:`repoze.bfg` model graph as an application under a
URL pathname that does not include the model path itself. For more
information, see the (new) "Virtual Hosting" chapter in the
documentation.
- A ``repoze.bfg.traversal.virtual_root`` API has been added. When
called, it returns the virtual root object (or the physical root
object if no virtual root has been specified).
Implementation Changes
----------------------
- ``repoze.bfg.traversal.RoutesModelTraverser`` has been moved to
``repoze.bfg.urldispatch``.
- ``model_url`` URL generation is now performed via an adapter lookup
based on the context and the request.
- ZCML which registers two adapters for the ``IContextURL`` interface
has been added to the configure.zcml in ``repoze.bfg.includes``.
|
|
"traversal" API chapter in the docs. This was a function previously
known as ``split_path`` that was not an API but people were using it
anyway. Unlike ``split_path`` it now returns a tuple instead of a
list (as its values are cached).
|
|
|
|
|
|
|
|
attached to each request object on ingress. The HTTP-verb-related
interfaces are defined in ``repoze.bfg.interfaces`` and are
``IGETRequest``, ``IPOSTRequest``, ``IPUTRequest``,
``IDELETERequest`` and ``IHEADRequest``. These interfaces can be
specified as the ``request_type`` attribute of a bfg view
declaration. A view naming a specific HTTP-verb-matching interface
will be found only if the view is defined with a request_type that
matches the HTTP verb in the incoming request. The more general
``IRequest`` interface can be used as the request_type to catch all
requests (and this is indeed the default). All requests implement
``IRequest``. The HTTP-verb-matching idea was pioneered by
`repoze.bfg.restrequest
<http://pypi.python.org/pypi/repoze.bfg.restrequest/1.0.1>`_ . That
package is no longer required, but still functions fine.
|
|
method accepts keyword arguments. Each key/value pair in the
keyword arguments causes an assertion to be made that the renderer
received this key with a value equal to the asserted value.
- Projects generated by the paster templates now use the
``DummyTemplateRenderer.assert_`` method in their view tests.
|
|
module. Instances of this class are willing to act as BFG views
which return static resources using files on disk. See the
:mod:`repoze.bfg.view` docs for more info.
|
|
- A new module ``repoze.bfg.url`` has been added. It contains the
``model_url`` API (moved from ``repoze.bfg.traversal``) and an
implementation of ``urlencode`` (like Python's
``urllib.urlencode``) which can handle Unicode keys and values in
parameters to the ``query`` argument.
Deprecations
- The ``model_url`` function has been moved from
``repoze.bfg.traversal`` into ``repoze.bfg.url``. It can still
be imported from ``repoze.bfg.traversal`` but an import from
``repoze.bfg.traversal`` will emit a DeprecationWarning.
Features
- The ``repoze.bfg.url.model_url`` API (nee'
``repoze.bfg.traversal.model_url``) now accepts and honors a
keyword argument named ``query``. The value of this argument
will be used to compose a query string, which will be attached to
the generated URL before it is returned. See the API docs (in
the docs directory or `on the web
<http://static.repoze.org/bfgdocs>`_) for more information.
|
|
setuptools 0.6c9.
- Turn ``view_execution_permitted`` from the :mod:`repoze.bfg.view`
module into a documented API.
- Doc cleanups.
|
|
where the template does not need to be wrapped in any containing
XML).
Prep for 0.4.9.
|
|
|
