| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
for all Chameleon BFG templates by setting a BFG-related Paster
``.ini`` file setting named ``debug_templates``. The exceptions
raised by Chameleon templates when a rendering fails are sometimes
less than helpful. ``debug_templates`` allows you to configure your
application development environment so that exceptions generated by
Chameleon during template compilation and execution will contain
more helpful debugging information. This mode is on by default in
all new projects.
|
|
$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
|
|
|
|
traceback when a renderer template cannot be found.
- Show the original traceback when a Chameleon template cannot be
rendered due to a platform incompatibility.
|
|
|
|
--------
- 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.
|
|
``Configurator.add_view`` or some derivative), they too-eagerly
attempted to look up the ``reload_templates`` setting via
``get_settings``, meaning they were always registered in
non-auto-reload-mode (the default). Each now waits until its
respective ``template`` attribute is accessed to look up the value.
|
|
``repoze.bfg.configuration`` module began to attempt to import the
``repoze.bfg.chameleon_zpt`` and ``repoze.bfg.chameleon_text``
modules, and these cannot be used on non-CPython platforms. It now
tolerates startup time import failures for these modules, and only
raise an import error when a template from one of these packages is
actually used.
|
|
request rather than a FakeRequest when it sets up the request as a
threadlocal.
- The ``repoze.bfg.traversal.traverse`` API now uses a 'real' WebOb
request rather than a FakeRequest when it calls the traverser.
- The ``repoze.bfg.request.FakeRequest`` class has been removed.
``repoze.bfg.url.route_url``
``repoze.bfg.url.model_url``
``repoze.bfg.url.static_url``
``repoze.bfg.traversal.virtual_root``
Each of these functions now expects to be called with a request
object that has a ``registry`` attribute which represents the
current ZCA registry.
Get rid of extraneous uses of ZCA threadlocal API.
|
|
ZCML directives which accept paths now register absolute paths, while
imperative registrations now register resource specifications.
|
|
|
|
|
|
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.
|
|
|
|
factory" (e.g. in the ``Router`` class) and ``webob.Response`` and
the "response factory" (e.g. in ``render_template_to_response``),
allow both to be overridden via a ZCML utility hook. See the "Using
ZCML Hooks" chapter of the documentation for more information.
|
|
where the template does not need to be wrapped in any containing
XML).
Prep for 0.4.9.
|
