Merge https://github.com/Pylons/pyramid

20 files changed, 72 insertions, 286 deletions

diff --git a/docs/api/interfaces.rst b/docs/api/interfaces.rst
index b3c14e5f7..3ce926230 100644
--- a/docs/api/interfaces.rst
+++ b/docs/api/interfaces.rst
@@ -35,3 +35,7 @@ Other Interfaces
 
   .. autointerface:: ITemplateRenderer
 
+  .. autointerface:: IViewMapperFactory
+
+  .. autointerface:: IViewMapper
+
diff --git a/docs/conf.py b/docs/conf.py
index 7bcdf3a07..8c238cecd 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -76,7 +76,7 @@ copyright = '%s, Agendaless Consulting' % datetime.datetime.now().year
 # other places throughout the built documents.
 #
 # The short X.Y version.
-version = '1.0a7'
+version = '1.0a8'
 # The full version, including alpha/beta/rc tags.
 release = version
 
diff --git a/docs/designdefense.rst b/docs/designdefense.rst
index 53b95b9d0..1d6941283 100644
--- a/docs/designdefense.rst
+++ b/docs/designdefense.rst
@@ -1604,10 +1604,10 @@ If you can understand this hello world program, you can use Pyramid:
        app = config.make_wsgi_app()
        serve(app)
 
-Pyramid has ~ 650 of documentation (printed), covering topics from the very
-basic to the most advanced.  *Nothing* is left undocumented, quite literally.
-It also has an *awesome*, very helpful community.  Visit the #repoze and/or
-#pylons IRC channels on freenode.net and see.
+Pyramid has ~ 650 pages of documentation (printed), covering topics from the
+very basic to the most advanced.  *Nothing* is left undocumented, quite
+literally.  It also has an *awesome*, very helpful community.  Visit the
+#repoze and/or #pylons IRC channels on freenode.net and see.
 
 Hate Zope
 +++++++++
diff --git a/docs/index.rst b/docs/index.rst
index 3281de13c..ecd401ddb 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -79,7 +79,6 @@ applications to various platforms.
    tutorials/wiki/index.rst
    tutorials/wiki2/index.rst
    tutorials/bfg/index.rst
-   tutorials/cmf/index.rst
    tutorials/gae/index.rst
    tutorials/modwsgi/index.rst
    tutorials/zeo/index.rst
diff --git a/docs/latexindex.rst b/docs/latexindex.rst
index 25e6791d0..058835937 100644
--- a/docs/latexindex.rst
+++ b/docs/latexindex.rst
@@ -125,7 +125,9 @@ ZCML Directive Reference
    zcml/configure
    zcml/default_permission
    zcml/forbidden
+   zcml/handler
    zcml/include
+   zcml/localenegotiator
    zcml/notfound
    zcml/remoteuserauthenticationpolicy
    zcml/renderer
@@ -134,6 +136,7 @@ ZCML Directive Reference
    zcml/scan
    zcml/static
    zcml/subscriber
+   zcml/translationdir
    zcml/utility
    zcml/view
 
diff --git a/docs/narr/assets.rst b/docs/narr/assets.rst
index f147426ce..f73ff231a 100644
--- a/docs/narr/assets.rst
+++ b/docs/narr/assets.rst
@@ -98,7 +98,7 @@ directory on a filesystem to an application user's browser.  Use the
 mechanism makes a directory of static files available at a name relative to
 the application root URL, e.g. ``/static`` or as an external URL.
 
-.. note:: `~pyramid.config.Configurator.add_static_view` cannot serve a
+.. note:: :meth:`~pyramid.config.Configurator.add_static_view` cannot serve a
    single file, nor can it serve a directory of static files directly
    relative to the root URL of a :app:`Pyramid` application.  For these
    features, see :ref:`advanced_static`.
@@ -282,7 +282,7 @@ create such a circumstance, we suggest using the
 in the application ``.ini`` file named ``media_location``.  Then set the
 value of ``media_location`` to either a prefix or a URL depending on whether
 the application is being run in development or in production (use a different
-`.ini`` file for production than you do for development).  This is just a
+``.ini`` file for production than you do for development).  This is just a
 suggestion for a pattern; any setting name other than ``media_location``
 could be used.
 
diff --git a/docs/narr/csrf.rst b/docs/narr/csrf.rst
index 7586b0ed7..2f545fb4f 100644
--- a/docs/narr/csrf.rst
+++ b/docs/narr/csrf.rst
@@ -9,7 +9,7 @@ phenomenon whereby a user with an identity on your website might click on a
 URL or button on another website which unwittingly redirects the user to your
 application to perform some command that requires elevated privileges.
 
-You can avoid most of these attacks by making sure that a the correct *CSRF
+You can avoid most of these attacks by making sure that the correct *CSRF
 token* has been set in an :app:`Pyramid` session object before performing any
 actions in code which requires elevated privileges and is invoked via a form
 post.  To use CSRF token support, you must enable a :term:`session factory`
diff --git a/docs/narr/flash.rst b/docs/narr/flash.rst
index d41c2cdaf..037bfc416 100644
--- a/docs/narr/flash.rst
+++ b/docs/narr/flash.rst
@@ -38,7 +38,7 @@ provide is not modified in any way.
 
 The ``queue`` argument allows you to choose a queue to which to append the
 message you provide.  This can be used to push different kinds of messages
-into flash storage for later display in different places on a page.  You cam
+into flash storage for later display in different places on a page.  You can
 pass any name for your queue, but it must be a string. The default value is
 the empty string, which chooses the default queue. Each queue is independent,
 and can be popped by ``pop_flash`` or examined via ``peek_flash`` separately.
@@ -49,20 +49,22 @@ default flash message queue.
 
    request.session.flash(msg, 'myappsqueue')
 
-The ``allow_duplicate`` argument, which defaults to ``True``.  If this is
+The ``allow_duplicate`` argument defaults to ``True``.  If this is
 ``False``, if you attempt to add a message to a queue which is already
 present in the queue, it will not be added.
 
 Using the ``session.pop_flash`` Method
 --------------------------------------
 
-Once one or more messages has been added to a flash queue by the
+Once one or more messages have been added to a flash queue by the
 ``session.flash`` API, the ``session.pop_flash`` API can be used to pop that
 queue and return it for use.
 
 To pop a particular queue of messages from the flash object, use the session
 object's ``pop_flash`` method.
 
+.. method:: pop_flash(queue='')
+
 .. code-block:: python
    :linenos:
 
@@ -85,14 +87,16 @@ been popped.
 
 The object returned from ``pop_flash`` is a list.
 
-Using the ``session.pop_flash`` Method
---------------------------------------
+Using the ``session.peek_flash`` Method
+---------------------------------------
 
 Once one or more messages has been added to a flash queue by the
 ``session.flash`` API, the ``session.peek_flash`` API can be used to "peek"
 at that queue.  Unlike ``session.pop_flash``, the queue is not popped from
 flash storage.
 
+.. method:: peek_flash(queue='')
+
 .. code-block:: python
    :linenos:
 
diff --git a/docs/narr/introduction.rst b/docs/narr/introduction.rst
index 3ade3726c..c61ef21d4 100644
--- a/docs/narr/introduction.rst
+++ b/docs/narr/introduction.rst
@@ -63,7 +63,7 @@ A Sense of Fun
 
 Minimalism
   :app:`Pyramid` provides only the very basics: *URL to code
-  mapping*, *templating*, *security*, and *resources*.  There is not
+  mapping*, *templating*, *security*, and *assets*.  There is not
   much more to the framework than these pieces: you are expected to
   provide the rest.
 
diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 36f2d6975..55a2711f3 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -256,6 +256,8 @@ create`` -generated project.  Within a project generated by the
    single: IPython
    single: paster pshell
 
+.. _interactive_shell:
+
 The Interactive Shell
 ---------------------
 
diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index 3804fcf42..76e9562fa 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -22,6 +22,7 @@ response.  For example:
    from pyramid.response import Response
    from pyramid.view import view_config
 
+   @view_config(renderer='json')
    def hello_world(request):
        return {'content':'Hello!'}
 
diff --git a/docs/narr/resources.rst b/docs/narr/resources.rst
index 3b9efe108..b892cf3cd 100644
--- a/docs/narr/resources.rst
+++ b/docs/narr/resources.rst
@@ -533,7 +533,7 @@ declares that the blog entry implements an :term:`interface`.
        implements(IBlogEntry)
        def __init__(self, title, body, author):
            self.title = title
-           self.body =  body
+           self.body = body
            self.author = author
            self.created = datetime.datetime.now()
 
@@ -568,7 +568,7 @@ To do so, use the :func:`zope.interface.directlyProvides` function:
    class BlogEntry(object):
        def __init__(self, title, body, author):
            self.title = title
-           self.body =  body
+           self.body = body
            self.author = author
            self.created = datetime.datetime.now()
 
@@ -596,7 +596,7 @@ the :func:`zope.interface.alsoProvides` function:
    class BlogEntry(object):
        def __init__(self, title, body, author):
            self.title = title
-           self.body =  body
+           self.body = body
            self.author = author
            self.created = datetime.datetime.now()
 
diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index 76eca454d..0d28a0e96 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -533,12 +533,12 @@ neither predicates nor view configuration information.
   callables.  Use custom predicates when no set of predefined predicates does
   what you need.  Custom predicates can be combined with predefined
   predicates as necessary.  Each custom predicate callable should accept two
-  arguments: ``context`` and ``request`` and should return either ``True`` or
+  arguments: ``info`` and ``request`` and should return either ``True`` or
   ``False`` after doing arbitrary evaluation of the context resource and/or
   the request.  If all callables return ``True``, the associated route will
   be considered viable for a given request.  If any custom predicate returns
-  ``False``, route matching continues.  Note that the value ``context`` will
-  always be ``None`` when passed to a custom route predicate.
+  ``False``, route matching continues.  See :ref:`custom_route_predicates`
+  for more information.
 
 **View-Related Arguments**
 
@@ -1231,6 +1231,44 @@ which you started the application from.  For example:
 See :ref:`environment_chapter` for more information about how, and where to
 set these values.
 
+.. index::
+   pair: routes; printing
+   single: paster proutes
+
+Displaying All Application Routes
+---------------------------------
+
+You can use the ``paster proutes`` command in a terminal window to print a
+summary of routes related to your application.  Much like the ``paster
+pshell`` command (see :ref:`interactive shell`), the ``paster proutes``
+command accepts two arguments.  The first argument to ``proutes`` is the path
+to your application's ``.ini`` file.  The second is the ``app`` section name
+inside the ``.ini`` file which points to your application.
+
+For example:
+
+.. code-block:: text
+   :linenos:
+
+   [chrism@thinko MyProject]$ ../bin/paster proutes development.ini MyProject
+   Name            Pattern                        View
+   ----            -------                        ----                     
+   home            /                              <function my_view>
+   home2           /                              <function my_view>
+   another         /another                       None                     
+   static/         static/*subpath                <static_view object>
+   catchall        /*subpath                      <function static_view>
+
+``paster proutes`` generates a table.  The table has three columns: a Name
+name column, a Pattern column, and a View column.  The items listed in the
+Name column are route names, the items listen in the Pattern column are route
+patterns, and the items listed in the View column are representations of the
+view callable that will be invoked when a request matches the associated
+route pattern.  The view column may show ``None`` if no associated view
+callable could be found.  If no routes are configured within your
+application, nothing will be printed to the console when ``paster proutes``
+is executed.
+
 References
 ----------
 
diff --git a/docs/tutorials/cmf/actions.rst b/docs/tutorials/cmf/actions.rst
deleted file mode 100644
index a6e33fa59..000000000
--- a/docs/tutorials/cmf/actions.rst
+++ /dev/null
@@ -1,28 +0,0 @@
-.. _actions_chapter:
-
-=======
-Actions
-=======
-
-In CMF, the "actions tool" along with "action providers" create an extensible
-mechanism to show links in the CMF management UI that invoke a particular
-behavior or which show a particular template.
-
-:app:`Pyramid` itself has no such concept, and no package provides a direct
-replacement.  Actions are such a generic concept that it's simple to
-reimplement action-like navigation in a different way within any given
-application.  For example, a module-scope global dictionary which has keys
-that are action names, and values which are tuples of (permission, link).
-Take that concept and expand on it, and you'll have some passable actions
-tool replacement within a single application.
-
-The `pyramid_viewgroup <https://github.com/Pylons/pyramid_viewgroup/>`_
-package provides some functionality for creating "view groups".  Each view in
-a viewgroup can provide some snippet of HTML (e.g. a single "tab"), and
-individual views (tabs) within the group which cannot be displayed to the
-user due to the user's lack of permissions will be omitted from the rendered
-output.
-
-The :term:`repoze.lemonade` package provides "list item" support that
-may be used to construct action lists.
-
diff --git a/docs/tutorials/cmf/catalog.rst b/docs/tutorials/cmf/catalog.rst
deleted file mode 100644
index d5e9534ae..000000000
--- a/docs/tutorials/cmf/catalog.rst
+++ /dev/null
@@ -1,73 +0,0 @@
-.. _catalog_chapter:
-
-=======
-Catalog
-=======
-
-The main feature of the CMF catalog is that it filters search results
-from the Zope 2 "catalog" based on the requesting user's ability to
-view a particular cataloged object.
-
-:app:`Pyramid` itself has no cataloging facility, but an addon
-package named :term:`repoze.catalog` offers similar functionality.
-
-Creating an Allowed Index
--------------------------
-
-In CMF, a catalog index named ``getAllowedRolesAndUsers`` along with
-application indexing code allows for filtered search results.  It's
-reasonably easy to reproduce this pattern using some custom code.
-
-Creating The ``allowed`` Index
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Here's some code which creates an ``allowed`` index for use in a
-``repoze.catalog`` catalog::
-
-    from pyramid.security import principals_allowed_by_permission
-    from repoze.catalog.indexes.keyword import CatalogKeywordIndex
-    from repoze.catalog.catalog import Catalog
-
-    class Allowed:
-        def __init__(self, permission):
-            self.permission = permission
-
-        def __call__(self, context, default):
-            principals = principals_allowed_by_permission(context, 
-                                                          self.permission)
-            return principals
-
-    def make_allowed_index(permission='View'):
-        index = CatalogKeywordIndex(Allowed(permission))
-        return index
-
-    index = make_allowed_index()
-    catalog = Catalog()
-    catalog['allowed'] = index
-
-When you index an item, the allowed index will be populated with all
-the principal ids which have the 'View' permission.
-
-Using the ``allowed`` Index
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Here's how you might use the ``allowed`` index within a query::
-
-  from pyramid.security import effective_principals
-  principals = effective_principals(request)
-  catalog.searchResults(allowed={'operator':'or', 'query':principals})
-
-The above query will return all document ids that the current user has
-the 'View' permission against.  Add other indexes to the query to get
-a useful result.
-
-See the `repoze.catalog package
-<http://svn.repoze.org/repoze.catalog/trunk>`_ for more information.
-
-
-
-
-
-
-
-
diff --git a/docs/tutorials/cmf/content.rst b/docs/tutorials/cmf/content.rst
deleted file mode 100644
index 85e5b5fbc..000000000
--- a/docs/tutorials/cmf/content.rst
+++ /dev/null
@@ -1,67 +0,0 @@
-.. _content_types_chapter:
-
-=============
-Content Types
-=============
-
-In CMF, a content type is defined as a bag of settings (the type
-information, controlled within the "types tool"), as well as factory
-code which generates an instance of that content.  It is possible to
-construct and enumerate content types using APIs defined on the types
-tool.
-
-:app:`Pyramid` itself has no such concept, but an addon package named
-:term:`repoze.lemonade` has a barebones replacement.
-
-Factory Type Information
-------------------------
-
-A factory type information object in CMF allows you to associate a
-title, a description, an internationalization domain, an icon, an
-initial view name, a factory, and a number of security settings with a
-type name.  Each type information object knows how to manufacture
-content objects that match its type.
-
-:app:`Pyramid` certainly enforces none of these concepts in any
-particular way, but :term:`repoze.lemonade` does.
-
-``repoze.lemonade`` Content
-+++++++++++++++++++++++++++
-
-:term:`repoze.lemonade` provides a reasonably handy directive and set
-of helper functions which allow you to:
-
-#. Associate a interface with a factory function, making it into a
-   "content type".
-
-#. Enumerate all interfaces associated with factory functions.
-
-.. note:: Using this pattern is often plain silly, as it's usually
-          just as easy to actually import a class implementation and
-          create an instance directly using its constructor.  But it
-          can be useful in cases where you want to address some set of
-          constructors uniformly without doing direct imports in the
-          code which performs the construction, or if you need to make
-          content construction uniform across a diverse set of model
-          types, or if you need to enumerate some set of information
-          about "content" types.  It's left as an exercise to the
-          reader to determine under which circumstances using this
-          pattern is an appropriate thing to do.  Hint: not very
-          often, unless you're doing the indirection solely to aid
-          content-agnostic unit tests or if you need to get an
-          enumerated subset of content type information to aid in UI
-          generation.  That said, this *is* a tutorial about how to
-          get CMF-like features in :app:`Pyramid`, so we'll assume
-          the pattern is useful to readers.
-
-See the `repoze.lemonade package
-<http://svn.repoze.org/repoze.lemonade/trunk>`_ for more information,
-particularly its documentation for "content".
-
-
-
-
-
-
-
-
diff --git a/docs/tutorials/cmf/index.rst b/docs/tutorials/cmf/index.rst
deleted file mode 100644
index 26aa336a9..000000000
--- a/docs/tutorials/cmf/index.rst
+++ /dev/null
@@ -1,38 +0,0 @@
-Converting an Existing Zope/CMF Application to :app:`Pyramid`
-================================================================
-
-The Zope `Content Management Framework
-<http://www.zope.org/Products/CMF/>`_ (aka CMF) is a layer on top of
-:term:`Zope` 2 that provides facilities for creating content-driven
-websites.  It's reasonably easy to convert a modern Zope/CMF
-application to :app:`Pyramid`.
-
-The main difference between CMF and :app:`Pyramid` is that :app:`Pyramid`
-does not advertise itself as a system into which you can plug arbitrary
-"packages" that extend a system-supplied management user interface.  You
-*could* build a CMF-like layer on top of :app:`Pyramid` but none currently
-exists.  For those sorts of high-extensibility, highly-regularized-UI
-systems, CMF is still the better choice.
-
-:app:`Pyramid` (and other more lightweight systems) is often a
-better choice when you're building the a user interface from scratch,
-which often happens when the paradigms of some CMF-provided user
-interface don't match the requirements of an application very closely.
-Even so, a good number of developers tend to use CMF even when they do
-start an application for which they need to build a UI from scratch,
-because CMF happens to provide other helpful services, such as types,
-skins, and workflow; this tutorial is for those sorts of developers
-and projects.
-
-.. toctree::
-   :maxdepth: 2
-
-   content.rst
-   catalog.rst
-   skins.rst
-   actions.rst
-   workflow.rst
-   missing.rst
-
-
-
diff --git a/docs/tutorials/cmf/missing.rst b/docs/tutorials/cmf/missing.rst
deleted file mode 100644
index 964e0ab04..000000000
--- a/docs/tutorials/cmf/missing.rst
+++ /dev/null
@@ -1,22 +0,0 @@
-Missing Comparisons
-===================
-
-We currently don't have any comparative Pyramid-vs-CMF information
-about the following concepts within this tutorial:
-
-- Templates
-
-- Forms
-
-- Membership
-
-- Discussions
-
-- Syndication
-
-- Dublincore
-
-Please ask on the `Pylons-devel maillist
-<http://groups.google.com/group/pylons-devel>`_ or on the `#pylons IRC
-channel <http://irc.freenode.net#pylons>`_ about these topics.
-
diff --git a/docs/tutorials/cmf/skins.rst b/docs/tutorials/cmf/skins.rst
deleted file mode 100644
index 676a076b3..000000000
--- a/docs/tutorials/cmf/skins.rst
+++ /dev/null
@@ -1,23 +0,0 @@
-.. _skins_chapter:
-
-=====
-Skins
-=====
-
-In CMF, a "skin layer" is defined as a collection of templates and
-code (Python scripts, DTML methods, etc) that can be activated and
-deactivated within a particular setup.  A collection of active "skin
-layers" grouped in a particular order forms a "skin".  "Add-on" CMF
-products often provide skin layers that are activated within a
-particular skin to provide the site with additional features.
-
-To override static resources using a "search path" much like a set of
-skin layers, :app:`Pyramid` provides the concept of
-:term:`resource` overrides.  See :ref:`overriding_resources_section`
-for more information about resource overrides.
-
-While there is no analogue to a skin layer search path for locating
-Python code (as opposed to resources), :term:`view` code combined with
-differing :term:`predicate` arguments can provide a good deal of
-the same sort of behavior.
-
diff --git a/docs/tutorials/cmf/workflow.rst b/docs/tutorials/cmf/workflow.rst
deleted file mode 100644
index cc70d771a..000000000
--- a/docs/tutorials/cmf/workflow.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-.. _workflow_chapter:
-
-========
-Workflow
-========
-
-In CMF, the "workflow tool" allows developers to design state machines
-which imply transition between content states.
-
-:app:`Pyramid` itself has no such concept, but the
-:term:`repoze.workflow` package provides a simple state machine
-implementation that can act as a barebones workflow tool.  See its
-documentation for more information.
-