3 files changed, 30 insertions, 44 deletions
diff --git a/docs/narr/resources.rst b/docs/narr/resources.rst
index 575afd1fe..c87157472 100644
--- a/docs/narr/resources.rst
+++ b/docs/narr/resources.rst
@@ -114,40 +114,6 @@ following kinds of resources defined in any Python package:
 - Any other resource (or set of resources) addressed by code that uses
   the setuptools :term:`pkg_resources` API.
 
-Usually, overriding a resource in an existing application means
-performing the following steps:
-
-- Create a new Python package.  The easiest way to do this is to
-  create a new :app:`Pyramid` application using the "paster"
-  template mechanism.  See :ref:`creating_a_project` for more
-  information.
-
-- Install the new package into the same Python environment as the
-  original application (e.g. ``python setup.py develop`` or ``python
-  setup.py install``).
-
-- Change the ``configure.zcml`` in the new package to include one or
-  more ``resource`` ZCML directives (see :ref:`resource_directive`
-  below).  The new package's ``configure.zcml`` should then include
-  the original :app:`Pyramid` application's ``configure.zcml`` via
-  an include statement, e.g.  ``<include
-  package="theoriginalpackage"/>``.
-
-- Add override resources to the package as necessary.
-
-- Change the Paste ``.ini`` file that starts up the original
-  application.  Add a ``configure_zcml`` statement within the
-  application's section in the file which points at your *new*
-  package's ``configure.zcml`` file.  See :ref:`environment_chapter`
-  for more information about this setting.
-
-Note that overriding resources is not the only way to extend or modify
-the behavior of an existing :app:`Pyramid` application.  A "heavier
-hammer" way to do the same thing is explained in
-:ref:`extending_chapter`.  The heavier hammer way allows you to
-replace a :term:`view` wholesale rather than resources that might be
-used by a view.
-
 .. index::
    single: override_resource
 
diff --git a/docs/narr/webob.rst b/docs/narr/webob.rst
index 92de9d409..c4805df8d 100644
--- a/docs/narr/webob.rst
+++ b/docs/narr/webob.rst
@@ -124,19 +124,39 @@ URLs
 
 In addition to these attributes, there are several ways to get the URL
 of the request.  I'll show various values for an example URL
-``http://localhost/app/?id=10``, where the application is mounted at
+``http://localhost/app/blog?id=10``, where the application is mounted at
 ``http://localhost/app``.
 
 ``req.url``:
     The full request URL, with query string, e.g.,
-    ``http://localhost/app/?id=10``
+    ``http://localhost/app/blog?id=10``
+
+``req.host``:
+    The host information in the URL, e.g.,
+    ``localhost``
+
+``req.host_url``:
+    The URL with the host, e.g., ``http://localhost``
 
 ``req.application_url``:
     The URL of the application (just the SCRIPT_NAME portion of the
     path, not PATH_INFO).  E.g., ``http://localhost/app``
 
-``req.host_url``:
-    The URL with the host, e.g., ``http://localhost``
+``req.path_url``:
+    The URL of the application including the PATH_INFO. e.g.,
+    ``http://localhost/app/blog``
+
+``req.path``:
+    The URL including PATH_INFO without the host or scheme. e.g.,
+    ``/app/blog``
+
+``req.path_qs``:
+    The URL including PATH_INFO and the query string. e.g,
+    ``/app/blog?id=10``
+
+``req.query_string``:
+    The query string in the URL, e.g.,
+    ``id=10``
 
 ``req.relative_url(url, to_application=False)``:
     Gives a URL, relative to the current URL.  If ``to_application``
diff --git a/docs/tutorials/wiki2/basiclayout.rst b/docs/tutorials/wiki2/basiclayout.rst
index 3e17f76e3..565bd0e96 100644
--- a/docs/tutorials/wiki2/basiclayout.rst
+++ b/docs/tutorials/wiki2/basiclayout.rst
@@ -19,12 +19,12 @@ an ``__init__.py`` file.  Even if empty, this marks a directory as a Python
 package.  We use ``__init__.py`` both as a package marker and to contain
 configuration code.
 
-When you run the application using the ``paster`` command using the
-``development.ini`` generated config file, the application configuration
-points at an Setuptools *entry point* described as ``egg:tutorial#app``.  In
-our application, because the application's ``setup.py`` file says so, this
-entry point happens to be the ``app`` function within the file named
-``__init__.py``:
+The generated ``development.ini`` file is read by ``paster`` which looks for
+the application module in the ``use`` variable of the ``app:tutorial``
+section. The *entry point* is defined in the Setuptools configuration of this
+module, specifically in the ``setup.py`` file. For this tutorial, the *entry
+point* is defined as ``tutorial:main`` and points to the following ``main``
+function:
 
    .. literalinclude:: src/basiclayout/tutorial/__init__.py
       :linenos: