diff options
Diffstat (limited to 'docs/tutorials/bfgwiki2/definingviews.rst')
| -rw-r--r-- | docs/tutorials/bfgwiki2/definingviews.rst | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/docs/tutorials/bfgwiki2/definingviews.rst b/docs/tutorials/bfgwiki2/definingviews.rst index a75f4b74b..c7f9ba945 100644 --- a/docs/tutorials/bfgwiki2/definingviews.rst +++ b/docs/tutorials/bfgwiki2/definingviews.rst @@ -8,7 +8,7 @@ single parameter named :term:`request`. A view is assumed to return a :term:`response` object. .. note:: A :mod:`repoze.bfg` view can also be defined as callable - which accepts *two* arguments: a :term:`context` and ` + which accepts *two* arguments: a :term:`context` and a :term:`request`. You'll see this two-argument pattern used in other :mod:`repoze.bfg` tutorials and applications. Either calling convention will work in any :mod:`repoze.bfg` application. In @@ -25,14 +25,14 @@ 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 +request passed to the view would have a ``one`` key with the value ``foo`` and a ``two`` key with the value ``bar``. Declaring Dependencies in Our ``setup.py`` File =============================================== -The view code in our application will depend a package which is not a -dependency of the original "tutorial" application. The original +The view code in our application will depend on a package which is not +a dependency of the original "tutorial" application. The original "tutorial" application was generated by the ``paster create`` command; it doesn't know about our custom application requirements. We need to add a dependency on the ``docutils`` package to our ``tutorial`` @@ -74,7 +74,7 @@ The ``view_wiki`` function will respond as the default view of a ``Wiki`` model object. It always redirects to a URL which represents the path to our "FrontPage". It returns an instance of the ``webob.exc.HTTPFound`` class (instances of which implement the WebOb -:term:`response` interface), It will use the the +:term:`response` interface), It will use the ``repoze.bfg.url.route_url`` API to construct a URL to the ``FrontPage`` page (e.g. ``http://localhost:6543/FrontPage``), and will use it as the "location" of the HTTPFound response, forming an @@ -325,8 +325,8 @@ our application in a browser. The views we'll try are as follows: browser invokes the ``view_wiki`` view. This always redirects to the ``view_page`` view of the FrontPage page object. -- Visiting `http://localhost:6543/FrontPage/ - <http://localhost:6543/FrontPage/>`_ in a browser invokes the +- Visiting `http://localhost:6543/FrontPage + <http://localhost:6543/FrontPage>`_ in a browser invokes the ``view_page`` view of the front page page object. - Visiting `http://localhost:6543/FrontPage/edit_page |