I love to delete lines.

5 files changed, 25 insertions, 154 deletions

diff --git a/docs/api/template.rst b/docs/api/template.rst
index 93b02a413..85e1989e6 100644
--- a/docs/api/template.rst
+++ b/docs/api/template.rst
@@ -7,4 +7,9 @@
 
 .. autofunction:: render_template
 
+.. autofunction:: render_template_to_response
+
 .. autofunction:: render_transform
+
+.. autofunction:: render_transform_to_response
+
diff --git a/docs/index.rst b/docs/index.rst
index 60488f0d3..d295c05d3 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -34,7 +34,6 @@ and run a web application.
    api/router
    api/security
    api/template
-   api/view
 
 Indices and tables
 ==================
diff --git a/docs/narr/introduction.rst b/docs/narr/introduction.rst
index 66dc07121..2d63a2659 100644
--- a/docs/narr/introduction.rst
+++ b/docs/narr/introduction.rst
@@ -144,23 +144,10 @@ response
   upstream), and status (representing the http status string).  This
   is the interface defined for ``WebOb`` response objects.
 
-mapply
+view
 
-  code which dynamically ("magically") determines which arguments to
-  pass to a view based on environment and request parameters.
-
-view factory and view
-
-  A "view factory" is a callable which returns a view object.  It
-  should accept two values: context and request.
-
-  A "view" is a callable that accepts arbitrary values (mapped into it
-  by "mapply") and which returns a response object.
-
-  A view factory may *be* a view in a repoze.bfg application
-  (e.g. it may accept "context" and "request" and return a response
-  object directly instead of returning a view object).  This makes it
-  possible to support views as simple functions.
+  A "view" is a callable which returns a response object.  It should
+  accept two values: context and request.
 
 view name
 
@@ -178,10 +165,10 @@ context
 
   A model in the system that is the subject of a view.
 
-view registry
+view registry (aka application registry)
 
-  A registry which maps a context and view name to a view factory
-  and optionally a permission.
+  A registry which maps a context and view name to a view callable and
+  optionally a permission.
 
 template
 
@@ -278,18 +265,13 @@ code to execute:
 
  8.  Armed with the context, the view name, and the subpath, the
      router performs a view lookup.  It attemtps to look up a view
-     factory from the ``repoze.bfg`` view registry using the view
-     name and the context.  If a view factory is found, it is
-     converted into a WSGI application: it is "wrapped in" ( aka
-     "adapted to") a WSGI application using mapply.  The WSGI adapter
-     uses mapply to map request and environment variables into the
-     view when it is called.  If a view factory is not found, a
-     generic WSGI ``NotFound`` application is constructed. 
-
-In either case, the resulting WSGI application is called.  The WSGI
-application's return value is an iterable.  This is returned upstream
-to the WSGI server.  The WSGI application also calls start_response
-with a status code and a header list.
+     from the ``repoze.bfg`` view registry using the view name and the
+     context.  If a view factory is found, it is called with the
+     context and the request.  It returns a response, which is fed
+     back upstream.  If a view is not found, a generic WSGI
+     ``NotFound`` application is constructed.
+
+In either case, the result is returned upstream via the WSGI protocol.
 
 A Traversal Example
 -------------------
@@ -479,16 +461,16 @@ A view registry might look like so::
     <!-- the default view for a MyModel -->
     <bfg:view
         for=".models.IMyModel"
-        factory=".views.my_hello_view"
-        permission="repoze.view"
+        view=".views.my_hello_view"
+        permission="read"
         />
 
     <!-- the templated.html view for a MyModel -->
     <bfg:view
         for=".models.IMyModel"
-        factory=".views.my_template_view"
+        view=".views.my_template_view"
         name="templated.html"
-        permission="repoze.view"
+        permission="read"
         />
 
   </configure>
diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index 5c61cd0da..294bff8db 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -30,7 +30,7 @@ You can also wire up page templates via ZCML:
 
   <bfg:view
       for=".models.IMapping"
-      factory=".views.contents_view"
+      view=".views.contents_view"
       name="contents.html"
       />
 
diff --git a/docs/narr/views.rst b/docs/narr/views.rst
index 75260e236..a349901bb 100644
--- a/docs/narr/views.rst
+++ b/docs/narr/views.rst
@@ -17,123 +17,8 @@ world view implemented as a function::
       from webob import Response
       return Response('Hello world!')
 
-Defining View Factories
------------------------
-
-Declarations in your view registry to point at a *view factory*
-rather than pointing it at a view implemented as a function.  This
-provides an additional level of convenience for some applications.
-
-A view factory, like a view implemented as a function, accepts the
-*context* and *request* arguments.  But unlike a view implemented as a
-function it returns *another* callable instead of a response.  The
-returned callable is then called by ``repoze.bfg``, with its arguments
-filled in "magically".
-
-The easiest way to implement a view factory is to implement it as a
-class.  Here's a hello world view factory that is implemented as a
-class::
-
-  class HelloWorld(object):
-      def __init__(self, context, request):
-          self.context = context
-          self.request = request
-
-      def __call__(self):
-          from webob import Response
-          return Response('Hello world!')
-
-You can also implement a view factory as a function::
-
-  def HelloWorld(context, request):
-      def hello_world():
-          from webob import Response
-          return Response('Hello world!')
-      return hello_world
-
-Using View Factories for Convenience
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-View factories aren't just makework.  They exist for convenience,
-because, unlike views as functions, views that are returned via a view
-factory will have arguments "magically" mapped into them when they are
-called by the router.  You can choose the arguments you'd like the
-constructed view to receive simply by mentioning each in the signature
-of the callable you return from the view factory (or the __call__ of
-the class you use as the view factory).
-
-The arguments that are available to be magically mapped into
-constructed view calls are as follows.
-
-context
-
-  The current context
-
-request
-
-  The current request
-
-environ
-
-  The current WSGI environment
-
-start_response
-
-  The current  WSGI start_response callable
-
-XXX We need to decide which other elements will be mapped in from the
-request and map them in: e.g. query string/form elements, etc.
-
-This means that the ``__call__`` of the following view factory
-will have its *environ* and *start_response* arguments filled in
-magically during view call time::
-
-  def ViewFactory(object):
-      def __init__(self, context, request):
-          self.context = context
-          self.request = request
-
-      def __call__(self, environ, start_response):
-          msg = 'Called via %s ' % environ['PATH_INFO']
-          start_response('200 OK', ('Content-Length', len(msg))
-          return msg
-
-.. note:: If you're familiar with WSGI, you'll notice above that the
-  view factory returns a valid WSGI application.  View
-  factories in ``repoze.bfg`` can return any WSGI application.
-
-View Functions Revisited
-------------------------
-
-Above we provided an example of a "view" implemented as a function::
-
-  def hello_world(context, request):
-      from webob import Response
-      return Response('Hello world!')
-
-When ``repoze.bfg`` finds and calls this callable, has no a-priori
-knowledge that would allow it to believe that this function would
-return a response directly.  It assumes that what it's calling will
-return a *view* instead of a *response*.  In other words, it expects
-that everything configured in its view registry points at a view
-factory.
-
-However, there is a special case in the logic implemented in the
-``repoze.bfg`` router that says if the return value of a view
-factory is an object implementing the Response interface, use that
-object as the response, and don't try to call the object or magically
-map any arguments into it.  Instead, it just passes it along to the
-upstream WSGI server.
-
-This is purely for convenience: it's useful to be able to define
-simple functions as "views" without the overhead of defining a view
-factory.
-
-View Factory Arguments
-----------------------
-
-Now that we know what view factories are, what are these *context*
-and *request* arguments that are mapped in to it?
+View Arguments
+--------------
 
 context