From f8dbdee6167b3b4ab1ee4b2138a3e04e47a7c9df Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Thu, 18 Jun 2009 06:35:21 +0000 Subject: - The matchdict related to the matching of a Routes route is available on the request as the ``matchdict`` attribute: ``request.matchdict``. If no route matched, this attribute will be None. --- docs/tutorials/bfgwiki2/definingviews.rst | 63 ++++++++++++++++++------------- 1 file changed, 36 insertions(+), 27 deletions(-) (limited to 'docs/tutorials/bfgwiki2/definingviews.rst') diff --git a/docs/tutorials/bfgwiki2/definingviews.rst b/docs/tutorials/bfgwiki2/definingviews.rst index 4d90db11f..25f52291c 100644 --- a/docs/tutorials/bfgwiki2/definingviews.rst +++ b/docs/tutorials/bfgwiki2/definingviews.rst @@ -7,13 +7,20 @@ parameters: :term:`context`, and :term:`request`. A view is assumed to return a :term:`response` object. A invocation of a view that matches a URL via :term:`url dispatch` -passes as the context object an object which has attributes matching -the elements placed into the URL by the ``path`` of a ``route`` -statement. For instance, if a route statement in ``configure.zcml`` -had the path ``:one/:two``, and the URL at -``http://example.com/foo/bar`` was invoked, matching this path, the -context object passed to the view would have a ``one`` attribute withe -the value ``foo`` and a ``two`` attribute with the value ``bar``. +passes as the context object an object generated by a ``root +factory``. In this application, the context will always be generated +by the *default* root factory. Since we're not using traversal in +this application, this means the context will appear useless, at least +until we get to :ref:`wiki2_adding_authorization`. + +The request 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 ``path`` of a ``route`` statement. +For instance, if a route statement in ``configure.zcml`` had the path +``:one/:two``, and the URL at ``http://example.com/foo/bar`` was +invoked, matching this path, the matchdict dictionary attached to the +request passed to the view would have a ``one`` key withe the value +``foo`` and a ``two`` key with the value ``bar``. Declaring Dependencies in Our ``setup.py`` File =============================================== @@ -111,14 +118,14 @@ The ``add_page`` function will be invoked when a user clicks on a *WikiWord* which isn't yet represented as a page in the system. The ``check`` function within the ``view_page`` view generates URLs to 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 will always have the attributes we need to -construct URLs and find model objects. +when we want to add a page object. The ``matchdict`` attribute of the +request passed to the ``add_page`` view will have the values we need +to construct URLs and find model objects. -The context object will have a ``pagename`` attribute that matches the -name of the page we'd like to add. If our add view is invoked via, +The matchdict will have a ``pagename`` key that matches the name of +the page we'd like to add. If our add view is invoked via, e.g. ``http://localhost:6543/add_page/SomeName``, the ``pagename`` -attribute of the context will be ``SomeName``. +value in the matchdict will be ``SomeName``. If the view rendering is *not* a result of a form submission (if the expression ``'form.submitted' in request.params`` is False), the view @@ -133,7 +140,7 @@ response. If the view rendering *is* a result of a form submission (if the expression ``'form.submitted' in request.params`` is True), we scrape the page body from the form data, create a Page object using the name -in ``pagename`` context attribute and obtain the page body from the +in the matchdict ``pagename``, and obtain the page body from the request, and save it into the database using ``session.add``. We then redirect back to the ``view_page`` view (the default view for a page) for the newly created page. @@ -143,9 +150,10 @@ The ``edit_page`` view function The ``edit_page`` function will be invoked when a user clicks the "Edit this Page" button on the view form. It renders an edit form but -it also acts as the handler for the form it renders. The ``context`` -of the ``edit_page`` view will *always* have a ``pagename`` attribute -matching the name of the page the user wants to edit. +it also acts as the handler for the form it renders. The +``matchdict`` attribute of the request passed to the ``add_page`` view +will have a ``pagename`` key matching the name of the page the user +wants to edit. If the view rendering is *not* a result of a form submission (if the expression ``'form.submitted' in request.params`` is False), the view @@ -155,9 +163,9 @@ and a save_url which will be used as the action of the generated form. If the view rendering *is* a result of a form submission (if the expression ``'form.submitted' in request.params`` is True), the view grabs the ``body`` element of the request parameter and sets it as the -``data`` attribute of the page context. It then redirects to the -default view of the context (the page), which will always be the -``view_page`` view. +``data`` key in the matchdict. It then redirects to the default view +of the context (the page), which will always be the ``view_page`` +view. Viewing the Result of Our Edits to ``views.py`` =============================================== @@ -234,14 +242,15 @@ number and type of static resources can be placed in this directory Mapping Views to URLs in ``configure.zcml`` =========================================== -The ``configure.zcml`` file contains ``route`` declarations which -serve to map URLs (via :term:`url dispatch`) to view functions. -First, we’ll get rid of the existing ``route`` created by the -template using the name ``home``. It’s only an example and isn’t -relevant to our application. We'll leave the static ``route`` -declaration as it is, since we are going to use it for the CSS. +The ``configure.zcml`` file contains ``route`` declarations (and a +lone ``view`` declaration) which serve to map URLs (via :term:`url +dispatch`) to view functions. First, we’ll get rid of the existing +``route`` created by the template using the name ``home``. It’s only +an example and isn’t relevant to our application. We'll leave the +static ``view`` declaration as it is, since we are going to use it to +serve CSS. -We then need to add four ``view`` declarations to ``configure.zcml``. +We then need to add four ``route`` declarations to ``configure.zcml``. Note that the *ordering* of these declarations is very important. ``route`` declarations are matched in the order they're found in the ``configure.zcml`` file. -- cgit v1.2.3