repoze.bfg 1.1a3 has been released. It is available via:
easy_install -i http://dist.repoze.org/bfg/dev repoze.bfg
This release is a feature release. It's sorta kinda major.
In 1.0.X releases, when a view callable returned a non-Response return value,
BFG would eventually throw an error, because... well, views weren't allowed to
return anything except Response objects. That was just the rule.
Now, this has changed. When a view has a "renderer" associated with it (by
virtue of the 'renderer' attribute in ZCML or the equivalent in a "bfg_view"
declaration), ia view is permitted to return any value that can be understood
by the associated renderer. A renderer is responsible for converting the value
into a string. Examples of renderers:
- A renderer which converts a dictionary return value into a string
rendered by atemplating system
<view
view=".views.my_view"
renderer="templates/my_template.pt"
/>
def my_view(context, request):
return {'This': 'might be used by the template'}
- A renderer which converts any basic-type return value from a view into
a JSON serialization.
<view
view=".views.my_view"
renderer="json"
/>
def my_view(context, request):
return ['This will be serialized to JSON']
Note that the "renderer" directive replaces the "template" directive as
documented in the changelog for 1.1a2.
See also
http://docs.repoze.org/bfg/1.1/narr/views.html#writing-views-which-use-a-renderer
Additional renderers can be added via the "renderer" ZCML directive:
<renderer
factory="my.package.MyRenderer"
name="coolrenderer"
/>
See also
http://docs.repoze.org/bfg/1.1/narr/views.html#adding-and-overriding-renderers
An additional feature allows you to assign a "wrapper" attribute to view
configuration. This makes it possible to spell wrapper relationships between
views via ZCML (or "bfg_view") configuration. See the documentation for the
"wrapper" attribute inside this documentation section:
http://docs.repoze.org/bfg/1.1/narr/views.html#the-view-zcml-directive
The exhhaustive changelog follows.
1.1a3 (2009-09-16)
==================
Documentation
-------------
- The "Views" narrative chapter in the documentation has been updated
extensively to discuss "renderers".
Features
--------
- A ``renderer`` attribute has been added to view configurations,
replacing the previous (1.1a2) version's ``template`` attribute. A
"renderer" is an object which accepts the return value of a view and
converts it to a string. This includes, but is not limited to,
templating systems.
- A new interface named ``IRenderer`` was added. The existing
interface, ``ITemplateRenderer`` now derives from this new
interface. This interface is internal.
- A new interface named ``IRendererFactory`` was added. An existing
interface named ``ITemplateRendererFactory`` now derives from this
interface. This interface is internal.
- The ``view`` attribute of the ``view`` ZCML directive is no longer
required if the ZCML directive also has a ``renderer`` attribute.
This is useful when the renderer is a template renderer and no names
need be passed to the template at render time.
- A new zcml directive ``renderer`` has been added. It is documented
in the "Views" narrative chapter of the documentation.
- A ZCML ``view`` directive (and the associated ``bfg_view``
decorator) can now accept a "wrapper" value. If a "wrapper" value
is supplied, it is the value of a separate view's *name* attribute.
When a view with a ``wrapper`` attribute is rendered, the "inner"
view is first rendered normally. Its body is then attached to the
request as "wrapped_body", and then a wrapper view name is looked up
and rendered (using ``repoze.bfg.render_view_to_response``), passed
the request and the context. The wrapper view is assumed to do
something sensible with ``request.wrapped_body``, usually inserting
its structure into some other rendered template. This feature makes
it possible to specify (potentially nested) "owrap" relationships
between views using only ZCML or decorators (as opposed always using
ZPT METAL and analogues to wrap view renderings in outer wrappers).
Dependencies
------------
- When used under Python < 2.6, BFG now has an installation time
dependency on the ``simplejson`` package.
Deprecations
------------
- The ``repoze.bfg.testing.registerDummyRenderer`` API has been
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"; its existence has been removed from the
documentation, however.
- 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.
Backwards Incompatibilities
---------------------------
- The ``ITemplateRenderer`` interface has been changed. Previously
its ``__call__`` method accepted ``**kw``. It now accepts a single
positional parameter named ``kw``. This is mostly an internal
change, but it was exposed in APIs in one place: if you've used the
``repoze.bfg.testing.registerDummyRenderer`` API in your tests with
a custom "renderer" argument with your own renderer implementation,
you will need to change that renderer implementation to accept
``kw`` instead of ``**kw`` in its ``__call__`` method.
- The ``ITemplateRendererFactory`` interface has been changed.
Previously its ``__call__`` method accepted an ``auto_reload``
keyword parameter. Now its ``__call__`` method accepts no keyword
parameters. Renderers are now themselves responsible for
determining details of auto-reload. This is purely an internal
change. This interface was never external.
- The ``template_renderer`` ZCML directive introduced in 1.1a2 has
been removed. It has been replaced by the ``renderer`` directive.
- The previous release (1.1a2) added a view configuration attribute
named ``template``. In this release, the attribute has been renamed
to ``renderer``. This signifies that the attribute is more generic:
it can now be not just a template name but any renderer name (ala
``json``).
- In the previous release (1.1a2), the Chameleon text template
renderer was used if the system didn't associate the ``template``
view configuration value with a filename with a "known" extension.
In this release, you must use a ``renderer`` attribute which is a
path that ends with a ``.txt`` extension
(e.g. ``templates/foo.txt``) to use the Chameleon text renderer.
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
