| Age | Commit message (Collapse) | Author |
|
|
|
on the "current" route (if any) and its matchdict values.
|
|
view config
|
|
|
|
|
|
a named implementation of a ``pyramid.interfaces.IViewMapperFactory``
interface. Its name can be passed as a ``view_mapper`` argument to
``config.add_view``. A view mapper allows objects that are meant to be
used as view callables to have an arbitrary argument list and an arbitrary
result. This feature will be used by Pyramid extension developers, not by
"civilians".
- New constructor argument to Configurator: ``default_view_mapper``. Useful
to create systems that have view callables with alternate default calling
conventions.
- ``view_mapper`` argument to ``add_view`` should now be a view mapper *name*
rather than an implementation.
- Add ``view_mapper`` argument to ``view_config`` decorator constructor.
- Remove (non-API) function of config.py named _map_view.
- Fix docstring for ``decorator`` argument to add_view.
- Factor invocation of view mapper into a viewderiver method.
- Promote view rendering and decorating into viewderiver, out of view mapper.
- Make requestonly into a function rather than a method of the default view
mapper.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
to :app:`Pyramid`. A custom role setting was added to ``docs/conf.py`` to
allow for this. (internal)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
``pregenerator`` argument. The pregenerator for the resulting route
is called by ``route_url`` in order to adjust the set of arguments
passed to it by the user for special purposes, such as Pylons
'subdomain' support. It will influence the URL returned by
``route_url``. See the ``repoze.bfg.interfaces.IRoutePregenerator``
interface for more information.
|
|
--------
- A ``request.matched_route`` attribute is now added to the request
when a route has matched. Its value is the "route" object that
matched (see the ``IRoute`` interface within
``repoze.bfg.interfaces`` API documentation for the API of a route
object).
- The ``exception`` attribute of the request is now set slightly
earlier and in a slightly different set of scenarios, for benefit of
"finished callbacks" and "response callbacks". In previous
versions, the ``exception`` attribute of the request was not set at
all if an exception view was not found. In this version, the
``request.exception`` attribute is set immediately when an exception
is caught by the router, even if an exception view could not be
found.
Backwards Incompatibilities
---------------------------
- The router no longer sets the value ``wsgiorg.routing_args`` into
the environ when a route matches. The value used to be something
like ``((), matchdict)``. This functionality was only ever
obliquely referred to in change logs; it was never documented as an
API.
- The ``exception`` attribute of the request now defaults to ``None``.
In prior versions, the ``request.exception`` attribute did not exist
if an exception was not raised by user code during request
processing; it only began existence once an exception view was
found.
Deprecations
------------
- References to the WSGI environment values ``bfg.routes.matchdict``
and ``bfg.routes.route`` were removed from documentation. These
will stick around internally for several more releases, but it is
``request.matchdict`` and ``request.matched_route`` are now the
"official" way to obtain the matchdict and the route object which
resulted in the match.
Documentation
-------------
- Added two sections to the "Hooks" chapter of the documentation:
"Using Response Callbacks" and "Using Finished Callbacks".
- Added documentation of the ``request.exception`` attribute to the
``repoze.bfg.request.Request`` API documentation.
- Added glossary entries for "response callback" and "finished
callback".
- The "Request Processing" narrative chapter has been updated to note
finished and response callback steps.
|
|
|
|
--------
- In support of making it easier to configure applications which are
"secure by default", a default permission feature was added. If
supplied, the default permission is used as the permission string to
all view registrations which don't otherwise name a permission.
These APIs are in support of that:
- A new constructor argument was added to the Configurator:
``default_permission``.
- A new method was added to the Configurator:
``set_default_permission``.
- A new ZCML directive was added: ``default_permission``.
Documentation
-------------
- Added documentation for the ``default_permission`` ZCML directive.
- Added documentation for the ``default_permission`` constructor value
and the ``set_default_permission`` method in the Configurator API
documentation.
- Added a new section to the "security" chapter named "Setting a
Default Permission".
- Document ``renderer_globals_factory`` and ``request_factory``
arguments to Configurator constructor.
|
|
This returns an object implementing the ``IRoutesMapper`` interface.
|
|
|
|
working with gettext files.
|
|
|
|
$REPOZE_SVN/repoze.bfg/branches/i18n
No foreigners were harmed in the coding of this feature.
|
|
merge -r9054:9030 svn+ssh://repoze@svn.repoze.org/svn/repoze.bfg/trunk
|
|
|
|
<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.
|
|
|
|
|
|
|
|
Merge a bunch of paper-based docs fixes
Configure logging during bfgshell.
|
|
|
|
|
|
code.
|
|
|
|
|
|
--------
- 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.
|
|
|