- Minor edits to tutorials for accuracy based on feedback.

- Back to dev.

5 files changed, 40 insertions, 53 deletions

diff --git a/docs/tutorials/bfgwiki/installation.rst b/docs/tutorials/bfgwiki/installation.rst
index 63a770299..53adec6bd 100644
--- a/docs/tutorials/bfgwiki/installation.rst
+++ b/docs/tutorials/bfgwiki/installation.rst
@@ -21,7 +21,7 @@ Preparation, UNIX
    your system, obtain, install, or find `Python 2.5
    <http://python.org/download/releases/2.5.4/>`_ for your system.
 
-#. Install latest `setuptools` into the Python you
+#. Install the latest `setuptools` into the Python you
    obtained/installed/found in the step above: download `ez_setup.py
    <http://peak.telecommunity.com/dist/ez_setup.py>`_ and run it using
    the ``python`` interpreter of your Python 2.5 installation:
@@ -73,7 +73,7 @@ Preparation, Windows
 #. Install, or find `Python 2.5
    <http://python.org/download/releases/2.5.4/>`_ for your system.
 
-#. Install latest `setuptools` into the Python you
+#. Install the latest `setuptools` into the Python you
    obtained/installed/found in the step above: download `ez_setup.py
    <http://peak.telecommunity.com/dist/ez_setup.py>`_ and run it using
    the ``python`` interpreter of your Python 2.5 installation using a
diff --git a/docs/tutorials/bfgwiki2/authorization.rst b/docs/tutorials/bfgwiki2/authorization.rst
index 7e86bd126..d4ec03eb2 100644
--- a/docs/tutorials/bfgwiki2/authorization.rst
+++ b/docs/tutorials/bfgwiki2/authorization.rst
@@ -18,7 +18,7 @@ Adding A Root Factory
 
 We're going to start to use a custom :term:`root factory` within our
 ``run.py`` file.  The objects generated by the root factory will be
-used as the :term:`context` of each of request to our application.  In
+used as the :term:`context` of each request to our application.  In
 order for :mod:`repoze.bfg` declarative security to work properly, the
 context object generated during a request must be decorated with
 security declarations; when we begin to use a custom root factory to
@@ -63,14 +63,14 @@ Configuring a ``repoze.bfg`` Authentication Policy
 For any :mod:`repoze.bfg` application to perform authorization, we
 need to add a ``security.py`` module and we'll need to change our
 :term:`application registry` to add an :term:`authentication policy`
-and a :term:`authorization policy`.
+and an :term:`authorization policy`.
 
 Changing ``run.py``
 ~~~~~~~~~~~~~~~~~~~
 
-We'll use the opportunity to pass the ``RootFactory`` we created in
-the step above in as the first argument to ``make_app``.  When we're
-done, your application's ``run.py`` will look like this.
+We'll pass the ``RootFactory`` we created in the step above in as the
+first argument to ``make_app``.  When we're done, your application's
+``run.py`` will look like this.
 
 .. literalinclude:: src/authorization/tutorial/run.py
    :linenos:
@@ -79,13 +79,20 @@ done, your application's ``run.py`` will look like this.
 Changing ``configure.zcml``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-We'' change our ``configure.zcml`` file to enable an
+We'll change our ``configure.zcml`` file to enable an
 ``AuthTktAuthenticationPolicy`` and an ``ACLAuthorizationPolicy`` to
 enable declarative security checking.  We'll also add a ``forbidden``
 stanza.  This configures our login view to show up when
 :mod:`repoze.bfg` detects that a view invocation can not be
-authorized.  When you're done, your ``configure.zcml`` will look like
-so:
+authorized.  We'll also change ``configure.zcml`` to add a
+``forbidden`` stanza which points at our login view.  This configures
+our newly created login view to show up when :mod:`repoze.bfg` detects
+that a view invocation can not be authorized.  Also, we'll add
+``permission`` attributes with the value ``edit`` to the ``edit_page``
+and ``add_page`` routes.  This indicates that the views which these
+routes reference cannot be invoked without the authenticated user
+possessing the ``edit`` permission with respect to the current
+context.  When you're done, your ``configure.zcml`` will look like so
 
 .. literalinclude:: src/authorization/tutorial/configure.zcml
    :linenos:
@@ -97,7 +104,7 @@ Adding ``security.py``
 Add a ``security.py`` module within your package (in the same
 directory as "run.py", "views.py", etc) with the following content:
 The groupfinder defined here is an authorization policy "callback"; it
-is a be a callable that accepts a userid and a request.  If the userid
+is a a callable that accepts a userid and a request.  If the userid
 exists in the system, the callback will return a sequence of group
 identifiers (or an empty sequence if the user isn't a member of any
 groups).  If the userid *does not* exist in the system, the callback
