diff options
Diffstat (limited to 'docs/tutorials/cmf')
| -rw-r--r-- | docs/tutorials/cmf/actions.rst | 2 | ||||
| -rw-r--r-- | docs/tutorials/cmf/catalog.rst | 2 | ||||
| -rw-r--r-- | docs/tutorials/cmf/content.rst | 6 | ||||
| -rw-r--r-- | docs/tutorials/cmf/index.rst | 12 | ||||
| -rw-r--r-- | docs/tutorials/cmf/skins.rst | 2 | ||||
| -rw-r--r-- | docs/tutorials/cmf/workflow.rst | 2 |
6 files changed, 13 insertions, 13 deletions
diff --git a/docs/tutorials/cmf/actions.rst b/docs/tutorials/cmf/actions.rst index 0de6d580d..8af8e5fd4 100644 --- a/docs/tutorials/cmf/actions.rst +++ b/docs/tutorials/cmf/actions.rst @@ -8,7 +8,7 @@ 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. -:mod:`pyramid` itself has no such concept, and no package provides +: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 diff --git a/docs/tutorials/cmf/catalog.rst b/docs/tutorials/cmf/catalog.rst index 11a9483a6..d5e9534ae 100644 --- a/docs/tutorials/cmf/catalog.rst +++ b/docs/tutorials/cmf/catalog.rst @@ -8,7 +8,7 @@ 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. -:mod:`pyramid` itself has no cataloging facility, but an addon +:app:`Pyramid` itself has no cataloging facility, but an addon package named :term:`repoze.catalog` offers similar functionality. Creating an Allowed Index diff --git a/docs/tutorials/cmf/content.rst b/docs/tutorials/cmf/content.rst index a8b2b8124..85e5b5fbc 100644 --- a/docs/tutorials/cmf/content.rst +++ b/docs/tutorials/cmf/content.rst @@ -10,7 +10,7 @@ code which generates an instance of that content. It is possible to construct and enumerate content types using APIs defined on the types tool. -:mod:`pyramid` itself has no such concept, but an addon package named +:app:`Pyramid` itself has no such concept, but an addon package named :term:`repoze.lemonade` has a barebones replacement. Factory Type Information @@ -22,7 +22,7 @@ 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. -:mod:`pyramid` certainly enforces none of these concepts in any +:app:`Pyramid` certainly enforces none of these concepts in any particular way, but :term:`repoze.lemonade` does. ``repoze.lemonade`` Content @@ -51,7 +51,7 @@ of helper functions which allow you to: 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 :mod:`pyramid`, so we'll assume + get CMF-like features in :app:`Pyramid`, so we'll assume the pattern is useful to readers. See the `repoze.lemonade package diff --git a/docs/tutorials/cmf/index.rst b/docs/tutorials/cmf/index.rst index 65ad99551..94c73af8e 100644 --- a/docs/tutorials/cmf/index.rst +++ b/docs/tutorials/cmf/index.rst @@ -1,21 +1,21 @@ -Converting an Existing Zope/CMF Application to :mod:`pyramid` +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 :mod:`pyramid`. +application to :app:`Pyramid`. -The main difference between CMF and :mod:`pyramid` is that -:mod:`pyramid` does not advertise itself as a system into which you +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 -:mod:`pyramid` (as CMF is built on Zope) but none currently exists. +:app:`Pyramid` (as CMF is built on Zope) but none currently exists. For those sorts of high-extensibility, highly-regularized-UI systems, CMF is still the better choice. -:mod:`pyramid` (and other more lightweight systems) is often a +: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. diff --git a/docs/tutorials/cmf/skins.rst b/docs/tutorials/cmf/skins.rst index 7ec3b1be6..676a076b3 100644 --- a/docs/tutorials/cmf/skins.rst +++ b/docs/tutorials/cmf/skins.rst @@ -12,7 +12,7 @@ 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, :mod:`pyramid` provides the concept of +skin layers, :app:`Pyramid` provides the concept of :term:`resource` overrides. See :ref:`overriding_resources_section` for more information about resource overrides. diff --git a/docs/tutorials/cmf/workflow.rst b/docs/tutorials/cmf/workflow.rst index 35cf552d2..cc70d771a 100644 --- a/docs/tutorials/cmf/workflow.rst +++ b/docs/tutorials/cmf/workflow.rst @@ -7,7 +7,7 @@ Workflow In CMF, the "workflow tool" allows developers to design state machines which imply transition between content states. -:mod:`pyramid` itself has no such concept, but the +: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. |