| Age | Commit message (Collapse) | Author |
|---|
|
|
|
``set_notfound_view`` or ``set_forbidden_view`` APIs, the context
sent to the view was incorrect (could be ``None`` inappropriately).
|
|
This interface is provided by all internal exception classes (such
as ``repoze.bfg.exceptions.NotFound`` and
``repoze.bfg.exceptions.Forbidden``), instances of which are both
exception objects and can behave as WSGI response objects. This
interface is made public so that exception classes which are also
valid WSGI response factories can be configured to implement them
or exception instances which are also or response instances can be
configured to provide them.
- New API class: ``repoze.bfg.view.AppendSlashNotFoundViewFactory`` (undoes
previous custom_notfound_view on request passsed to
append_slash_notfound_view).
- Previously, two default view functions were registered at
Configurator setup (one for ``repoze.bfg.exceptions.NotFound`` named
``default_notfound_view`` and one for
``repoze.bfg.exceptions.Forbidden`` named
``default_forbidden_view``) to render internal exception responses.
Those default view functions have been removed, replaced with a
generic default view function which is registered at Configurator
setup for the ``repoze.bfg.interfaces.IExceptionResponse`` interface
that simply returns the exception instance; the ``NotFound` and
``Forbidden`` classes are now still exception factories but they are
also response factories which generate instances that implement the
new ``repoze.bfg.interfaces.IExceptionResponse`` interface.
|
|
--------
- There can only be one Not Found view in any ``repoze.bfg``
application. If you use
``repoze.bfg.view.append_slash_notfound_view`` as the Not Found
view, it still must generate a NotFound response when it cannot
redirect to a slash-appended URL; this not found response will be
visible to site users.
As of this release, if you wish to use a custom notfound view
callable when ``append_slash_notfound_view`` does not redirect to a
slash-appended URL, use a wrapper function as the
``repoze.bfg.exceptions.NotFound`` view; have this wrapper attach a
view callable which returns a response to the request object named
``custom_notfound_view`` before calling
``append_slash_notfound_view``. For example::
from webob.exc import HTTPNotFound
from repoze.bfg.exceptions import NotFound
from repoze.bfg.view import append_slash_notfound_view
def notfound_view(exc, request):
def fallback_notfound_view(exc, request):
return HTTPNotFound('It aint there, stop trying!')
request.fallback_notfound_view = fallback_notfound_view
return append_slash_notfound_view(exc, request)
config.add_view(notfound_view, context=NotFound)
``custom_notfound_view`` must adhere to the two-argument view
callable calling convention of ``(context, request)`` (``context``
will be the exception object).
If ``custom_notfound_view`` is not found on the request object, a
default notfound response will be generated when the
``append_slash_notfound_view`` doesn't redirect to a slash-appended
URL.
Documentation
--------------
- Expanded the "Cleaning Up After a Request" section of the URL
Dispatch narrative chapter.
- Expanded the "Redirecting to Slash-Appended Routes" section of the
URL Dispatch narrative chapter.
|
|
``_app_url`` is present in the arguments passed to ``route_url``,
this value will be used as the protocol/hostname/port/leading path
prefix of the generated URL. For example, using an ``_app_url`` of
``http://example.com:8080/foo`` would cause the URL
``http://example.com:8080/foo/fleeb/flub`` to be returned from this
function if the expansion of the route pattern associated with the
``route_name`` expanded to ``/fleeb/flub``.
- It is now possible to use a URL as the ``name`` argument fed to
``repoze.bfg.configuration.Configurator.add_static_view``. When the
name argument is a URL, the ``repoze.bfg.url.static_url`` API will
generate join this URL (as a prefix) to a path including the static
file name. This makes it more possible to put static media on a
separate webserver for production, while keeping static media
package-internal and served by the development webserver during
development.
|
|
been registered explicitly via set_XXX_view instead of as exception views.
|
|
a context.
Cause append_slash_notfound_view to work in case it is registered via
set_notfound_view.
|
|
<http://docs.repoze.org/venusian>`) to perform ``bfg_view``
decorator scanning rather than relying on a BFG-internal decorator
scanner. (Truth be told, Venusian is really just a generalization
of the BFG-internal decorator scanner).
- A new install-time dependency on the ``venusian`` distribution was
added.
- Remove ``repoze.bfg.compat.pkgutil_26.py`` and import alias
``repoze.bfg.compat.walk_packages``. These were only required by
internal scanning machinery; Venusian replaced the internal scanning
machinery, so these are no longer required.
|
|
the "phash" branch.
|
|
specification values (internal).
|
|
decorator that provided a package-relative template filename might
not have been resolved properly. Symptom: inappropriate ``Missing
template resource`` errors.
|
|
|
|
--------
- The ``Configurator.add_view`` method now accepts an argument named
``context``. This is an alias for the older argument named
``for_``; it is preferred over ``for_``, but ``for_`` will continue
to be supported "forever".
- The ``view`` ZCML directive now accepts an attribute named
``context``. This is an alias for the older attribute named
``for``; it is preferred over ``for``, but ``for`` will continue to
be supported "forever".
- The ``Configurator.add_route`` method now accepts an argument named
``view_context``. This is an alias for the older argument named
``view_for``; it is preferred over ``view_for``, but ``view_for``
will continue to be supported "forever".
- The ``route`` ZCML directive now accepts an attribute named
``view_context``. This is an alias for the older attribute named
``view_for``; it is preferred over ``view_for``, but ``view_for``
will continue to be supported "forever".
Documentation and Paster Templates
----------------------------------
- All uses of the ``Configurator.add_view`` method that used its
``for_`` argument now use the ``context``argument instead.
- All uses of the ``Configurator.add_route`` method that used its
``view_for`` argument now use the ``view_context``argument instead.
- All uses of the ``view`` ZCML directive that used its ``for``
attribute now use the ``context`` attribute instead.
- All uses of the ``route`` ZCML directive that used its ``view_for``
attribute now use the ``view_context`` attribute instead.
|
|
``add_view`` method, the ``bfg_view`` decorator and the attribute
list of the ZCML ``view`` directive. If ``custom_predicates`` is
specified, it must be a sequence of predicate callables (a predicate
callable accepts two arguments: ``context`` and ``request`` and
returns ``True`` or ``False``). The associated view callable will
only be invoked if all custom predicates return ``True``. Use one
or more custom predicates when no existing predefined predicate is
useful. Predefined and custom predicates can be mixed freely.
- Add a ``custom_predicates`` argument to the ``Configurator``
``add_route`` and the attribute list of the ZCML ``route``
directive. If ``custom_predicates`` is specified, it must be a
sequence of predicate callables (a predicate callable accepts two
arguments: ``context`` and ``request`` and returns ``True`` or
``False``). The associated route will match will only be invoked if
all custom predicates return ``True``, else route matching
continues. Use one or more custom predicates when no existing
predefined predicate is useful. Predefined and custom predicates
can be mixed freely.
|
|
|
|
Remove set_security_policies configurator API method.
|
|
``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).
|
|
``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.
|
|
|
|
|
|
``repoze.bfg.compat``.
|
|
``webob.Request`` now defines its own ``__setattr__``,
``__getattr__`` and ``__delattr__`` methods, which override the
default WebOb behavior. The default WebOb behavior stores
attributes of the request in ``self.environ['webob.adhoc_attrs']``,
and retrieves them from that dictionary during a ``__getattr__``.
This behavior was undesirable for speed and "expectation" reasons.
Now attributes of the ``request`` are stored in ``request.__dict__``
(as you otherwise might expect from an object that did not override
these methods).
- The router no longer calls ``repoze.bfg.traversal._traverse`` and
does its work "inline" (speed).
|
|
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.
|
|
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.
|
|
--------
- 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.
|
|
|
|
``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.
|
|
|
|
|
|
This should have no external effects.
- An object implementing the ``IRenderer`` interface (and
``ITemplateRenderer`, which is a subclass of ``IRenderer``) must now
accept an extra ``system`` argument in its ``__call__`` method
implementation. Values computed by the system (as opposed to by the
view) are passed by the system in the ``system`` parameter, which
will always be a dictionary. Keys in the dictionary include:
``view`` (the view object that returned the value),
``renderer_name`` (the template name or simple name of the
renderer), ``context`` (the context object passed to the view), and
``request`` (the request object passed to the view). Previously
only ITemplateRenderers received system arguments as elements inside
the main ``value`` dictionary.
|
|
|
|
|
|
|
|
decorator) can now accept an "attr" value. If an "attr" value is
supplied, it is considered a method named of the view object to be
called when the response is required. This is typically only good
for views that are classes or instances (not so useful for
functions, as functions typically have no methods other than
``__call__``).
- A ZCML ``view`` directive (and the associated ``bfg_view``
decorator) can now accept a "template" value. If a "template" value
is supplied, and the view callable returns a dictionary, the
associated template is rendered with the dictionary as keyword
arguments.
|
|
|
|
first argument ("root_dir") that represents a package-relative name
e.g. ``somepackage:foo/bar/static``. This is now the preferred
mechanism for spelling package-relative static paths using this
class. A ``package_name`` keyword argument has been left around for
backwards compatibility. If it is supplied, it will be honored.
- Fixed documentation for ``repoze.bfg.view.static`` (in narrative
``Views`` chapter).
|
|
default_notfound_view functions into the ``repoze.bfg.view`` module
(moved from ``repoze.bfg.router``).
|
|
``BFG_RELOAD_RESOURCES`` environment variable). When this is set to
true, the server never needs to be restarted when moving files
between directory resource overrides (esp. for templates currently).
- Add a ``reload_all`` configuration file setting (aka the
``BFG_RELOAD_ALL`` environment variable) that implies both
``reload_resources`` and ``reload_templates``.
- The ``static`` helper view class now uses a ``PackageURLParser`` in
order to allow for the overriding of static resources (CSS / logo
files, etc) using the ``resource`` ZCML directive. The
``PackageURLParser`` class was added to a (new) ``static`` module in
BFG; it is a subclass of the ``StaticURLParser`` class in
``paste.urlparser``.
- The ``repoze.bfg.templating.renderer_from_cache`` function now
checks for the ``reload_resources`` setting; if it's true, it does
not register a template renderer (it won't use the registry as a
template renderer cache).
- Add ``pkg_resources`` to the glossary.
- Update the "Environment" docs to note the existence of
``reload_resources`` and ``reload_all``.
- Use a colon instead of a tab as the separator between package name
and relpath to form the "spec" when register a ITemplateRenderer.
|
|
|
|
|
|
via use of the ``bfg_view`` decorator in Python 2.6 as a class
decorator). The calling semantics when using a class as a view
callable is similar to that of using a class as a Zope "browser
view": the class' ``__init__`` must accept two positional parameters
(conventionally named ``context``, and ``request``). The resulting
instance must be callable (it must have a ``__call__`` method).
When called, the instance should return a response. For example::
from webob import Response
class MyView(object):
def __init__(self, context, request):
self.context = context
self.request = request
def __call__(self):
return Response('hello from %s!' % self.context)
See the "Views" chapter in the documentation and the
``repoze.bfg.view`` API documentation for more information.
|
|
|
|
and cleanUp functions in repoze.bfg.testing. Our dependencies still rely on zope.testing, however.
|
|
----------------
- The ``repoze.bfg.view.render_view_to_response`` API will no longer
raise a ValueError if an object returned by a view function it calls
does not possess certain attributes (``headerlist``, ``app_iter``,
``status``). This API used to attempt to perform a check using the
``is_response`` function in ``repoze.bfg.view``, and raised a
``ValueError`` if the ``is_response`` check failed. The
responsibility is now the caller's to ensure that the return value
from a view function is a "real" response.
- WSGI environ dicts passed to ``repoze.bfg`` 's Router must now
contain a REQUEST_METHOD key/value; if they do not, a KeyError will
be raised (speed).
Implementation Changes
----------------------
- Various speed micro-tweaks.
|
|
|
|
``root_path`` name; it will be considered relative to the file in
which it was called.
|
|
``webob.Request.get_response`` to do its work rather than relying on
howgrown WSGI code.
|
|
--------
- The functionality of ``repoze.bfg.convention`` has been merged into
the core. Applications which make use of ``repoze.bfg.convention``
will continue to work indefinitely, but it is recommended that apps
stop depending upon it. To do so, substitute imports of
``repoze.bfg.convention.bfg_view`` with imports of
``repoze.bfg.view.bfg_view``, and change the stanza in ZCML from
``<convention package=".">`` to ``<grok package=".">``. As a result
of the merge, bfg has grown a new dependency: ``martian``.
- View functions which use the pushpage decorator are now pickleable
(meaning their use won't prevent a ``configure.zcml.cache`` file
from being written to disk).
Implementation Changes
----------------------
- The ``wsgiapp`` decorator now uses ``webob.Request.get_response`` to
do its work rather than relying on howgrown WSGI code.
|
|
|
