- All references to Pyramid-the-application were changed from :mod:`pyramid`

  to :app:`Pyramid`.  A custom role setting was added to ``docs/conf.py`` to
  allow for this.  (internal)

9 files changed, 28 insertions, 28 deletions

diff --git a/docs/tutorials/wiki/authorization.rst b/docs/tutorials/wiki/authorization.rst
index e63a610c2..062c553b5 100644
--- a/docs/tutorials/wiki/authorization.rst
+++ b/docs/tutorials/wiki/authorization.rst
@@ -7,7 +7,7 @@ view, edit, and add pages to our wiki.  For purposes of demonstration
 we'll change our application to allow people whom are members of a
 *group* named ``group:editors`` to add and edit wiki pages but we'll
 continue allowing anyone with access to the server to view pages.
-:mod:`pyramid` provides facilities for *authorization* and
+:app:`Pyramid` provides facilities for *authorization* and
 *authentication*.  We'll make use of both features to provide security
 to our application.
 
@@ -19,7 +19,7 @@ The source code for this tutorial stage can be browsed via
 Configuring a ``pyramid`` Authentication Policy
 --------------------------------------------------
 
-For any :mod:`pyramid` application to perform authorization, we
+For any :app:`Pyramid` 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`.
@@ -31,7 +31,7 @@ We'll change our ``configure.zcml`` file to enable an
 ``AuthTktAuthenticationPolicy`` and an ``ACLAuthorizationPolicy`` to
 enable declarative security checking.  We'll also add a new view
 stanza, which specifies a :term:`forbidden view`.  This configures our
-login view to show up when :mod:`pyramid` detects that a view
+login view to show up when :app:`Pyramid` detects that a view
 invocation can not be authorized.  When you're done, your
 ``configure.zcml`` will look like so:
 
@@ -146,7 +146,7 @@ Giving Our Root Model Object an ACL
 -----------------------------------
 
 We need to give our root model object an :term:`ACL`.  This ACL will
-be sufficient to provide enough information to the :mod:`pyramid`
+be sufficient to provide enough information to the :app:`Pyramid`
 security machinery to challenge a user who doesn't have appropriate
 credentials when he attempts to invoke the ``add_page`` or
 ``edit_page`` views.
@@ -171,7 +171,7 @@ class scope to our ``Wiki`` class:
 
 It's only happenstance that we're assigning this ACL at class scope.
 An ACL can be attached to an object *instance* too; this is how "row
-level security" can be achieved in :mod:`pyramid` applications.  We
+level security" can be achieved in :app:`Pyramid` applications.  We
 actually only need *one* ACL for the entire system, however, because
 our security requirements are simple, so this feature is not
 demonstrated.
diff --git a/docs/tutorials/wiki/background.rst b/docs/tutorials/wiki/background.rst
index a7f9d1e82..e49407b70 100644
--- a/docs/tutorials/wiki/background.rst
+++ b/docs/tutorials/wiki/background.rst
@@ -2,8 +2,8 @@
 Background
 ==========
 
-This version of the :mod:`pyramid` wiki tutorial presents a
-:mod:`pyramid` application that uses technologies which will be
+This version of the :app:`Pyramid` wiki tutorial presents a
+:app:`Pyramid` application that uses technologies which will be
 familiar to someone with :term:`Zope` experience.  It uses
 :term:`ZODB` as a persistence mechanism and :term:`traversal` to map
 URLs to code.  It can also be followed by people without any prior
@@ -13,6 +13,6 @@ To code along with this tutorial, the developer will need a UNIX
 machine with development tools (Mac OS X with XCode, any Linux or BSD
 variant, etc) *or* he will need a Windows system of any kind.
 
-This tutorial targets :mod:`pyramid` version 1.0.
+This tutorial targets :app:`Pyramid` version 1.0.
 
 Have fun!
diff --git a/docs/tutorials/wiki/basiclayout.rst b/docs/tutorials/wiki/basiclayout.rst
index d129ff7ec..85cfc825b 100644
--- a/docs/tutorials/wiki/basiclayout.rst
+++ b/docs/tutorials/wiki/basiclayout.rst
@@ -4,7 +4,7 @@ Basic Layout
 
 The starter files generated by the ``pyramid_zodb`` template are basic,
 but they provide a good orientation for the high-level patterns common
-to most :term:`traversal` -based :mod:`pyramid` (and :term:`ZODB`
+to most :term:`traversal` -based :app:`Pyramid` (and :term:`ZODB`
 based) projects.
 
 The source code for this tutorial stage can be browsed via
@@ -101,7 +101,7 @@ following:
 Content Models with ``models.py``
 ---------------------------------
 
-:mod:`pyramid` often uses the word :term:`model` when talking about
+:app:`Pyramid` often uses the word :term:`model` when talking about
 content resources arranged in the hierarchical *object graph*
 consulted by :term:`traversal`.  The ``models.py`` file is where the
 ``pyramid_zodb`` Paster template put the classes that implement our
@@ -124,7 +124,7 @@ Here is the source for ``models.py``:
 
 #. *Lines 6-12*.  ``appmaker`` is used to return the *application
    root* object.  It is called on *every request* to the
-   :mod:`pyramid` application.  It also performs bootstrapping by
+   :app:`Pyramid` application.  It also performs bootstrapping by
    *creating* an application root (inside the ZODB root object) if one
    does not already exist.
  
diff --git a/docs/tutorials/wiki/definingmodels.rst b/docs/tutorials/wiki/definingmodels.rst
index 3fa72dd87..097485047 100644
--- a/docs/tutorials/wiki/definingmodels.rst
+++ b/docs/tutorials/wiki/definingmodels.rst
@@ -57,7 +57,7 @@ Our ``Wiki`` class should also have a ``__name__`` attribute set to
 ``None`` at class scope, and should have a ``__parent__`` attribute
 set to ``None`` at class scope as well.  If a model has a
 ``__parent__`` attribute of ``None`` in a traversal-based
-:mod:`pyramid` application, it means that it's the :term:`root`
+:app:`Pyramid` application, it means that it's the :term:`root`
 model.  The ``__name__`` of the root model is also always ``None``.
 
 Then we'll add a ``Page`` class.  This class should inherit from the
diff --git a/docs/tutorials/wiki/definingviews.rst b/docs/tutorials/wiki/definingviews.rst
index 797eee0d9..bbda3d45c 100644
--- a/docs/tutorials/wiki/definingviews.rst
+++ b/docs/tutorials/wiki/definingviews.rst
@@ -2,16 +2,16 @@
 Defining Views
 ==============
 
-A :term:`view callable` in a traversal-based :mod:`pyramid`
+A :term:`view callable` in a traversal-based :app:`Pyramid`
 application is typically a simple Python function that accepts two
 parameters: :term:`context`, and :term:`request`.  A view callable is
 assumed to return a :term:`response` object.
 
-.. note:: A :mod:`pyramid` view can also be defined as callable
+.. note:: A :app:`Pyramid` view can also be defined as callable
    which accepts *one* arguments: a :term:`request`.  You'll see this
-   one-argument pattern used in other :mod:`pyramid` tutorials and
+   one-argument pattern used in other :app:`Pyramid` tutorials and
    applications.  Either calling convention will work in any
-   :mod:`pyramid` application; the calling conventions can be used
+   :app:`Pyramid` application; the calling conventions can be used
    interchangeably as necessary.  In :term:`traversal` based
    applications, such as this tutorial, the context is used frequently
    within the body of a view method, so it makes sense to use the
@@ -22,7 +22,7 @@ assumed to return a :term:`response` object.
    to avoid the visual "noise".
 
 We're going to define several :term:`view callable` functions then
-wire them into :mod:`pyramid` using some :term:`view
+wire them into :app:`Pyramid` using some :term:`view
 configuration` via :term:`ZCML`.
 
 The source code for this tutorial stage can be browsed via
