Merge branch 'master' into viewderiver

13 files changed, 8 insertions, 273 deletions

diff --git a/docs/index.rst b/docs/index.rst
index 23ffb3b1b..d35eb2325 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -78,7 +78,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/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 71c6cf305..037bfc416 100644
--- a/docs/narr/flash.rst
+++ b/docs/narr/flash.rst
@@ -87,8 +87,8 @@ 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"
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/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/urldispatch.rst b/docs/narr/urldispatch.rst
index 4c601340f..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**
 
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.
-