- The matchdict related to the matching of a Routes route is available

  on the request as the ``matchdict`` attribute:
  ``request.matchdict``.  If no route matched, this attribute will be
  None.

1 files changed, 36 insertions, 27 deletions

diff --git a/docs/tutorials/bfgwiki2/definingviews.rst b/docs/tutorials/bfgwiki2/definingviews.rst
index 4d90db11f..25f52291c 100644
--- a/docs/tutorials/bfgwiki2/definingviews.rst
+++ b/docs/tutorials/bfgwiki2/definingviews.rst
@@ -7,13 +7,20 @@ 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 which has attributes matching
-the elements placed into the URL by the ``path`` of a ``route``
-statement.  For instance, if a route statement in ``configure.zcml``
-had the path ``:one/:two``, and the URL at
-``http://example.com/foo/bar`` was invoked, matching this path, the
-context object passed to the view would have a ``one`` attribute withe
-the value ``foo`` and a ``two`` attribute with the value ``bar``.
+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`.
+
+The request passed to every view that is called as the result of a
+route match has an attribute named ``matchdict`` that contains the
+elements placed into the URL by the ``path`` of a ``route`` statement.
+For instance, if a route statement in ``configure.zcml`` had the path
+``:one/:two``, and the URL at ``http://example.com/foo/bar`` was
+invoked, matching this path, the matchdict dictionary attached to the
+request passed to the view would have a ``one`` key withe the value
+``foo`` and a ``two`` key with the value ``bar``.
 
 Declaring Dependencies in Our ``setup.py`` File
 ===============================================
@@ -111,14 +118,14 @@ The ``add_page`` function will be invoked when a user clicks on a
 *WikiWord* which isn't yet represented as a page in the system.  The
 ``check`` function within the ``view_page`` view generates URLs to
 this view.  It also acts as a handler for the form that is generated
-when we want to add a page object.  The ``context`` of the
-``add_page`` view will always have the attributes we need to
-construct URLs and find model objects.
+when we want to add a page object.  The ``matchdict`` attribute of the
+request passed to the ``add_page`` view will have the values we need
+to construct URLs and find model objects.
 
-The context object will have a ``pagename`` attribute that matches the
-name of the page we'd like to add.  If our add view is invoked via,
+The matchdict will have a ``pagename`` key that matches the name of
+the page we'd like to add.  If our add view is invoked via,
 e.g. ``http://localhost:6543/add_page/SomeName``, the ``pagename``
-attribute of the context will be ``SomeName``.
+value in the matchdict will be ``SomeName``.
 
 If the view rendering is *not* a result of a form submission (if the
 expression ``'form.submitted' in request.params`` is False), the view
@@ -133,7 +140,7 @@ response.
 If the view rendering *is* a result of a form submission (if the
 expression ``'form.submitted' in request.params`` is True), we scrape
 the page body from the form data, create a Page object using the name
-in ``pagename`` context attribute and obtain the page body from the
+in the matchdict ``pagename``, and obtain the page body from the
 request, and save it into the database using ``session.add``.  We then
 redirect back to the ``view_page`` view (the default view for a page)
 for the newly created page.
@@ -143,9 +150,10 @@ The ``edit_page`` view function
 
 The ``edit_page`` function will be invoked when a user clicks the
 "Edit this Page" button on the view form.  It renders an edit form but
-it also acts as the handler for the form it renders.  The ``context``
-of the ``edit_page`` view will *always* have a ``pagename`` attribute
-matching the name of the page the user wants to edit. 
+it also acts as the handler for the form it renders.  The
+``matchdict`` attribute of the request passed to the ``add_page`` view
+will have a ``pagename`` key matching the name of the page the user
+wants to edit.
 
 If the view rendering is *not* a result of a form submission (if the
 expression ``'form.submitted' in request.params`` is False), the view
@@ -155,9 +163,9 @@ and a save_url which will be used as the action of the generated form.
 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`` attribute of the page context.  It then redirects to the
-default view of the context (the page), which will always be the
-``view_page`` view.
+``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.
 
 Viewing the Result of Our Edits to ``views.py``
 ===============================================
@@ -234,14 +242,15 @@ number and type of static resources can be placed in this directory
 Mapping Views to URLs in ``configure.zcml``
 ===========================================
 
-The ``configure.zcml`` file contains ``route`` declarations which
-serve to map URLs (via :term:`url dispatch`) to view functions.
-First, we’ll get rid of the existing ``route`` created by the
-template using the name ``home``. It’s only an example and isn’t
-relevant to our application. We'll leave the static ``route``
-declaration as it is, since we are going to use it for the CSS.
+The ``configure.zcml`` file contains ``route`` declarations (and a
+lone ``view`` declaration) which serve to map URLs (via :term:`url
+dispatch`) to view functions.  First, we’ll get rid of the existing
+``route`` created by the template using the name ``home``. It’s only
+an example and isn’t relevant to our application. We'll leave the
+static ``view`` declaration as it is, since we are going to use it to
+serve CSS.
 
-We then need to add four ``view`` declarations to ``configure.zcml``.
+We then need to add four ``route`` declarations to ``configure.zcml``.
 Note that the *ordering* of these declarations is very important.
 ``route`` declarations are matched in the order they're found in the
 ``configure.zcml`` file.