- The (weak) "Converting a CMF Application to Pyramid" tutorial has been

  removed from the tutorials section.  It was moved to the
  ``pyramid_tutorials`` Github repository.

7 files changed, 0 insertions, 265 deletions

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.
-