diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/tutorials/wiki2/basiclayout.rst | 21 | ||||
| -rw-r--r-- | docs/tutorials/wiki2/definingviews.rst | 28 |
2 files changed, 24 insertions, 25 deletions
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 ------------------------------ |