@@ -102,7 +102,7 @@ Note the contrast between this view callable and the ``view_wiki``
 view callable.  In the ``view_wiki`` view callable, we return a
 :term:`response` object.  In the ``view_page`` view callable, we
 return a *dictionary*.  It is *always* fine to return a
-:term:`response` object from a :mod:`pyramid` view.  Returning a
+:term:`response` object from a :app:`Pyramid` view.  Returning a
 dictionary is allowed only when there is a :term:`renderer` associated
 with the view callable in the view configuration.
 
@@ -116,7 +116,7 @@ this view.  It also acts as a handler for the form that is generated
 when we want to add a page object.  The ``context`` of the
 ``add_page`` view is always a Wiki object (*not* a Page object).
 
-The request :term:`subpath` in :mod:`pyramid` is the sequence of
+The request :term:`subpath` in :app:`Pyramid` is the sequence of
 names that are found *after* the view name in the URL segments given
 in the ``PATH_INFO`` of the WSGI request as the result of
 :term:`traversal`.  If our add view is invoked via,
@@ -182,7 +182,7 @@ Adding Templates
 
 Most view callables we've added expected to be rendered via a
 :term:`template`.  Each template is a :term:`Chameleon` template.  The
-default templating system in :mod:`pyramid` is a variant of
+default templating system in :app:`Pyramid` is a variant of
 :term:`ZPT` provided by Chameleon.  These templates will live in the
 ``templates`` directory of our tutorial package.
 
