diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/narr/traversal.rst | 11 | ||||
| -rw-r--r-- | docs/tutorials/wiki2/basiclayout.rst | 21 | ||||
| -rw-r--r-- | docs/tutorials/wiki2/definingviews.rst | 28 |
3 files changed, 31 insertions, 29 deletions
diff --git a/docs/narr/traversal.rst b/docs/narr/traversal.rst index 1234620c2..a2eac61de 100644 --- a/docs/narr/traversal.rst +++ b/docs/narr/traversal.rst @@ -22,10 +22,13 @@ resource found as the result of a traversal becomes the subsystem is used to find some view code willing to "publish" this resource by generating a :term:`response`. -Using :term:`Traversal` to map a URL to code is optional. It is often -less easy to understand than :term:`URL dispatch`, so if you're a rank -beginner, it probably makes sense to use URL dispatch to map URLs to -code instead of traversal. In that case, you can skip this chapter. +.. note:: + + Using :term:`Traversal` to map a URL to code is optional. If you're creating + your first Pyramid application it probably makes more sense to use :term:`URL + dispatch` to map URLs to code instead of traversal, as new Pyramid developers + tend to find URL dispatch slightly easier to understand. If you use URL + dispatch, you needn't read this chapter. .. index:: single: traversal details diff --git a/docs/tutorials/wiki2/basiclayout.rst b/docs/tutorials/wiki2/basiclayout.rst index 6d6287126..0193afab4 100644 --- a/docs/tutorials/wiki2/basiclayout.rst +++ b/docs/tutorials/wiki2/basiclayout.rst @@ -132,11 +132,10 @@ Finally, ``main`` is finished configuring things, so it uses the View Declarations via ``views.py`` ---------------------------------- -Arguably, the main function of a web framework is mapping each URL -patterns, see :term:`route`, to code, see :term:`view callable`, that is -executed when the requested URL matches the corresponding :term:`route`. Our -application uses the :meth:`pyramid.view.view_config` decorator to perform -this mapping. +The main function of a web framework is mapping each URL pattern to code (a +:term:`view callable`) that is executed when the requested URL matches the +corresponding :term:`route`. Our application uses the +:meth:`pyramid.view.view_config` decorator to perform this mapping. Open ``tutorial/tutorial/views.py``. It should already contain the following: @@ -228,10 +227,10 @@ To give a simple example of a model class, we define one named ``MyModel``: Our example model has an ``__init__`` method that takes two arguments (``name``, and ``value``). It stores these values as ``self.name`` and -``self.value`` within the ``__init__`` function itself. The ``MyModel`` class -also has a ``__tablename__`` attribute. This informs SQLAlchemy which table -to use to store the data representing instances of this class. - -That's about all there is to it with models, views, and initialization code in -our stock application. +``self.value`` on the instance created by the ``__init__`` function itself. +The ``MyModel`` class also has a ``__tablename__`` attribute. This informs +SQLAlchemy which table to use to store the data representing instances of this +class. +That's about all there is to it regarding models, views, and initialization +code in our stock application. diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 9894bcb08..53f8e569c 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -6,13 +6,13 @@ A :term:`view callable` in a :app:`Pyramid` application is typically a simple Python function that accepts a single parameter named :term:`request`. A view callable is assumed to return a :term:`response` object. -The request object has a dictionary as an attribute named ``matchdict``. -A ``matchdict`` maps the placeholders in the matching URL ``pattern`` to the substrings -of the :term:`request` ed URL. For instance, if a call to -:meth:`pyramid.config.Configurator.add_route` has the pattern -``{one}/{two}``, and a user visits ``http://example.com/foo/bar``, our pattern would be -matched and the ``matchdict`` would look like: ``{'one':'foo', 'two':'bar'}`` - +The request object has a dictionary as an attribute named ``matchdict``. A +``matchdict`` maps the placeholders in the matching URL ``pattern`` to the +substrings of the path in the :term:`request` URL. For instance, if a call to +:meth:`pyramid.config.Configurator.add_route` has the pattern ``/{one}/{two}``, +and a user visits ``http://example.com/foo/bar``, our pattern would be matched +against ``/foo/bar`` and the ``matchdict`` would look like: ``{'one':'foo', +'two':'bar'}`` Declaring Dependencies in Our ``setup.py`` File =============================================== @@ -145,13 +145,13 @@ As a result, the ``content`` variable is now a fully formed bit of HTML containing various view and add links for WikiWords based on the content of our current page object. -We then generate an edit URL (because it's easier to do here than in the -template), and we return a dictionary with a number of arguments. The fact -that ``view_page()`` returns a dictionary (as opposed to a :term:`response` -object) is a cue to :app:`Pyramid` that it should try to use a :term:`renderer` -associated with the view configuration to render a response. In our case, -the renderer used will be the ``templates/view.pt`` template, as indicated in -the ``@view_config`` decorator that is applied to ``view_page()``. +We then generate an edit URL because it's easier to do here than in the +template, and we return a dictionary with a number of arguments. The fact that +``view_page()`` returns a dictionary (as opposed to a :term:`response` object) +is a cue to :app:`Pyramid` that it should try to use a :term:`renderer` +associated with the view configuration to render a response. In our case, the +renderer used will be the ``templates/view.pt`` template, as indicated in the +``@view_config`` decorator that is applied to ``view_page()``. The ``add_page`` view function ------------------------------ |