Audit grammar in bfgwik2 tutorial.

1 files changed, 19 insertions, 18 deletions

diff --git a/docs/tutorials/bfgwiki2/authorization.rst b/docs/tutorials/bfgwiki2/authorization.rst
index ec6f44882..2e9bb0e19 100644
--- a/docs/tutorials/bfgwiki2/authorization.rst
+++ b/docs/tutorials/bfgwiki2/authorization.rst
@@ -19,11 +19,11 @@ 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
-order for 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 generate
-our contexts, we can begin to make use of the declarative security
-features of :mod:`repoze.bfg`.
+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
+generate our contexts, we can begin to make use of the declarative
+security features of :mod:`repoze.bfg`.
 
 Let's modify our ``run.py``, passing in a :term:`root factory` as the
 first argument to ``repoze.bfg.router.make_app``.  We'll point it at a
@@ -40,9 +40,9 @@ statements to your ``models.py`` file:
        def __init__(self, environ):
            self.__dict__.update(environ['bfg.routes.matchdict'])
 
-The ``RootFactory`` class we've just added will be used by BFG to
-construct a ``context`` object.  The context is attached to our
-request as the ``context`` attribute.
+The ``RootFactory`` class we've just added will be used by
+:mod:`repoze.bfg` to construct a ``context`` object.  The context is
+attached to our request as the ``context`` attribute.
 
 All of our context objects will possess an ``__acl__`` attribute that
 allows "Everyone" (a special principal) to view all pages, while
@@ -82,9 +82,10 @@ Changing ``configure.zcml``
 We'' 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 BFG detects
-that a view invocation can not be authorized.  When you're done, your
-``configure.zcml`` will look like so:
+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:
 
 .. literalinclude:: src/authorization/tutorial/configure.zcml
    :linenos:
@@ -184,13 +185,13 @@ We'll change our ``configure.zcml`` file to enable an
 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 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:
+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: