Merge branch 'master' of github.com:Pylons/pyramid

8 files changed, 73 insertions, 19 deletions

diff --git a/docs/narr/commandline.rst b/docs/narr/commandline.rst
index 4be436836..af53c1f78 100644
--- a/docs/narr/commandline.rst
+++ b/docs/narr/commandline.rst
@@ -654,8 +654,11 @@ use the following command:
 
 .. code-block:: python
 
-   import logging.config
-   logging.config.fileConfig('/path/to/my/development.ini')
+   import pyramid.paster
+   pyramid.paster.setup_logging('/path/to/my/development.ini')
+
+See :ref:`logging_chapter` for more information on logging within
+:app:`Pyramid`.
 
 .. index::
    single: console script
diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index a2143b3c5..332805152 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -289,6 +289,36 @@ keys added to the renderer globals dictionary by all
 :class:`pyramid.events.BeforeRender` subscribers and renderer globals
 factories must be unique.
 
+The dictionary returned from the view is accessible through the
+:attr:`rendering_val` attribute of a :class:`~pyramid.events.BeforeRender`
+event.
+
+Suppose you return ``{'mykey': 'somevalue', 'mykey2': 'somevalue2'}`` from
+your view callable, like so:
+
+.. code-block:: python
+   :linenos:
+
+   from pyramid.view import view_config
+
+   @view_config(renderer='some_renderer')
+   def myview(request):
+       return {'mykey': 'somevalue', 'mykey2': 'somevalue2'}
+
+:attr:`rendering_val` can be used to access these values from the
+:class:`~pyramid.events.BeforeRender` object:
+
+.. code-block:: python
+   :linenos:
+
+   from pyramid.events import subscriber
+   from pyramid.events import BeforeRender
+
+   @subscriber(BeforeRender)
+   def read_return(event):
+       # {'mykey': 'somevalue'} is returned from the view
+       print(event.rendering_val['mykey'])
+
 See the API documentation for the :class:`~pyramid.events.BeforeRender` event
 interface at :class:`pyramid.interfaces.IBeforeRender`.
 
diff --git a/docs/narr/logging.rst b/docs/narr/logging.rst
index 044655c1f..f4c38abb6 100644
--- a/docs/narr/logging.rst
+++ b/docs/narr/logging.rst
@@ -14,7 +14,7 @@ how to send log messages to loggers that you've configured.
    which help configure logging.  All of the scaffolds which ship along with
    :app:`Pyramid` do this.  If you're not using a scaffold, or if you've used
    a third-party scaffold which does not create these files, the
-   configuration information in this chapter will not be applicable.
+   configuration information in this chapter may not be applicable.
 
 .. _logging_config:
 
@@ -36,10 +36,11 @@ application-related and logging-related sections in the configuration file
 can coexist peacefully, and the logging-related sections in the file are used
 from when you run ``pserve``.
 
-The ``pserve`` command calls the `logging.fileConfig function
+The ``pserve`` command calls the :func:`pyramid.paster.setup_logging`
+function, a thin wrapper around the `logging.fileConfig
 <http://docs.python.org/lib/logging-config-api.html>`_ using the specified
 ini file if it contains a ``[loggers]`` section (all of the
-scaffold-generated ``.ini`` files do). ``logging.fileConfig`` reads the
+scaffold-generated ``.ini`` files do). ``setup_logging`` reads the
 logging configuration from the ini file upon which ``pserve`` was
 invoked.
 
diff --git a/docs/narr/sessions.rst b/docs/narr/sessions.rst
index 6ff9e3dea..1aa1b6341 100644
--- a/docs/narr/sessions.rst
+++ b/docs/narr/sessions.rst
@@ -151,13 +151,12 @@ Using Alternate Session Factories
 ---------------------------------
 
 At the time of this writing, exactly one alternate session factory
-implementation exists, named ``pyramid_beaker``. This is a session
-factory that uses the `Beaker <http://beaker.groovie.org/>`_ library
-as a backend.  Beaker has support for file-based sessions, database
-based sessions, and encrypted cookie-based sessions.  See
-`http://github.com/Pylons/pyramid_beaker
-<http://github.com/Pylons/pyramid_beaker>`_ for more information about
-``pyramid_beaker``.
+implementation exists, named ``pyramid_beaker``. This is a session factory
+that uses the `Beaker <http://beaker.groovie.org/>`_ library as a backend.
+Beaker has support for file-based sessions, database based sessions, and
+encrypted cookie-based sessions.  See `the pyramid_beaker documentation
+<http://docs.pylonsproject.org/projects/pyramid_beaker/en/latest/>`_ for more
+information about ``pyramid_beaker``.
 
 .. index::
    single: session factory (custom)
diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index 9db0b1c4d..860010a1a 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -714,6 +714,22 @@ This template doesn't use any advanced features of Mako, only the
 :term:`renderer globals`.  See the `the Mako documentation
 <http://www.makotemplates.org/>`_ to use more advanced features.
 
+Using def inside Mako Templates
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To use a def inside a Mako template, given a :term:`Mako` template file named 
+``foo.mak`` and a def named ``bar``, you can configure the template as a 
+:term:`renderer` like so:
+
+.. code-block:: python
+   :linenos:
+
+   from pyramid.view import view_config
+
+   @view_config(renderer='foo#bar.mak')
+   def my_view(request):
+       return {'project':'my project'}
+
 .. index::
    single: automatic reloading of templates
    single: template automatic reload
diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index acbccbdfd..ecf3d026a 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -954,7 +954,7 @@ will be prepended with the first:
    from pyramid.config import Configurator
 
    def timing_include(config):
-       config.add_route('show_times', /times')
+       config.add_route('show_times', '/times')
 
    def users_include(config):
        config.add_route('show_users', '/show')
@@ -966,7 +966,7 @@ will be prepended with the first:
 
 In the above configuration, the ``show_users`` route will still have an
 effective route pattern of ``/users/show``.  The ``show_times`` route
-however, will have an effective pattern of ``/users/timing/show_times``.
+however, will have an effective pattern of ``/users/timing/times``.
 
 Route prefixes have no impact on the requirement that the set of route
 *names* in any given Pyramid configuration must be entirely unique.  If you
@@ -981,7 +981,7 @@ that may be added in the future.  For example:
    from pyramid.config import Configurator
 
    def timing_include(config):
-       config.add_route('timing.show_times', /times')
+       config.add_route('timing.show_times', '/times')
 
    def users_include(config):
        config.add_route('users.show_users', '/show')
diff --git a/docs/tutorials/modwsgi/index.rst b/docs/tutorials/modwsgi/index.rst
index e070f8eda..d11167344 100644
--- a/docs/tutorials/modwsgi/index.rst
+++ b/docs/tutorials/modwsgi/index.rst
@@ -73,9 +73,10 @@ commands and files.
 
     .. code-block:: python
 
-       from pyramid.paster import get_app
-       application = get_app(
-         '/Users/chrism/modwsgi/env/myapp/production.ini', 'main')
+       from pyramid.paster import get_app, setup_logging
+       ini_path = '/Users/chrism/modwsgi/env/myapp/production.ini'
+       setup_logging(ini_path)
+       application = get_app(ini_path, 'main')
 
     The first argument to ``get_app`` is the project configuration file
     name.  It's best to use the ``production.ini`` file provided by your
@@ -85,6 +86,10 @@ commands and files.
     ``application`` is important: mod_wsgi requires finding such an
     assignment when it opens the file.
 
+    The call to ``setup_logging`` initializes the standard library's
+    `logging` module to allow logging within your application.
+    See :ref:`logging_config`.
+
 #.  Make the ``pyramid.wsgi`` script executable.
 
     .. code-block:: text
diff --git a/docs/tutorials/wiki2/design.rst b/docs/tutorials/wiki2/design.rst
index 2e6fc0e77..deaf32ef6 100644
--- a/docs/tutorials/wiki2/design.rst
+++ b/docs/tutorials/wiki2/design.rst
@@ -20,7 +20,7 @@ Models
 We'll be using a SQLite database to hold our wiki data, and we'll be using
 :term:`SQLAlchemy` to access the data in this database.
 
-Within the database, we define a single table named `tables`, whose elements
+Within the database, we define a single table named `pages`, whose elements
 will store the wiki pages.  There are two columns: `name` and `data`.
 
 URLs like ``/PageName`` will try to find an element in