Docs: project.rst: Utilize sidebars for out-of-band text.

1 files changed, 34 insertions, 24 deletions

diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 8788977c7..622f40d69 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -210,6 +210,12 @@ Python interpreter from the :term:`virtualenv` you created during
 :ref:`installing_chapter` (the ``python`` command that lives in the ``bin``
 directory of your virtualenv).
 
+.. sidebar:: Verbose Testing
+
+   The ``-q`` option is passed to the ``setup.py test`` command to limit the
+   output to a stream of dots.  If you don't pass ``-q``, you'll see more
+   verbose test result output (which normally isn't very useful).
+
 On UNIX:
 
 .. code-block:: text
@@ -243,12 +249,6 @@ Here's sample output from a test run on UNIX:
 
    OK
 
-.. note::
-
-   The ``-q`` option is passed to the ``setup.py test`` command to limit the
-   output to a stream of dots.  If you don't pass ``-q``, you'll see more
-   verbose test result output (which normally isn't very useful).
-
 The tests themselves are found in the ``tests.py`` module in your ``pcreate``
 generated project.  Within a project generated by the ``starter`` scaffold, a
 single sample test exists.
@@ -684,6 +684,14 @@ use a different version control system, you may need to install a setuptools
 add-on such as ``setuptools-git`` or ``setuptools-hg`` for this behavior to
 work properly.
 
+.. sidebar:: Python's ``setup.py``
+
+  ``setup.py`` is the de facto standard which Python developers use to
+  distribute their reusable code.  You can read more about ``setup.py`` files
+  and their usage in the `Setuptools documentation
+  <http://peak.telecommunity.com/DevCenter/setuptools>`_ and `The
+  Hitchhiker's Guide to Packaging <http://guide.python-distribute.org/>`_.
+
 .. index::
    single: setup.py
 
@@ -694,14 +702,6 @@ The ``setup.py`` file is a :term:`setuptools` setup file.  It is meant to be
 run directly from the command line to perform a variety of functions, such as
 testing, packaging, and distributing your application.
 
-.. note::
-
-  ``setup.py`` is the de facto standard which Python developers use to
-  distribute their reusable code.  You can read more about ``setup.py`` files
-  and their usage in the `Setuptools documentation
-  <http://peak.telecommunity.com/DevCenter/setuptools>`_ and `The
-  Hitchhiker's Guide to Packaging <http://guide.python-distribute.org/>`_.
-
 Our generated ``setup.py`` looks like this:
 
 .. literalinclude:: MyProject/setup.py
@@ -857,6 +857,26 @@ and which returns a :term:`response`.
    :language: python
    :linenos:
 
+.. sidebar:: Fully Interactive Development
+
+   Because our ``development.ini`` has a ``pyramid.reload_templates =
+   true`` directive indicating that templates should be reloaded when
+   they change, you won't need to restart the application server to
+   see changes you make to templates.  During development, this is
+   handy.  If this directive had been ``false`` (or if the directive
+   did not exist), you would need to restart the application server
+   for each template change.  For production applications, you should
+   set your project's ``pyramid.reload_templates`` to ``false`` to
+   increase template rendering speed.
+
+   Pyramid can also dynamically reload changed Python files.  For more
+   on this see :ref:`reloading_code` above.
+
+   The :ref:`debug_toolbar` provides interactive access to your
+   application's internals and, should an exception occur, allows
+   interactive access to traceback execution stack frames from the
+   Python interpreter.
+
 Lines 4-6 define and register a :term:`view callable` named ``my_view``.  The
 function named ``my_view`` is decorated with a ``view_config`` decorator
 (which is processed by the ``config.scan()`` line in our ``__init__.py``).
@@ -888,16 +908,6 @@ returns the HTML in a :term:`response`.
 See :ref:`views_which_use_a_renderer` for more information about how views,
 renderers, and templates relate and cooperate.
 
-.. note:: Because our ``development.ini`` has a ``pyramid.reload_templates =
-   true`` directive indicating that templates should be reloaded when
-   they change, you won't need to restart the application server to
-   see changes you make to templates.  During development, this is
-   handy.  If this directive had been ``false`` (or if the directive
-   did not exist), you would need to restart the application server
-   for each template change.  For production applications, you should
-   set your project's ``pyramid.reload_templates`` to ``false`` to increase
-   the speed at which templates may be rendered.
-
 .. index::
    single: static directory