bfgwiki tutorial audit.

1 files changed, 20 insertions, 20 deletions

diff --git a/docs/tutorials/bfgwiki/basiclayout.rst b/docs/tutorials/bfgwiki/basiclayout.rst
index 1ec10094e..d69839c46 100644
--- a/docs/tutorials/bfgwiki/basiclayout.rst
+++ b/docs/tutorials/bfgwiki/basiclayout.rst
@@ -4,7 +4,8 @@ Basic Layout
 
 The starter files generated by the ``bfg_zodb`` template are basic,
 but they provide a good orientation for the high-level patterns common
-to most :term:`traversal` -based BFG (and BFG with ZODB) projects.
+to most :term:`traversal` -based :mod:`repoze.bfg` (and :term:`ZODB`
+based) projects.
 
 ``__init__.py``
 ---------------
@@ -16,17 +17,18 @@ directory as a Python package.
 Configuration With ``configure.zcml``
 --------------------------------------
 
-BFG uses a 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 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.
+#. *Line 4*. Boilerplate, the comment explains.
 
 #. *Lines 6-9*.  Register a ``<view>`` that is bound to a class.
    ``.views.my_view`` is a *function* we write (generated by the
@@ -44,10 +46,10 @@ namespace.  Our sample ZCML file looks like the following:
 Content Models with ``models.py``
 ---------------------------------
 
-BFG often uses the word *model* when talking about content resources
-arranged in a hierarchical *model graph*.  The ``models.py`` file is
-where the ``bfg_zodb`` Paster template put the classes that implement
-our models.
+:mod:`repoze.bfg` often uses the word *model* when talking about
+content resources arranged in a hierarchical *model graph*.  The
+``models.py`` file is where the ``bfg_zodb`` Paster template put the
+classes that implement our models.
 
 Here is the source for ``models.py``:
 
@@ -62,10 +64,10 @@ Here is the source for ``models.py``:
    that this is the :term:`root` object.
 
 #. *Lines 6-12*.  ``appmaker`` is used to return the *application
-   root* object.  It is called on *every request* to the BFG
-   application (it is essentially a :term:`root factory`).  It also
-   performs bootstrapping by *creating* an application root (inside
-   the ZODB root object) if one does not already exist.
+   root* object.  It is called on *every request* to the
+   :mod:`repoze.bfg` application.  It also performs bootstrapping by
+   *creating* an application root (inside the ZODB root object) if one
+   does not already exist.
  
    We do so by first seeing if the database has the persistent
    application root.  If not, we make an instance, store it, and
@@ -75,10 +77,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:
@@ -100,5 +102,3 @@ and its ``app`` function:
    factory (``get_root``), the *package* representing our application,
    and the keywords parsed by PasteDeploy.
 
-We'll later change ``run.py`` when we add :term:`authorization` to our
-wiki application.