diff options
Diffstat (limited to 'docs/tutorials')
| -rw-r--r-- | docs/tutorials/wiki2/basiclayout.rst | 19 | ||||
| -rw-r--r-- | docs/tutorials/wiki2/definingviews.rst | 22 |
2 files changed, 18 insertions, 23 deletions
diff --git a/docs/tutorials/wiki2/basiclayout.rst b/docs/tutorials/wiki2/basiclayout.rst index eb2445864..6d6287126 100644 --- a/docs/tutorials/wiki2/basiclayout.rst +++ b/docs/tutorials/wiki2/basiclayout.rst @@ -132,11 +132,11 @@ Finally, ``main`` is finished configuring things, so it uses the View Declarations via ``views.py`` ---------------------------------- -Mapping a :term:`route` to code that will be executed when a match for -the route's pattern occurs is done by registering a :term:`view -configuration`. Our application uses the -:meth:`pyramid.view.view_config` decorator to map view callables to -each route, thereby mapping URL patterns to code. +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. Open ``tutorial/tutorial/views.py``. It should already contain the following: @@ -228,11 +228,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. +``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 to models, views, and initialization code in +That's about all there is to it with models, views, and initialization code in our stock application. diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index f2ac2f85f..9894bcb08 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -6,15 +6,12 @@ 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 passed to every view that is called as the result of a -route match has an attribute named ``matchdict`` that contains the elements -placed into the URL by the ``pattern`` of a ``route`` statement. For -instance, if a call to :meth:`pyramid.config.Configurator.add_route` in -``__init__.py`` had the pattern ``{one}/{two}``, and the URL at -``http://example.com/foo/bar`` was invoked, matching this pattern, the -``matchdict`` dictionary attached to the request passed to the view would -have a ``'one'`` key with the value ``'foo'`` and a ``'two'`` key with the -value ``'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 :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'}`` Declaring Dependencies in Our ``setup.py`` File @@ -152,10 +149,9 @@ 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 template. In our case, -the template which will be rendered will be the ``templates/view.pt`` -template, as indicated in the ``@view_config`` decorator that is applied to -``view_page()``. +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 ------------------------------ |