diff --git a/docs/tutorials/wiki/distributing.rst b/docs/tutorials/wiki/distributing.rst
index 81ec61a63..ad717e72a 100644
--- a/docs/tutorials/wiki/distributing.rst
+++ b/docs/tutorials/wiki/distributing.rst
@@ -6,7 +6,7 @@ Once your application works properly, you can create a "tarball" from
 it by using the ``setup.py sdist`` command.  The following commands
 assume your current working directory is the ``tutorial`` package
 we've created and that the parent directory of the ``tutorial``
-package is a virtualenv representing a :mod:`pyramid` environment.
+package is a virtualenv representing a :app:`Pyramid` environment.
 
 On UNIX:
 
diff --git a/docs/tutorials/wiki/index.rst b/docs/tutorials/wiki/index.rst
index 1fdc4be95..68f724902 100644
--- a/docs/tutorials/wiki/index.rst
+++ b/docs/tutorials/wiki/index.rst
@@ -3,7 +3,7 @@
 ZODB + Traversal Wiki Tutorial (For Developers Familiar with Zope)
 ==================================================================
 
-This tutorial introduces a :term:`traversal` -based :mod:`pyramid`
+This tutorial introduces a :term:`traversal` -based :app:`Pyramid`
 application to a developer familiar with Python.  It will be most familiar to
 developers with previous :term:`Zope` experience.  When we're done with the
 tutorial, the developer will have created a basic Wiki application with
diff --git a/docs/tutorials/wiki/installation.rst b/docs/tutorials/wiki/installation.rst
index 3e1b7552c..cb05611b7 100644
--- a/docs/tutorials/wiki/installation.rst
+++ b/docs/tutorials/wiki/installation.rst
@@ -52,7 +52,7 @@ Preparation, UNIX
 #. (Optional) Consider using ``source bin/activate`` to make your
    shell environment wired to use the virtualenv.
 
-#. Use ``easy_install`` to get :mod:`pyramid` and its direct
+#. Use ``easy_install`` to get :app:`Pyramid` and its direct
    dependencies installed:
 
    .. code-block:: bash
@@ -104,7 +104,7 @@ Preparation, Windows
 #. (Optional) Consider using ``bin\activate.bat`` to make your shell
    environment wired to use the virtualenv.
 
-#. Use ``easy_install`` to get :mod:`pyramid` and its direct
+#. Use ``easy_install`` to get :app:`Pyramid` and its direct
    dependencies installed:
 
    .. code-block:: bat
@@ -124,7 +124,7 @@ Preparation, Windows
 Making a Project
 ================
 
-Your next step is to create a project.  :mod:`pyramid` supplies a
+Your next step is to create a project.  :app:`Pyramid` supplies a
 variety of templates to generate sample projects.  For this tutorial,
 we will use the :term:`ZODB` -oriented template named ``pyramid_zodb``.
 
@@ -255,8 +255,8 @@ assumptions:
 
 .. note::
 
-   :mod:`pyramid` supports any persistent storage mechanism (e.g. a SQL
-   database or filesystem files, etc).  :mod:`pyramid` also supports an
+   :app:`Pyramid` supports any persistent storage mechanism (e.g. a SQL
+   database or filesystem files, etc).  :app:`Pyramid` also supports an
    additional mechanism to map URLs to code (:term:`URL dispatch`).  However,
    for the purposes of this tutorial, we'll only be using traversal and ZODB.
 
diff --git a/docs/tutorials/wiki/viewdecorators.rst b/docs/tutorials/wiki/viewdecorators.rst
index 2d58890e4..c2f068d86 100644
--- a/docs/tutorials/wiki/viewdecorators.rst
+++ b/docs/tutorials/wiki/viewdecorators.rst
@@ -154,7 +154,7 @@ Adding a Scan Directive
 
 In order for our decorators to be recognized, we must add a bit of
 boilerplate to our ``configure.zcml`` file which tells
-:mod:`pyramid` to kick off a :term:`scan` at startup time.  Add the
+:app:`Pyramid` to kick off a :term:`scan` at startup time.  Add the
 following tag anywhere beneath the ``<include
 package="pyramid.includes">`` tag but before the ending
 ``</configure>`` tag within ``configure.zcml``: