Audit grammar in bfgwik2 tutorial.

1 files changed, 19 insertions, 19 deletions

diff --git a/docs/tutorials/bfgwiki2/basiclayout.rst b/docs/tutorials/bfgwiki2/basiclayout.rst
index 89457b602..36cb8afd4 100644
--- a/docs/tutorials/bfgwiki2/basiclayout.rst
+++ b/docs/tutorials/bfgwiki2/basiclayout.rst
@@ -4,7 +4,7 @@ Basic Layout
 
 The starter files generated by the ``bfg_routesalchemy`` template are
 basic, but they provide a good orientation for the high-level patterns
-common to most :term:`url dispatch` -based BFG projects.
+common to most :term:`url dispatch` -based :mod:`repoze.bfg` projects.
 
 ``__init__.py``
 ---------------
@@ -16,15 +16,17 @@ directory as a Python package.
 Configuration With ``configure.zcml``
 --------------------------------------
 
-BFG uses a configuration markup language syntactically the same as
-Zope's implementation of :term:`ZCML`, but using a different default
-XML namespace.  Our sample ZCML file looks like the following:
+:mod:`repoze.bfg` uses a configuration markup language syntactically
+the same as Zope's implementation of :term:`ZCML`, but using a
+different default XML namespace.  Our sample ZCML file looks like the
+following:
 
    .. literalinclude:: src/basiclayout/tutorial/configure.zcml
       :linenos:
       :language: xml
 
-#. *Line 1*.  The root ``<configure>`` element, in a *BFG* namespace.
+#. *Line 1*.  The root ``<configure>`` element, in a ``bfg``
+   namespace.
 
 #. *Line 3*. Boilerplate, the comment explains.
 
@@ -50,7 +52,7 @@ XML namespace.  Our sample ZCML file looks like the following:
    declaration, we're saying that any URL that starts with ``/static``
    should go to the static view; any remainder of its path (e.g. the
    ``/foo`` in ``/static/foo``) will be used to compose a path to a
-   static file resource (CSS and such).  
+   static file resource, such as a CSS file.
 
 Content Models with ``models.py``
 ---------------------------------
@@ -101,10 +103,10 @@ Here is the source for ``models.py``:
 App Startup with ``run.py``
 ---------------------------
 
-How does a BFG application start up?  When you run under ``paster``
-using the ``tutorial.ini`` generated config file, the application area
-points at an entry point.  Our entry point happens to be in ``run.py``
-and its ``app`` function:
+How does a :mod:`repoze.bfg` application start up?  When you run under
+``paster`` using the ``tutorial.ini`` generated config file, the
+application area points at an entry point.  Our entry point happens to
+be in ``run.py`` and its ``app`` function:
 
    .. literalinclude:: src/basiclayout/tutorial/run.py
       :linenos:
@@ -131,12 +133,10 @@ and its ``app`` function:
 
 #. Line *26*.  We use the ``repoze.bfg.router.make_app`` to return a
    :term:`WSGI` application.  The ``make_app`` function's first
-   parameter is the "root factory", which is used by the BFG
-   :term:`traversal` mechanism.  Since this is a URL dispatch
-   application, the root factory is ``None``.  The second argument is
-   the *package* representing our application, and the third argument,
-   ``options`` is passed as a keyword argument.  It contains a
-   dictionary of options parsed by PasteDeploy.
-
-We'll later change ``run.py`` when we add :term:`authorization` to our
-wiki application.
+   parameter is the "root factory", which is used by the
+   :mod:`repoze.bfg` :term:`traversal` mechanism.  Since this is a URL
+   dispatch application, the root factory is ``None``.  The second
+   argument is the *package* representing our application, and the
+   third argument, ``options`` is passed as a keyword argument.  It
+   contains a dictionary of options parsed by PasteDeploy.
+