convert narrative docs to Pyramid

1 files changed, 20 insertions, 20 deletions

diff --git a/docs/narr/models.rst b/docs/narr/models.rst
index c6f896119..f2b3182a5 100644
--- a/docs/narr/models.rst
+++ b/docs/narr/models.rst
@@ -3,20 +3,20 @@ Models
 
 A :term:`model` class is typically a simple Python class defined in a
 module.  References to these classes and instances of such classes are
-omnipresent in :mod:`repoze.bfg`:
+omnipresent in :mod:`pyramid`:
 
-- Model instances make up the graph that :mod:`repoze.bfg` is
+- Model instances make up the graph that :mod:`pyramid` is
   willing to walk over when :term:`traversal` is used.
 
 - The ``context`` and ``containment`` arguments to
-  :meth:`repoze.bfg.configuration.Configurator.add_view` often
+  :meth:`pyramid.configuration.Configurator.add_view` often
   reference a model class.
 
 - A :term:`root factory` returns a model instance.
 
 - A model instance is generated as a result of :term:`url dispatch`
   (see the ``factory`` argument to
-  :meth:`repoze.bfg.configuration.Configurator.add_route`).
+  :meth:`pyramid.configuration.Configurator.add_route`).
 
 - A model instance is exposed to :term:`view` code as the
   :term:`context` of a view.
@@ -31,16 +31,16 @@ mutating that data.
    different notion of the definition of a "model".  When using the API
    of common ORM packages, its conception of "model" is almost
    certainly not the same conception of "model" used by
-   :mod:`repoze.bfg`.  In particular, it can be unnatural to think of
-   :mod:`repoze.bfg` model objects as "models" if you develop your
+   :mod:`pyramid`.  In particular, it can be unnatural to think of
+   :mod:`pyramid` model objects as "models" if you develop your
    application using :term:`traversal` and a relational database.  When
    you develop such applications, the object graph *might* be composed
    completely of "model" objects (as defined by the ORM) but it also
-   might not be.  The things that :mod:`repoze.bfg` refers to as
+   might not be.  The things that :mod:`pyramid` refers to as
    "models" in such an application may instead just be stand-ins that
    perform a query and generate some wrapper *for* an ORM "model" or
    set of ORM models.  This naming overlap is slightly unfortunate.
-   However, many :mod:`repoze.bfg` applications (especially ones which
+   However, many :mod:`pyramid` applications (especially ones which
    use :term:`ZODB`) do indeed traverse a graph full of literal model
    nodes.  Each node in the graph is a separate persistent object that
    is stored within a database.  This was the use case considered when
@@ -200,10 +200,10 @@ Defining a Graph of Model Instances for Traversal
 -------------------------------------------------
 
 When :term:`traversal` is used (as opposed to a purely :term:`url
-dispatch` based application), :mod:`repoze.bfg` expects to be able to
+dispatch` based application), :mod:`pyramid` expects to be able to
 traverse a graph composed of model instances.  Traversal begins at a
 root model, and descends into the graph recursively via each found
-model's ``__getitem__`` method.  :mod:`repoze.bfg` imposes the
+model's ``__getitem__`` method.  :mod:`pyramid` imposes the
 following policy on model instance nodes in the graph:
 
 - Nodes which contain other nodes (aka "container" nodes) must supply
@@ -238,13 +238,13 @@ Location-Aware Model Instances
   :mod:`repoze.bfg.traversalwrapper` package (available via `SVN
   <http://svn.repoze.org/repoze.bfg.traversalwrapper>`_), then
   register its ``ModelGraphTraverser`` as the traversal policy, rather
-  than the default :mod:`repoze.bfg` traverser. The package contains
+  than the default :mod:`pyramid` traverser. The package contains
   instructions.
 
-  Once :mod:`repoze.bfg` is configured with this feature, you will no
+  Once :mod:`pyramid` is configured with this feature, you will no
   longer need to manage the ``__parent__`` and ``__name__`` attributes
   on graph objects "by hand".  Instead, as necessary, during traversal
-  :mod:`repoze.bfg` will wrap each object (even the root object) in a
+  :mod:`pyramid` will wrap each object (even the root object) in a
   ``LocationProxy`` which will dynamically assign a ``__name__`` and a
   ``__parent__`` to the traversed object (based on the last traversed
   object and the name supplied to ``__getitem__``).  The root object
@@ -255,7 +255,7 @@ Applications which use :term:`traversal` to locate the :term:`context`
 of a view must ensure that the model instances that make up the model
 graph are "location aware".
 
-In order for :mod:`repoze.bfg` location, security, URL-generation, and
+In order for :mod:`pyramid` location, security, URL-generation, and
 traversal functions (such as the functions exposed in
 :ref:`location_module`, :ref:`traversal_module`, and :ref:`url_module`
 as well as certain functions in :ref:`security_module` ) to work
@@ -289,9 +289,9 @@ and so on.
 
 .. warning:: If your root model object has a ``__name__`` argument
    that is not ``None`` or the empty string, URLs returned by the
-   :func:`repoze.bfg.url.model_url` function and paths generated by
-   the :func:`repoze.bfg.traversal.model_path` and
-   :func:`repoze.bfg.traversal.model_path_tuple` APIs will be
+   :func:`pyramid.url.model_url` function and paths generated by
+   the :func:`pyramid.traversal.model_path` and
+   :func:`pyramid.traversal.model_path_tuple` APIs will be
    generated improperly.  The value of ``__name__`` will be prepended
    to every path and URL generated (as opposed to a single leading
    slash or empty tuple element).
@@ -300,7 +300,7 @@ and so on.
    single: model API functions
    single: url generation (traversal)
 
-:mod:`repoze.bfg` API Functions That Act Against Models
+:mod:`pyramid` API Functions That Act Against Models
 -------------------------------------------------------
 
 A model instance is used as the :term:`context` argument provided to a
@@ -317,8 +317,8 @@ conveniently locate one object "inside" another.
 
 Some APIs in :ref:`security_module` accept a model object as a
 parameter.  For example, the
-:func:`repoze.bfg.security.has_permission` API accepts a "context" (a
+:func:`pyramid.security.has_permission` API accepts a "context" (a
 model object) as one of its arguments; the ACL is obtained from this
 model or one of its ancestors.  Other APIs in the
-:mod:`repoze.bfg.security` module also accept :term:`context` as an
+:mod:`pyramid.security` module also accept :term:`context` as an
 argument, and a context is always a model.