@@ -177,26 +184,6 @@ class="main_content">`` div:
 
    <span tal:condition="logged_in"><a href="${request.application_url}/logout">Logout</a></span>
 
-Changing ``configure.zcml``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-We'll change our ``configure.zcml`` file to enable an
-``AuthTktAuthenticationPolicy`` and an ``ACLAuthorizationPolicy`` to
-enable declarative security checking.  We'll also change
-``configure.zcml`` to add a ``forbidden`` stanza which points at our
-login view.  This configures our newly created login view to show up
-when :mod:`repoze.bfg` detects that a view invocation can not be
-authorized.  Also, add ``permission`` attributes with the value
-``edit`` to the ``edit_page`` and ``add_page`` routes.  This indicates
-that the views which these routes reference cannot be invoked without
-the authenticated user possessing the ``edit`` permission with respect
-to the current context.  When you're done, your ``configure.zcml``
-will look like so:
-
-.. literalinclude:: src/authorization/tutorial/configure.zcml
-   :linenos:
-   :language: xml
-
 Viewing the Application in a Browser
 ------------------------------------
 
@@ -208,8 +195,8 @@ our application in a browser.  The views we'll try are as follows:
   the ``view_page`` view of the FrontPage page object.  It is
   executable by any user.
 
-- 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 FrontPage page object.
 
 - Visiting `http://localhost:6543/FrontPage/edit_page
diff --git a/docs/tutorials/bfgwiki2/definingmodels.rst b/docs/tutorials/bfgwiki2/definingmodels.rst
index 6f4809199..982865a80 100644
--- a/docs/tutorials/bfgwiki2/definingmodels.rst
+++ b/docs/tutorials/bfgwiki2/definingmodels.rst
@@ -30,16 +30,16 @@ code generated by our ``routesalchemy`` paster template does not use
 declarative SQLAlchemy syntax, so we'll need to change various things to
 begin to use declarative syntax.
 
-Our ``Page`` class will have a class level attributes
-``__tablename__`` which equals the string ``pages``.  This means that
-SQLAlchemy will store our wiki data in a SQL table named ``pages``.
-Our Page class will also have class-level attributes named ``id``,
-``pagename`` and ``data`` (all instances of ``sqlalchemy.Column``).
-These will map to columns in the ``pages`` table.  The ``id``
-attribute will be the primary key in the table.  The ``name``
-attribute will be a text attribute, each value of which needs to be
-unique within the column.  The ``data`` attribute is a text attribute
-that will hold the body of each page.
+Our ``Page`` class will have a class level attribute ``__tablename__``
+which equals the string ``pages``.  This means that SQLAlchemy will
+store our wiki data in a SQL table named ``pages``.  Our Page class
+will also have class-level attributes named ``id``, ``pagename`` and
+``data`` (all instances of ``sqlalchemy.Column``).  These will map to
+columns in the ``pages`` table.  The ``id`` attribute will be the
+primary key in the table.  The ``name`` attribute will be a text
+attribute, each value of which needs to be unique within the column.
+The ``data`` attribute is a text attribute that will hold the body of
+each page.
 
 We'll also remove our ``populate`` function.  We'll inline the
 populate step into ``initialize_sql``, changing our ``initialize_sql``
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
diff --git a/docs/tutorials/bfgwiki2/installation.rst b/docs/tutorials/bfgwiki2/installation.rst
index a6ba6fbfa..e48ae8ec7 100644
--- a/docs/tutorials/bfgwiki2/installation.rst
+++ b/docs/tutorials/bfgwiki2/installation.rst
@@ -21,7 +21,7 @@ Preparation, UNIX
    your system, obtain, install, or find `Python 2.5
    <http://python.org/download/releases/2.5.4/>`_ for your system.
 
-#. Install latest `setuptools` into the Python you
+#. Install the latest `setuptools` into the Python you
    obtained/installed/found in the step above: download `ez_setup.py
    <http://peak.telecommunity.com/dist/ez_setup.py>`_ and run it using
    the ``python`` interpreter of your Python 2.5 installation:
@@ -70,7 +70,7 @@ Preparation, Windows
 #. Install, or find `Python 2.5
    <http://python.org/download/releases/2.5.4/>`_ for your system.
 
-#. Install latest `setuptools` into the Python you
+#. Install the latest `setuptools` into the Python you
    obtained/installed/found in the step above: download `ez_setup.py
    <http://peak.telecommunity.com/dist/ez_setup.py>`_ and run it using
    the ``python`` interpreter of your Python 2.5 installation using a
@@ -101,7 +101,7 @@ Preparation, Windows
 #. (Optional) Consider using ``bin\activate.bat`` to make your shell
    environment wired to use the virtualenv.
 
-#. Use ``easy_install`` and point to the BFG "current index to get
+#. Use ``easy_install`` and point to the BFG "current" index to get
    :mod:`repoze.bfg` and its direct dependencies installed:
 
    .. code-block:: bat