summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorCasey Duncan <casey.duncan@gmail.com>2011-01-01 21:15:43 -0700
committerCasey Duncan <casey.duncan@gmail.com>2011-01-01 21:15:43 -0700
commit419b2260ad97cbc9816b2fe075ef3d9acdb79581 (patch)
tree3c8a6fc70bafb026c02324d8feb6d39e71f36d84 /docs
parentad838b5d01980b156f763bea4cd655bf50a61783 (diff)
downloadpyramid-419b2260ad97cbc9816b2fe075ef3d9acdb79581.tar.gz
pyramid-419b2260ad97cbc9816b2fe075ef3d9acdb79581.tar.bz2
pyramid-419b2260ad97cbc9816b2fe075ef3d9acdb79581.zip
rework paragraphs discussifng root factot config
Diffstat (limited to 'docs')
-rw-r--r--docs/narr/traversal.rst31
1 files changed, 15 insertions, 16 deletions
diff --git a/docs/narr/traversal.rst b/docs/narr/traversal.rst
index c6da5e5ef..0b0bb1d3e 100644
--- a/docs/narr/traversal.rst
+++ b/docs/narr/traversal.rst
@@ -126,24 +126,23 @@ passing it to an instance of a :term:`Configurator` named ``config``:
config = Configurator(root_factory=Root)
-Using the ``root_factory`` argument to a :class:`pyramid.config.Configurator`
-constructor tells your :app:`Pyramid` application to call this root factory
-to generate a root resource whenever a request enters the application. This
-root factory is also known as the global root factory. A root factory can
-alternately be passed to the ``Configurator`` as a :term:`dotted Python name`
-which can refer to a root factory defined in a different module.
-
-A root factory is passed a :term:`request` object and it is expected to
-return an object which represents the root of the resource tree. All
-:term:`traversal` will begin at this root resource. Usually a root factory
-for a traversal-based application will be more complicated than the above
-``Root`` class; in particular it may be associated with a database connection
-or another persistence mechanism.
+The ``root_factory`` argument to the
+:class:`pyramid.config.Configurator` constructor registers this root
+factory to be called to generate a root resource whenever a request
+enters the application. The root factory registered this way is also
+known as the global root factory. A root factory can alternately be
+passed to the ``Configurator`` as a :term:`dotted Python name` which can
+refer to a root factory defined in a different module.
If no :term:`root factory` is passed to the :app:`Pyramid`
-:term:`Configurator` constructor, or the ``root_factory`` is specified as the
-value ``None``, a *default* root factory is used. The default root factory
-always returns a resource that has no child resources; it is effectively empty.
+:term:`Configurator` constructor, or if the ``root_factory`` value
+specified is ``None``, a *default* root factory is used. The default
+root factory always returns a resource that has no child resources; it
+is effectively empty.
+
+Usually a root factory for a traversal-based application will be more
+complicated than the above ``Root`` class; in particular it may be
+associated with a database connection or another persistence mechanism.
.. sidebar:: Emulating the Default Root Factory