specify ordering unimportance

1 files changed, 17 insertions, 13 deletions

diff --git a/docs/tutorials/wiki/authorization.rst b/docs/tutorials/wiki/authorization.rst
index 57c4a3ce5..1b66ace96 100644
--- a/docs/tutorials/wiki/authorization.rst
+++ b/docs/tutorials/wiki/authorization.rst
@@ -83,20 +83,24 @@ and logout views.  Add a file named ``login.py`` to your application
    :language: python
 
 Note that the ``login`` view callable in the ``login.py`` file has *two* view
-configuration decorators.  In the first view configuration decorator, we
-configured the ``login`` view callable so it will be invoked when someone
-visits ``/login`` (when the context is a Wiki and the view name is
-``login``).  The second decorator (with context of
+configuration decorators.  The order of these decorators is unimportant.
+Each just adds a different :term:`view configuration` for the ``login`` view
+callable.
+
+The first view configuration decorator configures the ``login`` view callable
+so it will be invoked when someone visits ``/login`` (when the context is a
+Wiki and the view name is ``login``).  The second decorator (with context of
 ``pyramid.exceptions.Forbidden``) specifies a :term:`forbidden view`.  This
-configures our login view to show up when :app:`Pyramid` detects that a view
-invocation can not be authorized.  Because we've configured a forbidden view,
-the ``login`` view callable will be invoked whenever one of our users tries
-to execute a view callable that they are disallowed from invoking based on
-the :term:`authorization policy` in use.  In our application, for example,
-this means that if a user has not logged in, and he tries to add or edit a
-Wiki page, he will be shown the login form.  Before being allowed to continue
-on to the add or edit form, he will have to provide credentials that give him
-permission to add or edit via this login form.
+configures our login view to be presented to the user when :app:`Pyramid`
+detects that a view invocation can not be authorized.  Because we've
+configured a forbidden view, the ``login`` view callable will be invoked
+whenever one of our users tries to execute a view callable that they are not
+allowed to invoke as determined by the :term:`authorization policy` in use.
+In our application, for example, this means that if a user has not logged in,
+and he tries to add or edit a Wiki page, he will be shown the login form.
+Before being allowed to continue on to the add or edit form, he will have to
+provide credentials that give him permission to add or edit via this login
+form.
 
 Changing Existing Views
 ~~~~~~~~~~~~~~~~~~~~~~~