Merge branch 'viewderiver'

Conflicts:
	pyramid/config.py

1 files changed, 33 insertions, 0 deletions

diff --git a/CHANGES.txt b/CHANGES.txt
index e7ecad31a..743f20e3b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -9,6 +9,23 @@ Bug Fixes
   Instead of trying to resolve the view, if it cannot, it will now just print
   ``<unknown>``.
 
+Features
+--------
+
+- ``config.add_view`` now accepts a ``decorator`` keyword argument, a callable
+  which will decorate the view callable before it is added to the registry.
+
+- ``config.add_view`` now accepts a ``view_mapper`` keyword argument, which
+  should be a class which implements the new
+  ``pyramid.interfaces.IViewMapperFactory`` interface.  Use of an alternate
+  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".
+
+- If a handler class provides an __action_decorator__ attribute (usually a
+  classmethod or staticmethod), use that as the decorator for each view
+  registration for that handler.
+
 Documentation
 -------------
 
@@ -16,6 +33,22 @@ Documentation
   removed from the tutorials section.  It was moved to the
   ``pyramid_tutorials`` Github repository.
 
+Internals
+---------
+
+- The "view derivation" code is now factored into a set of classes rather
+  than a large number of standalone functions (a side effect of the
+  ``view_mapper`` refactoring).
+
+- The ``pyramid.renderer.RendererHelper`` class has grown a ``render_view``
+  method, which is used by the default view mapper (a side effect of the
+  ``view_mapper`` refactoring).
+
+- The object passed as ``renderer`` to the "view deriver" is now an instance
+  of ``pyramid.renderers.RendererHelper`` rather than a dictionary (a side
+  effect of ``view_mapper`` refactoring).
+
+
 1.0a8 (2010-12-27)
 ==================