Rejigger tutorial in the face of request-only default views.

1 files changed, 5 insertions, 12 deletions

diff --git a/docs/tutorials/bfgwiki2/definingviews.rst b/docs/tutorials/bfgwiki2/definingviews.rst
index 25f52291c..df19a21c2 100644
--- a/docs/tutorials/bfgwiki2/definingviews.rst
+++ b/docs/tutorials/bfgwiki2/definingviews.rst
@@ -2,16 +2,10 @@
 Defining Views
 ==============
 
-Views in BFG are typically simple Python functions that accept two
-parameters: :term:`context`, and :term:`request`.  A view is assumed
-to return a :term:`response` object.
-
-A invocation of a view that matches a URL via :term:`url dispatch`
-passes as the context object an object generated by a ``root
-factory``.  In this application, the context will always be generated
-by the *default* root factory.  Since we're not using traversal in
-this application, this means the context will appear useless, at least
-until we get to :ref:`wiki2_adding_authorization`.
+Views in a :term:`url dispatch` -based BFG application are typically
+simple Python functions that accept a single parameter:
+::term:`request`.  A view is assumed to return a :term:`response`
+object.
 
 The request passed to every view that is called as the result of a
 route match has an attribute named ``matchdict`` that contains the
@@ -164,8 +158,7 @@ If the view rendering *is* a result of a form submission (if the
 expression ``'form.submitted' in request.params`` is True), the view
 grabs the ``body`` element of the request parameter and sets it as the
 ``data`` key in the matchdict.  It then redirects to the default view
-of the context (the page), which will always be the ``view_page``
-view.
+of the wiki page, which will always be the ``view_page`` view.
 
 Viewing the Result of Our Edits to ``views.py``
 ===============================================