diff options
Diffstat (limited to 'docs/tutorials/wiki')
| -rw-r--r-- | docs/tutorials/wiki/authorization.rst | 10 | ||||
| -rw-r--r-- | docs/tutorials/wiki/background.rst | 6 | ||||
| -rw-r--r-- | docs/tutorials/wiki/basiclayout.rst | 6 | ||||
| -rw-r--r-- | docs/tutorials/wiki/definingmodels.rst | 2 | ||||
| -rw-r--r-- | docs/tutorials/wiki/definingviews.rst | 16 | ||||
| -rw-r--r-- | docs/tutorials/wiki/distributing.rst | 2 | ||||
| -rw-r--r-- | docs/tutorials/wiki/index.rst | 2 | ||||
| -rw-r--r-- | docs/tutorials/wiki/installation.rst | 10 | ||||
| -rw-r--r-- | docs/tutorials/wiki/viewdecorators.rst | 2 |
9 files changed, 28 insertions, 28 deletions
diff --git a/docs/tutorials/wiki/authorization.rst b/docs/tutorials/wiki/authorization.rst index e63a610c2..062c553b5 100644 --- a/docs/tutorials/wiki/authorization.rst +++ b/docs/tutorials/wiki/authorization.rst @@ -7,7 +7,7 @@ view, edit, and add pages to our wiki. For purposes of demonstration we'll change our application to allow people whom are members of a *group* named ``group:editors`` to add and edit wiki pages but we'll continue allowing anyone with access to the server to view pages. -:mod:`pyramid` provides facilities for *authorization* and +:app:`Pyramid` provides facilities for *authorization* and *authentication*. We'll make use of both features to provide security to our application. @@ -19,7 +19,7 @@ The source code for this tutorial stage can be browsed via Configuring a ``pyramid`` Authentication Policy -------------------------------------------------- -For any :mod:`pyramid` application to perform authorization, we +For any :app:`Pyramid` application to perform authorization, we need to add a ``security.py`` module and we'll need to change our :term:`application registry` to add an :term:`authentication policy` and a :term:`authorization policy`. @@ -31,7 +31,7 @@ We'll change our ``configure.zcml`` file to enable an ``AuthTktAuthenticationPolicy`` and an ``ACLAuthorizationPolicy`` to enable declarative security checking. We'll also add a new view stanza, which specifies a :term:`forbidden view`. This configures our -login view to show up when :mod:`pyramid` detects that a view +login view to show up when :app:`Pyramid` detects that a view invocation can not be authorized. When you're done, your ``configure.zcml`` will look like so: @@ -146,7 +146,7 @@ Giving Our Root Model Object an ACL ----------------------------------- We need to give our root model object an :term:`ACL`. This ACL will -be sufficient to provide enough information to the :mod:`pyramid` +be sufficient to provide enough information to the :app:`Pyramid` security machinery to challenge a user who doesn't have appropriate credentials when he attempts to invoke the ``add_page`` or ``edit_page`` views. @@ -171,7 +171,7 @@ class scope to our ``Wiki`` class: It's only happenstance that we're assigning this ACL at class scope. An ACL can be attached to an object *instance* too; this is how "row -level security" can be achieved in :mod:`pyramid` applications. We +level security" can be achieved in :app:`Pyramid` applications. We actually only need *one* ACL for the entire system, however, because our security requirements are simple, so this feature is not demonstrated. diff --git a/docs/tutorials/wiki/background.rst b/docs/tutorials/wiki/background.rst index a7f9d1e82..e49407b70 100644 --- a/docs/tutorials/wiki/background.rst +++ b/docs/tutorials/wiki/background.rst @@ -2,8 +2,8 @@ Background ========== -This version of the :mod:`pyramid` wiki tutorial presents a -:mod:`pyramid` application that uses technologies which will be +This version of the :app:`Pyramid` wiki tutorial presents a +:app:`Pyramid` application that uses technologies which will be familiar to someone with :term:`Zope` experience. It uses :term:`ZODB` as a persistence mechanism and :term:`traversal` to map URLs to code. It can also be followed by people without any prior @@ -13,6 +13,6 @@ To code along with this tutorial, the developer will need a UNIX machine with development tools (Mac OS X with XCode, any Linux or BSD variant, etc) *or* he will need a Windows system of any kind. -This tutorial targets :mod:`pyramid` version 1.0. +This tutorial targets :app:`Pyramid` version 1.0. Have fun! diff --git a/docs/tutorials/wiki/basiclayout.rst b/docs/tutorials/wiki/basiclayout.rst index d129ff7ec..85cfc825b 100644 --- a/docs/tutorials/wiki/basiclayout.rst +++ b/docs/tutorials/wiki/basiclayout.rst @@ -4,7 +4,7 @@ Basic Layout The starter files generated by the ``pyramid_zodb`` template are basic, but they provide a good orientation for the high-level patterns common -to most :term:`traversal` -based :mod:`pyramid` (and :term:`ZODB` +to most :term:`traversal` -based :app:`Pyramid` (and :term:`ZODB` based) projects. The source code for this tutorial stage can be browsed via @@ -101,7 +101,7 @@ following: Content Models with ``models.py`` --------------------------------- -:mod:`pyramid` often uses the word :term:`model` when talking about +:app:`Pyramid` often uses the word :term:`model` when talking about content resources arranged in the hierarchical *object graph* consulted by :term:`traversal`. The ``models.py`` file is where the ``pyramid_zodb`` Paster template put the classes that implement our @@ -124,7 +124,7 @@ Here is the source for ``models.py``: #. *Lines 6-12*. ``appmaker`` is used to return the *application root* object. It is called on *every request* to the - :mod:`pyramid` application. It also performs bootstrapping by + :app:`Pyramid` application. It also performs bootstrapping by *creating* an application root (inside the ZODB root object) if one does not already exist. diff --git a/docs/tutorials/wiki/definingmodels.rst b/docs/tutorials/wiki/definingmodels.rst index 3fa72dd87..097485047 100644 --- a/docs/tutorials/wiki/definingmodels.rst +++ b/docs/tutorials/wiki/definingmodels.rst @@ -57,7 +57,7 @@ Our ``Wiki`` class should also have a ``__name__`` attribute set to ``None`` at class scope, and should have a ``__parent__`` attribute set to ``None`` at class scope as well. If a model has a ``__parent__`` attribute of ``None`` in a traversal-based -:mod:`pyramid` application, it means that it's the :term:`root` +:app:`Pyramid` application, it means that it's the :term:`root` model. The ``__name__`` of the root model is also always ``None``. Then we'll add a ``Page`` class. This class should inherit from the diff --git a/docs/tutorials/wiki/definingviews.rst b/docs/tutorials/wiki/definingviews.rst index 797eee0d9..bbda3d45c 100644 --- a/docs/tutorials/wiki/definingviews.rst +++ b/docs/tutorials/wiki/definingviews.rst @@ -2,16 +2,16 @@ Defining Views ============== -A :term:`view callable` in a traversal-based :mod:`pyramid` +A :term:`view callable` in a traversal-based :app:`Pyramid` application is typically a simple Python function that accepts two parameters: :term:`context`, and :term:`request`. A view callable is assumed to return a :term:`response` object. -.. note:: A :mod:`pyramid` view can also be defined as callable +.. note:: A :app:`Pyramid` view can also be defined as callable which accepts *one* arguments: a :term:`request`. You'll see this - one-argument pattern used in other :mod:`pyramid` tutorials and + one-argument pattern used in other :app:`Pyramid` tutorials and applications. Either calling convention will work in any - :mod:`pyramid` application; the calling conventions can be used + :app:`Pyramid` application; the calling conventions can be used interchangeably as necessary. In :term:`traversal` based applications, such as this tutorial, the context is used frequently within the body of a view method, so it makes sense to use the @@ -22,7 +22,7 @@ assumed to return a :term:`response` object. to avoid the visual "noise". We're going to define several :term:`view callable` functions then -wire them into :mod:`pyramid` using some :term:`view +wire them into :app:`Pyramid` using some :term:`view configuration` via :term:`ZCML`. The source code for this tutorial stage can be browsed via @@ -102,7 +102,7 @@ Note the contrast between this view callable and the ``view_wiki`` view callable. In the ``view_wiki`` view callable, we return a :term:`response` object. In the ``view_page`` view callable, we return a *dictionary*. It is *always* fine to return a -:term:`response` object from a :mod:`pyramid` view. Returning a +:term:`response` object from a :app:`Pyramid` view. Returning a dictionary is allowed only when there is a :term:`renderer` associated with the view callable in the view configuration. @@ -116,7 +116,7 @@ this view. It also acts as a handler for the form that is generated when we want to add a page object. The ``context`` of the ``add_page`` view is always a Wiki object (*not* a Page object). -The request :term:`subpath` in :mod:`pyramid` is the sequence of +The request :term:`subpath` in :app:`Pyramid` is the sequence of names that are found *after* the view name in the URL segments given in the ``PATH_INFO`` of the WSGI request as the result of :term:`traversal`. If our add view is invoked via, @@ -182,7 +182,7 @@ Adding Templates Most view callables we've added expected to be rendered via a :term:`template`. Each template is a :term:`Chameleon` template. The -default templating system in :mod:`pyramid` is a variant of +default templating system in :app:`Pyramid` is a variant of :term:`ZPT` provided by Chameleon. These templates will live in the ``templates`` directory of our tutorial package. diff --git a/docs/tutorials/wiki/distributing.rst b/docs/tutorials/wiki/distributing.rst index 81ec61a63..ad717e72a 100644 --- a/docs/tutorials/wiki/distributing.rst +++ b/docs/tutorials/wiki/distributing.rst @@ -6,7 +6,7 @@ Once your application works properly, you can create a "tarball" from it by using the ``setup.py sdist`` command. The following commands assume your current working directory is the ``tutorial`` package we've created and that the parent directory of the ``tutorial`` -package is a virtualenv representing a :mod:`pyramid` environment. +package is a virtualenv representing a :app:`Pyramid` environment. On UNIX: diff --git a/docs/tutorials/wiki/index.rst b/docs/tutorials/wiki/index.rst index 1fdc4be95..68f724902 100644 --- a/docs/tutorials/wiki/index.rst +++ b/docs/tutorials/wiki/index.rst @@ -3,7 +3,7 @@ ZODB + Traversal Wiki Tutorial (For Developers Familiar with Zope) ================================================================== -This tutorial introduces a :term:`traversal` -based :mod:`pyramid` +This tutorial introduces a :term:`traversal` -based :app:`Pyramid` application to a developer familiar with Python. It will be most familiar to developers with previous :term:`Zope` experience. When we're done with the tutorial, the developer will have created a basic Wiki application with diff --git a/docs/tutorials/wiki/installation.rst b/docs/tutorials/wiki/installation.rst index 3e1b7552c..cb05611b7 100644 --- a/docs/tutorials/wiki/installation.rst +++ b/docs/tutorials/wiki/installation.rst @@ -52,7 +52,7 @@ Preparation, UNIX #. (Optional) Consider using ``source bin/activate`` to make your shell environment wired to use the virtualenv. -#. Use ``easy_install`` to get :mod:`pyramid` and its direct +#. Use ``easy_install`` to get :app:`Pyramid` and its direct dependencies installed: .. code-block:: bash @@ -104,7 +104,7 @@ Preparation, Windows #. (Optional) Consider using ``bin\activate.bat`` to make your shell environment wired to use the virtualenv. -#. Use ``easy_install`` to get :mod:`pyramid` and its direct +#. Use ``easy_install`` to get :app:`Pyramid` and its direct dependencies installed: .. code-block:: bat @@ -124,7 +124,7 @@ Preparation, Windows Making a Project ================ -Your next step is to create a project. :mod:`pyramid` supplies a +Your next step is to create a project. :app:`Pyramid` supplies a variety of templates to generate sample projects. For this tutorial, we will use the :term:`ZODB` -oriented template named ``pyramid_zodb``. @@ -255,8 +255,8 @@ assumptions: .. note:: - :mod:`pyramid` supports any persistent storage mechanism (e.g. a SQL - database or filesystem files, etc). :mod:`pyramid` also supports an + :app:`Pyramid` supports any persistent storage mechanism (e.g. a SQL + database or filesystem files, etc). :app:`Pyramid` also supports an additional mechanism to map URLs to code (:term:`URL dispatch`). However, for the purposes of this tutorial, we'll only be using traversal and ZODB. diff --git a/docs/tutorials/wiki/viewdecorators.rst b/docs/tutorials/wiki/viewdecorators.rst index 2d58890e4..c2f068d86 100644 --- a/docs/tutorials/wiki/viewdecorators.rst +++ b/docs/tutorials/wiki/viewdecorators.rst @@ -154,7 +154,7 @@ Adding a Scan Directive In order for our decorators to be recognized, we must add a bit of boilerplate to our ``configure.zcml`` file which tells -:mod:`pyramid` to kick off a :term:`scan` at startup time. Add the +:app:`Pyramid` to kick off a :term:`scan` at startup time. Add the following tag anywhere beneath the ``<include package="pyramid.includes">`` tag but before the ending ``</configure>`` tag within ``configure.zcml``: |