| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Documentation licensing.
|
|
This section contains detailed ZCML directive information, some of
which was removed from various narrative chapters.
|
|
--------
- The ``Configurator`` object now has two new methods: ``begin`` and
``end``. The ``begin`` method is meant to be called before any
"configuration" begins (e.g. before ``add_view``, et. al are
called). The ``end`` method is meant to be called after all
"configuration" is complete.
Previously, before there was imperative configuration at all (1.1
and prior), configuration begin and end was invariably implied by
the process of loading a ZCML file. When a ZCML load happened, the
threadlocal data structure containing the request and registry was
modified before the load, and torn down after the load, making sure
that all framework code that needed ``get_current_registry`` for the
duration of the ZCML load was satisfied.
Some API methods called during imperative configuration, (such as
``Configurator.add_view`` when a renderer is involved) end up for
historical reasons calling ``get_current_registry``. However, in
1.2a5 and below, the Configurator supplied no functionality that
allowed people to make sure that ``get_current_registry`` returned
the registry implied by the configurator being used. ``begin`` now
serves this purpose. Inversely, ``end`` pops the thread local
stack, undoing the actions of ``begin``.
We make this boundary explicit to reduce the potential for confusion
when the configurator is used in different circumstances (e.g. in
unit tests and app code vs. just in initial app setup).
Existing code written for 1.2a1-1.2a5 which does not call ``begin``
or ``end`` continues to work in the same manner it did before. It
is however suggested that this code be changed to call ``begin`` and
``end`` to reduce the potential for confusion in the future.
- All ``paster`` templates which generate an application skeleton now
make use of the new ``begin`` and ``end`` methods of the
Configurator they use in their respective copies of ``run.py`` and
``tests.py``.
Documentation
-------------
- All documentation that makes use of a ``Configurator`` object to do
application setup and test setup now makes use of the new ``begin``
and ``end`` methods of the configurator.
Bug Fixes
---------
- When a ``repoze.bfg.exceptions.NotFound`` or
``repoze.bfg.exceptions.Forbidden`` *class* (as opposed to instance)
was raised as an exception within a root factory (or route root
factory), the exception would not be caught properly by the
``repoze.bfg.`` Router and it would propagate to up the call stack,
as opposed to rendering the not found view or the forbidden view as
would have been expected.
|
|
documentation chapter explaining the effect of raising
``repoze.bfg.exceptions.NotFound`` and
``repoze.bfg.exceptions.Forbidden`` from within view code.
- When the ``repoze.bfg.exceptions.NotFound`` or
``repoze.bfg.exceptions.Forbidden`` error is raised from within a
custom root factory or the ``factory`` of a route, the appropriate
response is now sent to the requesting user agent (the result of the
notfound view or the forbidden view, respectively). When these
errors are raised from within a root factory, the ``context`` passed
to the notfound or forbidden view will be ``None``. Also, the
request will not be decorated with ``view_name``, ``subpath``,
``context``, etc. as would normally be the case if traversal had
been allowed to take place.
|
|
event subscriber, as other predicates are now usually an easier way
to get this done.
|
|
|
|
|
|
|
|
|
|
configuration into account in more places and uses glossary
references more liberally.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
``repoze.bfg`` application.
|
|
|
|
|
|
explains how to override resources within one package from another
package.
|
|
``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.
|
|
|
|
URL paths.
|
|
|
