diff options
| author | Chris McDonough <chrism@agendaless.com> | 2009-09-14 07:55:36 +0000 |
|---|---|---|
| committer | Chris McDonough <chrism@agendaless.com> | 2009-09-14 07:55:36 +0000 |
| commit | 4eb45e9de657bedeb0b03469781c35758500dfa2 (patch) | |
| tree | 0d4a7b93f08248425af04dcc38d447c1e25e66ad /CHANGES.txt | |
| parent | 7dbf3ffc6e3d27dbebe3b32ff6d4c97f6a81de92 (diff) | |
| download | pyramid-4eb45e9de657bedeb0b03469781c35758500dfa2.tar.gz pyramid-4eb45e9de657bedeb0b03469781c35758500dfa2.tar.bz2 pyramid-4eb45e9de657bedeb0b03469781c35758500dfa2.zip | |
- 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).
Diffstat (limited to 'CHANGES.txt')
| -rw-r--r-- | CHANGES.txt | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/CHANGES.txt b/CHANGES.txt index 26c180d9d..91c16a362 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,20 @@ +Next release +============ + +- 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). + 1.1a2 (2009-09-14) ================== |