From a7e625785f65c41e5a6dc017b31bd0d74821474e Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Tue, 31 May 2011 14:40:05 -0400 Subject: the canonical import location for HTTP exceptions/responses is now pyramid.response --- docs/tutorials/wiki2/definingviews.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 832f90b92..32e3c0b24 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -90,8 +90,8 @@ path to our "FrontPage". :language: python The ``view_wiki`` function returns an instance of the -:class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement -the WebOb :term:`response` interface), It will use the +:class:`pyramid.response.HTTPFound` class (instances of which implement the +WebOb :term:`response` interface), It will use the :func:`pyramid.url.route_url` API to construct a URL to the ``FrontPage`` page (e.g. ``http://localhost:6543/FrontPage``), and will use it as the "location" of the HTTPFound response, forming an HTTP redirect. -- cgit v1.2.3 From 99edc51a3b05309c7f5d98ff96289ec51b1d7660 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Sat, 11 Jun 2011 05:35:27 -0400 Subject: - Pyramid now expects Response objects to have a __call__ method which implements the WSGI application interface instead of the three webob attrs status, headerlist and app_iter. Backwards compatibility exists for code which returns response objects that do not have a __call__. - pyramid.response.Response is no longer an exception (and therefore cannot be raised in order to generate a response). - Changed my mind about moving stuff from pyramid.httpexceptions to pyramid.response. The stuff I moved over has been moved back to pyramid.httpexceptions. --- docs/tutorials/wiki2/definingviews.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 32e3c0b24..832f90b92 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -90,8 +90,8 @@ path to our "FrontPage". :language: python The ``view_wiki`` function returns an instance of the -:class:`pyramid.response.HTTPFound` class (instances of which implement the -WebOb :term:`response` interface), It will use the +:class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement +the WebOb :term:`response` interface), It will use the :func:`pyramid.url.route_url` API to construct a URL to the ``FrontPage`` page (e.g. ``http://localhost:6543/FrontPage``), and will use it as the "location" of the HTTPFound response, forming an HTTP redirect. -- cgit v1.2.3 From d868fff7597c5a05acd1f5c024fc45dde9880413 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Mon, 13 Jun 2011 06:17:00 -0400 Subject: - Remove IResponder abstraction in favor of more general IResponse abstraction. - It is now possible to return an arbitrary object from a Pyramid view callable even if a renderer is not used, as long as a suitable adapter to ``pyramid.interfaces.IResponse`` is registered for the type of the returned object. See the section in the Hooks chapter of the documentation entitled "Changing How Pyramid Treats View Responses". - The Pyramid router now, by default, expects response objects returned from view callables to implement the ``pyramid.interfaces.IResponse`` interface. Unlike the Pyramid 1.0 version of this interface, objects which implement IResponse now must define a ``__call__`` method that accepts ``environ`` and ``start_response``, and which returns an ``app_iter`` iterable, among other things. Previously, it was possible to return any object which had the three WebOb ``app_iter``, ``headerlist``, and ``status`` attributes as a response, so this is a backwards incompatibility. It is possible to get backwards compatibility back by registering an adapter to IResponse from the type of object you're now returning from view callables. See the section in the Hooks chapter of the documentation entitled "Changing How Pyramid Treats View Responses". - The ``pyramid.interfaces.IResponse`` interface is now much more extensive. Previously it defined only ``app_iter``, ``status`` and ``headerlist``; now it is basically intended to directly mirror the ``webob.Response`` API, which has many methods and attributes. - Documentation changes to support above. --- docs/tutorials/wiki2/definingviews.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 832f90b92..43cbc3483 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -91,7 +91,8 @@ path to our "FrontPage". The ``view_wiki`` function returns an instance of the :class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement -the WebOb :term:`response` interface), It will use the +the :class:`pyramid.interfaces.IResponse` interface like +:class:`pyramid.response.Response` does), It will use the :func:`pyramid.url.route_url` API to construct a URL to the ``FrontPage`` page (e.g. ``http://localhost:6543/FrontPage``), and will use it as the "location" of the HTTPFound response, forming an HTTP redirect. -- cgit v1.2.3 From 42d31c1c6355a7d6c72393ca668d7d200a994da3 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Sun, 14 Aug 2011 14:26:10 -0400 Subject: - All tutorials now use - The ``route_url``, ``route_path``, ``resource_url``, ``static_url``, and ``current_route_url`` methods of the request rather than the function variants imported from ``pyramid.url``. --- docs/tutorials/wiki2/definingviews.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index c91d1d914..8f6dd6455 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -93,9 +93,9 @@ The ``view_wiki`` function returns an instance of the :class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement the :class:`pyramid.interfaces.IResponse` interface like :class:`pyramid.response.Response` does), It will use the -:func:`pyramid.url.route_url` API to construct a URL to the ``FrontPage`` -page (e.g. ``http://localhost:6543/FrontPage``), and will use it as the -"location" of the HTTPFound response, forming an HTTP redirect. +:meth:`pyramid.request.Request.route_url` API to construct a URL to the +``FrontPage`` page (e.g. ``http://localhost:6543/FrontPage``), and will use +it as the "location" of the HTTPFound response, forming an HTTP redirect. The ``view_page`` view function ------------------------------- -- cgit v1.2.3 From 012b9762cd0b114b6afbf2d6356554b51706804a Mon Sep 17 00:00:00 2001 From: michr Date: Fri, 23 Sep 2011 18:48:28 -0700 Subject: fixed up all the warning dealing ..note and ..warn added a hide toc for glossary to prevent warnings --- docs/tutorials/wiki2/definingviews.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 8f6dd6455..234f91246 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -7,7 +7,9 @@ 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. -.. note:: A :app:`Pyramid` view can also be defined as callable +.. note:: + + A :app:`Pyramid` view can also be defined as callable which accepts *two* arguments: a :term:`context` and a :term:`request`. You'll see this two-argument pattern used in other :app:`Pyramid` tutorials and applications. Either calling -- cgit v1.2.3 From cfb2b5596b8ef366aeef3bce5b61eafc7a2f175d Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Thu, 6 Oct 2011 03:05:29 -0400 Subject: remove all reference to the paster command-line utility --- docs/tutorials/wiki2/definingviews.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 234f91246..21b97f7aa 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -40,7 +40,7 @@ Declaring Dependencies in Our ``setup.py`` File The view code in our application will depend on a package which is not a dependency of the original "tutorial" application. The original "tutorial" -application was generated by the ``paster create`` command; it doesn't know +application was generated by the ``pcreate`` command; it doesn't know about our custom application requirements. We need to add a dependency on the ``docutils`` package to our ``tutorial`` package's ``setup.py`` file by assigning this dependency to the ``install_requires`` parameter in the -- cgit v1.2.3 From 5edd54f05b05330fa6e899a1bb1650cc7a2df33c Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Sun, 27 Nov 2011 04:08:20 -0500 Subject: - The SQLAlchemy Wiki tutorial has been updated. It now uses ``@view_config`` decorators and an explicit database population script. Closes #359. --- docs/tutorials/wiki2/definingviews.rst | 161 +++++++++++++++++---------------- 1 file changed, 81 insertions(+), 80 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 21b97f7aa..7f533b635 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -2,34 +2,19 @@ Defining Views ============== -A :term:`view callable` in a :term:`url dispatch` -based :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. - -.. note:: - - A :app:`Pyramid` view can also be defined as callable - which accepts *two* arguments: a :term:`context` and a - :term:`request`. You'll see this two-argument pattern used in - other :app:`Pyramid` tutorials and applications. Either calling - convention will work in any :app:`Pyramid` application; the - calling conventions can be used interchangeably as necessary. In - :term:`url dispatch` based applications, however, the context - object is rarely used in the view body itself, so within this - tutorial we define views as callables that accept only a request to - avoid the visual "noise". If you do need the ``context`` within a - view function that only takes the request as a single argument, you - can obtain it via ``request.context``. - -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 ``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'``. +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 source code for this tutorial stage can be browsed at `http://github.com/Pylons/pyramid/tree/master/docs/tutorials/wiki2/src/views/ @@ -52,24 +37,56 @@ Our resulting ``setup.py`` should look like so: :linenos: :language: python -.. note:: After these new dependencies are added, you will need to - rerun ``python setup.py develop`` inside the root of the - ``tutorial`` package to obtain and register the newly added - dependency package. +Running ``setup.py develop`` +============================ + +Since a new software dependency was added, you will need to rerun ``python +setup.py develop`` inside the root of the ``tutorial`` package to obtain and +register the newly added dependency distribution. + +Make sure your current working directory is the root of the project (the +directory in which setup.py lives) and execute the following command. + +On UNIX: + +.. code-block:: text + + $ cd tutorial + $ ../bin/python setup.py develop -Adding View Functions -===================== +On Windows: -We'll get rid of our ``my_view`` view function in our ``views.py`` file. -It's only an example and isn't relevant to our application. +.. code-block:: text -Then we're going to add four :term:`view callable` functions to our -``views.py`` module. One view callable (named ``view_wiki``) will display -the wiki itself (it will answer on the root URL), another named ``view_page`` -will display an individual page, another named ``add_page`` will allow a page -to be added, and a final view callable named ``edit_page`` will allow a page -to be edited. We'll describe each one briefly and show the resulting -``views.py`` file afterward. + c:\pyramidtut> cd tutorial + c:\pyramidtut\tutorial> ..\Scripts\python setup.py develop + +Success executing this command will end with a line to the console something +like:: + + Finished processing dependencies for tutorial==0.0 + +Changing the ``views.py`` File +============================== + +We're going to edit our ``views.py`` in a rather major way. The result of +all of our edits to ``views.py`` will leave it looking like this: + +.. literalinclude:: src/views/tutorial/views.py + :linenos: + :language: python + +We've gotten rid of the ``my_view`` view function and its decorator that was +added when we originally rendered the ``alchemy`` scaffold. It was only an +example and isn't relevant to our application. + +Then we added four :term:`view callable` functions to our ``views.py`` +module. One view callable (named ``view_wiki``) will display the wiki itself +(it will answer on the root URL), another named ``view_page`` will display an +individual page, another named ``add_page`` will allow a page to be added, +and a final view callable named ``edit_page`` will allow a page to be edited. +We'll describe each one briefly and show the resulting ``views.py`` file +afterward. .. note:: @@ -195,16 +212,6 @@ If the view execution *is* a result of a form submission (if the expression attribute of the page object. It then redirects to the ``view_page`` view of the wiki page. -Viewing the Result of all Our Edits to ``views.py`` -=================================================== - -The result of all of our edits to ``views.py`` will leave it looking -like this: - -.. literalinclude:: src/views/tutorial/views.py - :linenos: - :language: python - Adding Templates ================ @@ -270,47 +277,41 @@ subdirectories) and are just referred to by URL or by using the convenience method ``static_url`` e.g. ``request.static_url('{{package}}:static/foo.css')`` within templates. -Mapping Views to URLs in ``__init__.py`` -======================================== +Adding Routes to ``__init__.py`` +================================ The ``__init__.py`` file contains -:meth:`pyramid.config.Configurator.add_view` calls which serve to map -routes via :term:`url dispatch` to views. 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. +:meth:`pyramid.config.Configurator.add_route` calls which serve to add routes +to our application. 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 then need to add four calls to ``add_route``. Note that the *ordering* of these declarations is very important. ``route`` declarations are matched in the order they're found in the ``__init__.py`` file. #. Add a declaration which maps the pattern ``/`` (signifying the root URL) - to the route named ``view_wiki``. + to the route named ``view_wiki``. It maps to our ``view_wiki`` view + callable by virtue of the ``@view_config`` attached to the ``view_wiki`` + view function indicating ``route_name='view_wiki'``. #. Add a declaration which maps the pattern ``/{pagename}`` to the route named - ``view_page``. This is the regular view for a page. + ``view_page``. This is the regular view for a page. It maps + to our ``view_page`` view callable by virtue of the ``@view_config`` + attached to the ``view_page`` view function indicating + ``route_name='view_page'``. #. Add a declaration which maps the pattern ``/add_page/{pagename}`` to the - route named ``add_page``. This is the add view for a new page. + route named ``add_page``. This is the add view for a new page. It maps + to our ``add_page`` view callable by virtue of the ``@view_config`` + attached to the ``add_page`` view function indicating + ``route_name='add_page'``. #. Add a declaration which maps the pattern ``/{pagename}/edit_page`` to the - route named ``edit_page``. This is the edit view for a page. - -After we've defined the routes for our application, we can register views -to handle the processing and rendering that needs to happen when each route is -requested. - -#. Add a declaration which maps the ``view_wiki`` route to the view named - ``view_wiki`` in our ``views.py`` file. This is the :term:`default view` - for the wiki. - -#. Add a declaration which maps the ``view_page`` route to the view named - ``view_page`` in our ``views.py`` file. - -#. Add a declaration which maps the ``add_page`` route to the view named - ``add_page`` in our ``views.py`` file. - -#. Add a declaration which maps the ``edit_page`` route to the view named - ``edit_page`` in our ``views.py`` file. + route named ``edit_page``. This is the edit view for a page. It maps + to our ``edit_page`` view callable by virtue of the ``@view_config`` + attached to the ``edit_page`` view function indicating + ``route_name='edit_page'``. As a result of our edits, the ``__init__.py`` file should look something like so: -- cgit v1.2.3 From d1ad7044480901123b9c744b686b579491c36683 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Sun, 29 Jan 2012 13:32:45 -0500 Subject: show decorators along with view callables, fixes #393 --- docs/tutorials/wiki2/definingviews.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 7f533b635..bda0a2eb7 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -104,7 +104,7 @@ when a request is made to the root URL of our wiki. It always redirects to a URL which represents the path to our "FrontPage". .. literalinclude:: src/views/tutorial/views.py - :pyobject: view_wiki + :lines: 18-21 :linenos: :language: python @@ -126,7 +126,7 @@ HTML anchor for each *WikiWord* reference in the rendered HTML using a compiled regular expression. .. literalinclude:: src/views/tutorial/views.py - :pyobject: view_page + :lines: 23-44 :linenos: :language: python @@ -161,7 +161,7 @@ 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. .. literalinclude:: src/views/tutorial/views.py - :pyobject: add_page + :lines: 46-58 :linenos: :language: python @@ -197,7 +197,7 @@ request passed to the ``edit_page`` view will have a ``'pagename'`` key matching the name of the page the user wants to edit. .. literalinclude:: src/views/tutorial/views.py - :pyobject: edit_page + :lines: 60-73 :linenos: :language: python -- cgit v1.2.3 From c6a299ad7159ffcabe201fa79f485c388d837971 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Tue, 14 Feb 2012 05:57:06 -0500 Subject: - Don't create a ``session`` instance in SQLA Wiki tutorial, use raw ``DBSession`` instead (this is more common in real SQLA apps). --- docs/tutorials/wiki2/definingviews.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index bda0a2eb7..a067dbd66 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -126,7 +126,7 @@ HTML anchor for each *WikiWord* reference in the rendered HTML using a compiled regular expression. .. literalinclude:: src/views/tutorial/views.py - :lines: 23-44 + :lines: 23-43 :linenos: :language: python @@ -161,7 +161,7 @@ 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. .. literalinclude:: src/views/tutorial/views.py - :lines: 46-58 + :lines: 45-56 :linenos: :language: python @@ -184,7 +184,7 @@ If the view execution *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 with this page body and the name taken from ``matchdict['pagename']``, and save it into the database using -``session.add``. We then redirect back to the ``view_page`` view for the +``DBSession.add``. We then redirect back to the ``view_page`` view for the newly created page. The ``edit_page`` view function @@ -197,7 +197,7 @@ request passed to the ``edit_page`` view will have a ``'pagename'`` key matching the name of the page the user wants to edit. .. literalinclude:: src/views/tutorial/views.py - :lines: 60-73 + :lines: 58-70 :linenos: :language: python -- cgit v1.2.3 From 218ad474c5e8db6925ed6a5f4067ae3db69f68c8 Mon Sep 17 00:00:00 2001 From: Patricio Paez Date: Mon, 12 Mar 2012 15:49:58 -0700 Subject: Added links to Starting the Application - Sections 'Viewing the Application in a Browser' in the 'Defining the Domain Model' and 'Defining the Views' chapters now offer a quick link in both wiki tutorials, as suggested by Paulo. --- docs/tutorials/wiki2/definingviews.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index a067dbd66..592b183a4 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -323,7 +323,8 @@ something like so: Viewing the Application in a Browser ==================================== -We can finally examine our application in a browser. The views we'll try are +We can finally examine our application in a browser (See +:ref:`wiki2-start-the-application`). The views we'll try are as follows: - Visiting ``http://localhost:6543`` in a browser invokes the -- cgit v1.2.3 From 533c89ebe807f02f5eae3240e770864b21f78168 Mon Sep 17 00:00:00 2001 From: Patricio Paez Date: Mon, 12 Mar 2012 17:57:13 -0700 Subject: Clarify two steps in the SQL wiki tutorial - Highlight the added or changed lines --- docs/tutorials/wiki2/definingviews.rst | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 592b183a4..5f7526b24 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -28,15 +28,18 @@ dependency of the original "tutorial" application. The original "tutorial" application was generated by the ``pcreate`` command; it doesn't know about our custom application requirements. We need to add a dependency on the ``docutils`` package to our ``tutorial`` package's ``setup.py`` file by -assigning this dependency to the ``install_requires`` parameter in the +assigning this dependency to the ``requires`` parameter in the ``setup`` function. -Our resulting ``setup.py`` should look like so: +Open ``tutorial/setup.py`` and edit it to look like the following: .. literalinclude:: src/views/setup.py :linenos: + :emphasize-lines: 17 :language: python +(Only the highlighted line needs to be added) + Running ``setup.py develop`` ============================ -- cgit v1.2.3 From 04df1056cdadf1420e75d8bbbe81a384041ab0f7 Mon Sep 17 00:00:00 2001 From: Audrey Roy Date: Tue, 13 Mar 2012 19:05:24 -0700 Subject: Wording improvements to Defining Views section of tutorial. --- docs/tutorials/wiki2/definingviews.rst | 68 +++++++++++++++++++--------------- 1 file changed, 38 insertions(+), 30 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 5f7526b24..6d5ae7f6a 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -26,17 +26,19 @@ Declaring Dependencies in Our ``setup.py`` File The view code in our application will depend on a package which is not a dependency of the original "tutorial" application. The original "tutorial" application was generated by the ``pcreate`` command; it doesn't know -about our custom application requirements. We need to add a dependency on -the ``docutils`` package to our ``tutorial`` package's ``setup.py`` file by -assigning this dependency to the ``requires`` parameter in the -``setup`` function. +about our custom application requirements. + +We need to add a dependency on the ``docutils`` package to our ``tutorial`` +package's ``setup.py`` file by assigning this dependency to the ``requires`` parameter in ``setup()``. Open ``tutorial/setup.py`` and edit it to look like the following: .. literalinclude:: src/views/setup.py :linenos: - :emphasize-lines: 17 :language: python + :emphasize-lines: 17 + +(Only the highlighted line needs to be changed.) (Only the highlighted line needs to be added) @@ -72,22 +74,27 @@ like:: Changing the ``views.py`` File ============================== -We're going to edit our ``views.py`` in a rather major way. The result of -all of our edits to ``views.py`` will leave it looking like this: +It's time for a major change. Open ``tutorial/tutorial/views.py`` and edit it to look like the following: .. literalinclude:: src/views/tutorial/views.py :linenos: :language: python + :emphasize-lines: 1-7,12,15-70 -We've gotten rid of the ``my_view`` view function and its decorator that was +(The highlighted lines are the ones that need to be added or edited.) + +We got rid of the ``my_view`` view function and its decorator that was added when we originally rendered the ``alchemy`` scaffold. It was only an example and isn't relevant to our application. Then we added four :term:`view callable` functions to our ``views.py`` -module. One view callable (named ``view_wiki``) will display the wiki itself -(it will answer on the root URL), another named ``view_page`` will display an -individual page, another named ``add_page`` will allow a page to be added, -and a final view callable named ``edit_page`` will allow a page to be edited. +module: + +* ``view_wiki()`` - Displays the wiki itself. It will answer on the root URL. +* ``view_page()`` - Displays an individual page. +* ``add_page()`` - Allows the user to add a page. +* ``edit_page()`` - Allows the user to edit a page. + We'll describe each one briefly and show the resulting ``views.py`` file afterward. @@ -102,8 +109,8 @@ afterward. The ``view_wiki`` view function ------------------------------- -The ``view_wiki`` function is the :term:`default view` that will be called -when a request is made to the root URL of our wiki. It always redirects to +``view_wiki()`` is the :term:`default view` that gets called when a request +is made to the root URL of our wiki. It always redirects to a URL which represents the path to our "FrontPage". .. literalinclude:: src/views/tutorial/views.py @@ -111,18 +118,19 @@ a URL which represents the path to our "FrontPage". :linenos: :language: python -The ``view_wiki`` function returns an instance of the +``view_wiki()`` returns an instance of the :class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement the :class:`pyramid.interfaces.IResponse` interface like -:class:`pyramid.response.Response` does), It will use the -:meth:`pyramid.request.Request.route_url` API to construct a URL to the -``FrontPage`` page (e.g. ``http://localhost:6543/FrontPage``), and will use -it as the "location" of the HTTPFound response, forming an HTTP redirect. +:class:`pyramid.response.Response` does). + +It uses the :meth:`pyramid.request.Request.route_url` API to construct a +URL to the ``FrontPage`` page (e.g. ``http://localhost:6543/FrontPage``), which +is used as the "location" of the HTTPFound response, forming an HTTP redirect. The ``view_page`` view function ------------------------------- -The ``view_page`` function will be used to show a single page of our +``view_page()`` is used to display a single page of our wiki. It renders the :term:`ReStructuredText` body of a page (stored as the ``data`` attribute of a Page object) as HTML. Then it substitutes an HTML anchor for each *WikiWord* reference in the rendered HTML using a @@ -133,12 +141,12 @@ compiled regular expression. :linenos: :language: python -The curried function named ``check`` is used as the first argument to +The curried ``check()`` function is used as the first argument to ``wikiwords.sub``, indicating that it should be called to provide a value for each WikiWord match found in the content. If the wiki already contains a -page with the matched WikiWord name, the ``check`` function generates a view +page with the matched WikiWord name, ``check()`` generates a view link to be used as the substitution value and returns it. If the wiki does -not already contain a page with with the matched WikiWord name, the function +not already contain a page with with the matched WikiWord name, ``check()`` generates an "add" link as the substitution value and returns it. As a result, the ``content`` variable is now a fully formed bit of HTML @@ -147,8 +155,8 @@ 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 this view 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` +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 per the configuration put into effect in ``__init__.py``. @@ -156,11 +164,11 @@ template, as per the configuration put into effect in ``__init__.py``. The ``add_page`` view function ------------------------------ -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 +``add_page()`` is 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 ``matchdict`` attribute of the request passed to the ``add_page`` view +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. .. literalinclude:: src/views/tutorial/views.py @@ -193,7 +201,7 @@ newly created page. The ``edit_page`` view function ------------------------------- -The ``edit_page`` function will be invoked when a user clicks the "Edit this +``edit_page()`` is 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 ``matchdict`` attribute of the request passed to the ``edit_page`` view will have a ``'pagename'`` key @@ -258,7 +266,7 @@ and a submit button that has the name "form.submitted". The textarea in the form should be filled with any existing page data when it is rendered. Once we're done with the ``edit.pt`` template, it will look a lot like -the below: +the following: .. literalinclude:: src/views/tutorial/templates/edit.pt :language: xml -- cgit v1.2.3 From 03960030b5fb25cd1aa26068a10aa017dd4ef334 Mon Sep 17 00:00:00 2001 From: Audrey Roy Date: Tue, 13 Mar 2012 19:06:39 -0700 Subject: Wording improvements to Defining Views section of tutorial. --- docs/tutorials/wiki2/definingviews.rst | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 6d5ae7f6a..2c58a6ac4 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -38,9 +38,7 @@ Open ``tutorial/setup.py`` and edit it to look like the following: :language: python :emphasize-lines: 17 -(Only the highlighted line needs to be changed.) - -(Only the highlighted line needs to be added) +(Only the highlighted line needs to be added.) Running ``setup.py develop`` ============================ -- cgit v1.2.3 From 692fd6816616ed5b3cb9ef3c0f2c6eff2276da93 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Sat, 17 Mar 2012 00:05:06 -0400 Subject: master->1.3-branch --- docs/tutorials/wiki2/definingviews.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 2c58a6ac4..92f61c486 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -17,8 +17,8 @@ have a ``'one'`` key with the value ``'foo'`` and a ``'two'`` key with the value ``'bar'``. The source code for this tutorial stage can be browsed at -`http://github.com/Pylons/pyramid/tree/master/docs/tutorials/wiki2/src/views/ -`_. +`http://github.com/Pylons/pyramid/tree/1.3-branch/docs/tutorials/wiki2/src/views/ +`_. Declaring Dependencies in Our ``setup.py`` File =============================================== -- cgit v1.2.3 From b3e608bac815a7d3fc639d78ec38edc5f97df859 Mon Sep 17 00:00:00 2001 From: Doug Latornell Date: Sat, 17 Mar 2012 09:27:13 -0700 Subject: Improve text of SQLAlchemy wiki tutorial. A mixture of typo fixes and wording improvements. --- docs/tutorials/wiki2/definingviews.rst | 50 +++++++++++++++++++--------------- 1 file changed, 28 insertions(+), 22 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 2c58a6ac4..e1eb2cf1f 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -157,17 +157,19 @@ 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 per the configuration put into effect in ``__init__.py``. +template, as indicated in the ``@view_config`` decorator that is applied to +``view_page()``. The ``add_page`` view function ------------------------------ -``add_page()`` is 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 ``matchdict`` attribute of the request passed to the ``add_page()`` view -will have the values we need to construct URLs and find model objects. +``add_page()`` is 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. +``add_page()`` also acts as a handler for the form that is generated +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. .. literalinclude:: src/views/tutorial/views.py :lines: 45-56 @@ -179,17 +181,17 @@ the page we'd like to add. If our add view is invoked via, e.g. ``http://localhost:6543/add_page/SomeName``, the value for ``'pagename'`` in the ``matchdict`` will be ``'SomeName'``. -If the view execution is *not* a result of a form submission (if the +If the view execution is *not* a result of a form submission (i.e. the expression ``'form.submitted' in request.params`` is ``False``), the view callable renders a template. To do so, it generates a "save url" which the template uses as the form post URL during rendering. We're lazy here, so -we're trying to use the same template (``templates/edit.pt``) for the add -view as well as the page edit view, so we create a dummy Page object in order -to satisfy the edit form's desire to have *some* page object exposed as -``page``, and :app:`Pyramid` will render the template associated with this -view to a response. +we're going to use the same template (``templates/edit.pt``) for the add +view as well as the page edit view. To do so we create a dummy Page object +in order to satisfy the edit form's desire to have *some* page object +exposed as ``page``. :app:`Pyramid` will render the template associated +with this view to a response. -If the view execution *is* a result of a form submission (if the expression +If the view execution *is* a result of a form submission (i.e. the expression ``'form.submitted' in request.params`` is ``True``), we scrape the page body from the form data, create a Page object with this page body and the name taken from ``matchdict['pagename']``, and save it into the database using @@ -210,12 +212,12 @@ matching the name of the page the user wants to edit. :linenos: :language: python -If the view execution is *not* a result of a form submission (if the +If the view execution is *not* a result of a form submission (i.e. the expression ``'form.submitted' in request.params`` is ``False``), the view simply renders the edit form, passing the page object and a ``save_url`` which will be used as the action of the generated form. -If the view execution *is* a result of a form submission (if the expression +If the view execution *is* a result of a form submission (i.e. the expression ``'form.submitted' in request.params`` is ``True``), the view grabs the ``body`` element of the request parameters and sets it as the ``data`` attribute of the page object. It then redirects to the ``view_page`` view @@ -231,11 +233,12 @@ The views we've added all reference a :term:`template`. Each template is a The ``view.pt`` Template ------------------------ -The ``view.pt`` template is used for viewing a single wiki page. It is used -by the ``view_page`` view function. It should have a div that is "structure -replaced" with the ``content`` value provided by the view. It should also -have a link on the rendered page that points at the "edit" URL (the URL which -invokes the ``edit_page`` view for the page being viewed). +The ``view.pt`` template is used for viewing a single wiki page. It +is used by the ``view_page`` view function. It should have a ``div`` +that is "structure replaced" with the ``content`` value provided by +the view. It should also have a link on the rendered page that points +at the "edit" URL (the URL which invokes the ``edit_page`` view for +the page being viewed). Once we're done with the ``view.pt`` template, it will look a lot like the below: @@ -323,11 +326,14 @@ the order they're found in the ``__init__.py`` file. ``route_name='edit_page'``. As a result of our edits, the ``__init__.py`` file should look -something like so: +something like: .. literalinclude:: src/views/tutorial/__init__.py :linenos: :language: python + :emphasize-lines: 13-16 + +(The highlighted lines are the ones that need to be added or edited.) Viewing the Application in a Browser ==================================== -- cgit v1.2.3 From 8e7df02fb76a0ce965254141918d6c405bcaa264 Mon Sep 17 00:00:00 2001 From: Patricio Paez Date: Thu, 12 Apr 2012 21:51:42 -0500 Subject: Improve the Adding Templates section in both tutorials - As suggested by Paulo in the PyCon sprint --- docs/tutorials/wiki2/definingviews.rst | 66 +++++++++++++++++++--------------- 1 file changed, 38 insertions(+), 28 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index ac58e1e46..a2c8ba8c5 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -228,50 +228,60 @@ Adding Templates The views we've added all reference a :term:`template`. Each template is a :term:`Chameleon` :term:`ZPT` template. These templates will live in the -``templates`` directory of our tutorial package. +``templates`` directory of our tutorial package. Chameleon templates +must have a ``.pt`` extension to be recognized as such. The ``view.pt`` Template ------------------------ -The ``view.pt`` template is used for viewing a single wiki page. It -is used by the ``view_page`` view function. It should have a ``div`` -that is "structure replaced" with the ``content`` value provided by -the view. It should also have a link on the rendered page that points -at the "edit" URL (the URL which invokes the ``edit_page`` view for -the page being viewed). - -Once we're done with the ``view.pt`` template, it will look a lot like the -below: +Create ``tutorial/tutorial/templates/view.pt`` and add the following +content: .. literalinclude:: src/views/tutorial/templates/view.pt + :linenos: :language: xml -.. note:: The names available for our use in a template are always - those that are present in the dictionary returned by the view - callable. But our templates make use of a ``request`` object that - none of our tutorial views return in their dictionary. This value - appears as if "by magic". However, ``request`` is one of several - names that are available "by default" in a template when a template - renderer is used. See :ref:`chameleon_template_renderers` for more - information about other names that are available by default in a - template when a Chameleon template is used as a renderer. +This template is used by ``view_page()`` for displaying a single +wiki page. It includes: + +- A ``div`` element that is replaced with the ``content`` + value provided by the view (rows 45-47). ``content`` + contains HTML, so the ``structure`` keyword is used + to prevent escaping it (i.e. changing ">" to >, etc.) +- A link that points + at the "edit" URL which invokes the ``edit_page`` view for + the page being viewed (rows 49-51). The ``edit.pt`` Template ------------------------ -The ``edit.pt`` template is used for adding and editing a wiki page. It is -used by the ``add_page`` and ``edit_page`` view functions. It should display -a page containing a form that POSTs back to the "save_url" argument supplied -by the view. The form should have a "body" textarea field (the page data), -and a submit button that has the name "form.submitted". The textarea in the -form should be filled with any existing page data when it is rendered. - -Once we're done with the ``edit.pt`` template, it will look a lot like -the following: +Create ``tutorial/tutorial/templates/edit.pt`` and add the following +content: .. literalinclude:: src/views/tutorial/templates/edit.pt + :linenos: :language: xml +This template is used by ``add_page()`` and ``edit_page()`` for adding +and editing a wiki page. It displays +a page containing a form that includes: + +- A 10 row by 60 column ``textarea`` field named ``body`` that is filled + with any existing page data when it is rendered (rows 46-47). +- A submit button that has the name ``form.submitted`` (row 48). + +The form POSTs back to the "save_url" argument supplied +by the view (row 45). The view will use the ``body`` and +``form.submitted`` values. + +.. note:: Our templates use a ``request`` object that + none of our tutorial views return in their dictionary. + ``request`` is one of several + names that are available "by default" in a template when a template + renderer is used. See :ref:`chameleon_template_renderers` for + information about other names that are available by default + when a Chameleon template is used as a renderer. + Static Assets ------------- -- cgit v1.2.3 From f97aa6332c08d5edb35665a7afda2aefd98f662b Mon Sep 17 00:00:00 2001 From: Patricio Paez Date: Fri, 13 Apr 2012 13:10:00 -0500 Subject: Simplify the introduction - Moved the selection of the templates to the Design chapter - Improved the Views section in the Design chapter - Normalize in both tutorials --- docs/tutorials/wiki2/definingviews.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index a2c8ba8c5..84017ce5a 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -226,10 +226,11 @@ of the wiki page. Adding Templates ================ -The views we've added all reference a :term:`template`. Each template is a -:term:`Chameleon` :term:`ZPT` template. These templates will live in the -``templates`` directory of our tutorial package. Chameleon templates -must have a ``.pt`` extension to be recognized as such. +The ``view_page``, ``add_page`` and ``edit_page`` views that we've added +reference a :term:`template`. Each template is a :term:`Chameleon` :term:`ZPT` +template. These templates will live in the ``templates`` directory of our +tutorial package. Chameleon templates must have a ``.pt`` extension to be +recognized as such. The ``view.pt`` Template ------------------------ -- cgit v1.2.3 From 607524abda505e53a9851026e8e9d16de7b58053 Mon Sep 17 00:00:00 2001 From: Patricio Paez Date: Mon, 16 Apr 2012 19:21:22 -0500 Subject: Normalize and update the last section --- docs/tutorials/wiki2/definingviews.rst | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 84017ce5a..efb72230e 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -350,25 +350,24 @@ Viewing the Application in a Browser ==================================== We can finally examine our application in a browser (See -:ref:`wiki2-start-the-application`). The views we'll try are -as follows: +:ref:`wiki2-start-the-application`). Launch a browser and visit +each of the following URLs, check that the result is as expected: -- Visiting ``http://localhost:6543`` in a browser invokes the +- ``http://localhost:6543`` in a browser invokes the ``view_wiki`` view. This always redirects to the ``view_page`` view of the FrontPage page object. -- Visiting ``http://localhost:6543/FrontPage`` in a browser invokes +- ``http://localhost:6543/FrontPage`` in a browser invokes the ``view_page`` view of the front page page object. -- Visiting ``http://localhost:6543/FrontPage/edit_page`` in a browser +- ``http://localhost:6543/FrontPage/edit_page`` in a browser invokes the edit view for the front page object. -- Visiting ``http://localhost:6543/add_page/SomePageName`` in a +- ``http://localhost:6543/add_page/SomePageName`` in a browser invokes the add view for a page. -Try generating an error within the body of a view by adding code to -the top of it that generates an exception (e.g. ``raise -Exception('Forced Exception')``). Then visit the error-raising view -in a browser. You should see an interactive exception handler in the -browser which allows you to examine values in a post-mortem mode. +- To generate an error, visit ``http://localhost:6543/add_page`` which + will generate a ``NoResultFound: No row was found for one()`` error. + You'll see an interactive traceback facility provided + by :term:`pyramid_debugtoolbar`. -- cgit v1.2.3 From 1d627da85d8b7603b28f276be482f9cb4ec79dae Mon Sep 17 00:00:00 2001 From: Daniel Haaker Date: Sat, 4 Aug 2012 21:54:44 +0200 Subject: add quotes for clarity --- docs/tutorials/wiki2/definingviews.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index efb72230e..24ac4338d 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -248,7 +248,7 @@ wiki page. It includes: - A ``div`` element that is replaced with the ``content`` value provided by the view (rows 45-47). ``content`` contains HTML, so the ``structure`` keyword is used - to prevent escaping it (i.e. changing ">" to >, etc.) + to prevent escaping it (i.e. changing ">" to ">", etc.) - A link that points at the "edit" URL which invokes the ``edit_page`` view for the page being viewed (rows 49-51). -- cgit v1.2.3 From 098599b497fb6cd7c9372ceb795e9e8a416d573e Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Sat, 22 Sep 2012 10:04:14 -0400 Subject: - Add ``Base.metadata.bind = engine`` to alchemy template, so that tables defined imperatively will work. - update wiki2 SQLA tutorial with the changes required after inserting ``Base.metadata.bind = engine`` into the alchemy scaffold. --- docs/tutorials/wiki2/definingviews.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 24ac4338d..a54996e3c 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -342,7 +342,7 @@ something like: .. literalinclude:: src/views/tutorial/__init__.py :linenos: :language: python - :emphasize-lines: 13-16 + :emphasize-lines: 17-20 (The highlighted lines are the ones that need to be added or edited.) -- cgit v1.2.3 From b9b2ee39c251dd68a12e717e1f6d9d02a29efe9a Mon Sep 17 00:00:00 2001 From: Marc Abramowitz Date: Fri, 30 Nov 2012 09:27:09 -0800 Subject: A bunch of minor tweaks to the wiki2 tutorial in docs/tutorials/wiki2 --- docs/tutorials/wiki2/definingviews.rst | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index a54996e3c..c23ca947d 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -26,7 +26,7 @@ Declaring Dependencies in Our ``setup.py`` File The view code in our application will depend on a package which is not a dependency of the original "tutorial" application. The original "tutorial" application was generated by the ``pcreate`` command; it doesn't know -about our custom application requirements. +about our custom application requirements. We need to add a dependency on the ``docutils`` package to our ``tutorial`` package's ``setup.py`` file by assigning this dependency to the ``requires`` parameter in ``setup()``. @@ -123,14 +123,14 @@ the :class:`pyramid.interfaces.IResponse` interface like It uses the :meth:`pyramid.request.Request.route_url` API to construct a URL to the ``FrontPage`` page (e.g. ``http://localhost:6543/FrontPage``), which -is used as the "location" of the HTTPFound response, forming an HTTP redirect. +is used as the "location" of the ``HTTPFound`` response, forming an HTTP redirect. The ``view_page`` view function ------------------------------- ``view_page()`` is used to display a single page of our wiki. It renders the :term:`ReStructuredText` body of a page (stored as -the ``data`` attribute of a Page object) as HTML. Then it substitutes an +the ``data`` attribute of a ``Page`` model object) as HTML. Then it substitutes an HTML anchor for each *WikiWord* reference in the rendered HTML using a compiled regular expression. @@ -139,7 +139,7 @@ compiled regular expression. :linenos: :language: python -The curried ``check()`` function is used as the first argument to +The ``check()`` function is used as the first argument to ``wikiwords.sub``, indicating that it should be called to provide a value for each WikiWord match found in the content. If the wiki already contains a page with the matched WikiWord name, ``check()`` generates a view @@ -181,6 +181,13 @@ the page we'd like to add. If our add view is invoked via, e.g. ``http://localhost:6543/add_page/SomeName``, the value for ``'pagename'`` in the ``matchdict`` will be ``'SomeName'``. +If the view execution *is* a result of a form submission (i.e. the expression +``'form.submitted' in request.params`` is ``True``), we scrape the page body +from the form data, create a Page object with this page body and the name +taken from ``matchdict['pagename']``, and save it into the database using +``DBSession.add``. We then redirect back to the ``view_page`` view for the +newly created page. + If the view execution is *not* a result of a form submission (i.e. the expression ``'form.submitted' in request.params`` is ``False``), the view callable renders a template. To do so, it generates a "save url" which the @@ -191,13 +198,6 @@ in order to satisfy the edit form's desire to have *some* page object exposed as ``page``. :app:`Pyramid` will render the template associated with this view to a response. -If the view execution *is* a result of a form submission (i.e. the expression -``'form.submitted' in request.params`` is ``True``), we scrape the page body -from the form data, create a Page object with this page body and the name -taken from ``matchdict['pagename']``, and save it into the database using -``DBSession.add``. We then redirect back to the ``view_page`` view for the -newly created page. - The ``edit_page`` view function ------------------------------- @@ -212,17 +212,17 @@ matching the name of the page the user wants to edit. :linenos: :language: python -If the view execution is *not* a result of a form submission (i.e. the -expression ``'form.submitted' in request.params`` is ``False``), the view -simply renders the edit form, passing the page object and a ``save_url`` -which will be used as the action of the generated form. - If the view execution *is* a result of a form submission (i.e. the expression ``'form.submitted' in request.params`` is ``True``), the view grabs the ``body`` element of the request parameters and sets it as the ``data`` attribute of the page object. It then redirects to the ``view_page`` view of the wiki page. +If the view execution is *not* a result of a form submission (i.e. the +expression ``'form.submitted' in request.params`` is ``False``), the view +simply renders the edit form, passing the page object and a ``save_url`` +which will be used as the action of the generated form. + Adding Templates ================ -- cgit v1.2.3 From 9223b3cbff80328431e3711eba2a317bb206286e Mon Sep 17 00:00:00 2001 From: Marc Abramowitz Date: Fri, 30 Nov 2012 09:44:25 -0800 Subject: tutorials/wiki2/definingviews.rst: Change example error page from http://localhost:6543/add_page to http://localhost:6543/foobar/edit_page For me, the former generates "404 Not Found" (probably because it doesn't match a route) while the latter gives "sqlalchemy.orm.exc.NoResultFound" and the nice traceback from Werkzeug. --- docs/tutorials/wiki2/definingviews.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index c23ca947d..538b94216 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -366,7 +366,7 @@ each of the following URLs, check that the result is as expected: - ``http://localhost:6543/add_page/SomePageName`` in a browser invokes the add view for a page. -- To generate an error, visit ``http://localhost:6543/add_page`` which +- To generate an error, visit ``http://localhost:6543/foobars/edit_page`` which will generate a ``NoResultFound: No row was found for one()`` error. You'll see an interactive traceback facility provided by :term:`pyramid_debugtoolbar`. -- cgit v1.2.3 From e90fa43a8051dfc8799596e17b72fd3d3def6516 Mon Sep 17 00:00:00 2001 From: Patricio Paez Date: Sat, 1 Dec 2012 19:43:02 -0600 Subject: Sync __init__.py in SQL wiki tutorial - Update lines and emphasized-lines - No line numbers if only a single line --- docs/tutorials/wiki2/definingviews.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index a54996e3c..d6a31edbb 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -342,7 +342,7 @@ something like: .. literalinclude:: src/views/tutorial/__init__.py :linenos: :language: python - :emphasize-lines: 17-20 + :emphasize-lines: 18-21 (The highlighted lines are the ones that need to be added or edited.) -- cgit v1.2.3 From 043ccddb909327106264d10ed5d413760a51770d Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 2 Jan 2013 02:22:52 +0200 Subject: eliminate other repeated words --- docs/tutorials/wiki2/definingviews.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 6b8689b5b..8714927c3 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -144,7 +144,7 @@ The ``check()`` function is used as the first argument to each WikiWord match found in the content. If the wiki already contains a page with the matched WikiWord name, ``check()`` generates a view link to be used as the substitution value and returns it. If the wiki does -not already contain a page with with the matched WikiWord name, ``check()`` +not already contain a page with the matched WikiWord name, ``check()`` generates an "add" link as the substitution value and returns it. As a result, the ``content`` variable is now a fully formed bit of HTML @@ -358,7 +358,7 @@ each of the following URLs, check that the result is as expected: of the FrontPage page object. - ``http://localhost:6543/FrontPage`` in a browser invokes - the ``view_page`` view of the front page page object. + the ``view_page`` view of the front page object. - ``http://localhost:6543/FrontPage/edit_page`` in a browser invokes the edit view for the front page object. -- cgit v1.2.3 From 445eb8708fa48209947377f6de609799dd843ad6 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sun, 20 Jan 2013 17:10:40 +0200 Subject: point to the sources of the wiki tutorials in just one location; fix #763 * This avoids having to update the link multiple times. * Also, mention their location, in case user has Pyramid checkout. --- docs/tutorials/wiki2/definingviews.rst | 3 --- 1 file changed, 3 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 8714927c3..e83a88198 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -16,9 +16,6 @@ instance, if a call to :meth:`pyramid.config.Configurator.add_route` in have a ``'one'`` key with the value ``'foo'`` and a ``'two'`` key with the value ``'bar'``. -The source code for this tutorial stage can be browsed at -`http://github.com/Pylons/pyramid/tree/1.3-branch/docs/tutorials/wiki2/src/views/ -`_. Declaring Dependencies in Our ``setup.py`` File =============================================== -- cgit v1.2.3 From eb3cee262ef52480198fc7f506debe0f35e3554a Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 4 Mar 2013 22:30:32 +0200 Subject: fix #311 --- docs/tutorials/wiki2/definingviews.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index e83a88198..0e95ca1c1 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -33,7 +33,7 @@ Open ``tutorial/setup.py`` and edit it to look like the following: .. literalinclude:: src/views/setup.py :linenos: :language: python - :emphasize-lines: 17 + :emphasize-lines: 19 (Only the highlighted line needs to be added.) -- cgit v1.2.3 From cd8ac801ac1ccefb81c2e015124be910cb8c93de Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 15 Feb 2013 00:48:08 +0200 Subject: update some links and fix others --- docs/tutorials/wiki2/definingviews.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 0e95ca1c1..9d2f8fb7f 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -287,7 +287,7 @@ Our templates name a single static asset named ``pylons.css``. We don't need to create this file within our package's ``static`` directory because it was provided at the time we created the project. This file is a little too long to replicate within the body of this guide, however it is available `online -`_. +`_. This CSS file will be accessed via e.g. ``http://localhost:6543/static/pylons.css`` by virtue of the call to -- cgit v1.2.3 From f73f0e332658fac2583f51247dcd49bd36d63ce4 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 13 Mar 2013 23:05:17 +0200 Subject: consistency: use $VENV whenever virtualenv binaries are used --- docs/tutorials/wiki2/definingviews.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 9d2f8fb7f..5727816c8 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -52,14 +52,14 @@ On UNIX: .. code-block:: text $ cd tutorial - $ ../bin/python setup.py develop + $ $VENV/bin/python setup.py develop On Windows: .. code-block:: text c:\pyramidtut> cd tutorial - c:\pyramidtut\tutorial> ..\Scripts\python setup.py develop + c:\pyramidtut\tutorial> %VENV%\Scripts\python setup.py develop Success executing this command will end with a line to the console something like:: -- cgit v1.2.3 From f39d8bf14b163e251b5c6eac88f07f862fd007b0 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sun, 17 Mar 2013 14:32:08 +0200 Subject: that should be lower-case --- docs/tutorials/wiki2/definingviews.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 5727816c8..f2ac2f85f 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -126,7 +126,7 @@ The ``view_page`` view function ------------------------------- ``view_page()`` is used to display a single page of our -wiki. It renders the :term:`ReStructuredText` body of a page (stored as +wiki. It renders the :term:`reStructuredText` body of a page (stored as the ``data`` attribute of a ``Page`` model object) as HTML. Then it substitutes an HTML anchor for each *WikiWord* reference in the rendered HTML using a compiled regular expression. -- cgit v1.2.3 From b1611cf0d24e2947ebfb58071ff7c695a1d824cc Mon Sep 17 00:00:00 2001 From: Patrick Canfield Date: Mon, 18 Mar 2013 13:05:41 -0700 Subject: Update definingviews.rst explain matchdict more explicitly, concisely --- docs/tutorials/wiki2/definingviews.rst | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index f2ac2f85f..72cba8d1e 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -6,14 +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 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 +The request object has 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` 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'``. -- cgit v1.2.3 From b4eeddf672987c8f03058f5bf0d4f7080007b0e2 Mon Sep 17 00:00:00 2001 From: Patrick Canfield Date: Mon, 18 Mar 2013 14:12:23 -0700 Subject: Update definingviews.rst to be more explicit, concise (?) A make the first sentence a litte more explicit, default to present tense, remove unnecessary details and use python instead of english when it's cleared to do so. --- docs/tutorials/wiki2/definingviews.rst | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 72cba8d1e..9df72c926 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -6,14 +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 has 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` 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 the URL at ``http://example.com/foo/bar`` is invoked, matching +this pattern, the ``matchdict`` attached to the request would look like: ``{'one':'foo', 'two':'bar'}`` Declaring Dependencies in Our ``setup.py`` File -- cgit v1.2.3 From e163c0931e17c3ad79dd0fa08cea924db1813558 Mon Sep 17 00:00:00 2001 From: Patrick Canfield Date: Mon, 18 Mar 2013 14:16:57 -0700 Subject: Update definingviews.rst to use active voice, reduce redundancy. --- docs/tutorials/wiki2/definingviews.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 9df72c926..f733abe10 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -10,8 +10,8 @@ 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 the URL at ``http://example.com/foo/bar`` is invoked, matching -this pattern, the ``matchdict`` attached to the request would look like: ``{'one':'foo', 'two':'bar'}`` +``{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 -- cgit v1.2.3 From bb8e20e0d35dc806e19edc6d07c837ec272128ec Mon Sep 17 00:00:00 2001 From: Patrick Canfield Date: Mon, 18 Mar 2013 17:24:51 -0700 Subject: Update definingviews.rst to clarify that a template is a renderer --- docs/tutorials/wiki2/definingviews.rst | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index f733abe10..9894bcb08 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -149,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 ------------------------------ -- cgit v1.2.3 From e7b21013bab17d5eccdc60f6125cc898996021cf Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Sat, 23 Mar 2013 03:12:42 -0400 Subject: change some slightly awkward wording --- docs/tutorials/wiki2/definingviews.rst | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') 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 ------------------------------ -- cgit v1.2.3 From 2fe90368e99aedded9177ec222020f6fef81ffed Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sun, 24 Mar 2013 12:07:59 +0200 Subject: make example links clickable, for convenience --- docs/tutorials/wiki2/definingviews.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 53f8e569c..a1e2313f3 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -346,20 +346,20 @@ We can finally examine our application in a browser (See :ref:`wiki2-start-the-application`). Launch a browser and visit each of the following URLs, check that the result is as expected: -- ``http://localhost:6543`` in a browser invokes the +- http://localhost:6543 in a browser invokes the ``view_wiki`` view. This always redirects to the ``view_page`` view of the FrontPage page object. -- ``http://localhost:6543/FrontPage`` in a browser invokes +- http://localhost:6543/FrontPage in a browser invokes the ``view_page`` view of the front page object. -- ``http://localhost:6543/FrontPage/edit_page`` in a browser +- http://localhost:6543/FrontPage/edit_page in a browser invokes the edit view for the front page object. -- ``http://localhost:6543/add_page/SomePageName`` in a +- http://localhost:6543/add_page/SomePageName in a browser invokes the add view for a page. -- To generate an error, visit ``http://localhost:6543/foobars/edit_page`` which +- To generate an error, visit http://localhost:6543/foobars/edit_page which will generate a ``NoResultFound: No row was found for one()`` error. You'll see an interactive traceback facility provided by :term:`pyramid_debugtoolbar`. -- cgit v1.2.3 From 404b28ba2efb02d93777a3e01fd602c96af8c077 Mon Sep 17 00:00:00 2001 From: Michael Merickel Date: Fri, 6 Sep 2013 00:02:46 -0500 Subject: update the code in the wiki and wiki2 tutorials to use pyramid_chameleon --- docs/tutorials/wiki2/definingviews.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index a1e2313f3..ea49d4733 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -30,7 +30,7 @@ Open ``tutorial/setup.py`` and edit it to look like the following: .. literalinclude:: src/views/setup.py :linenos: :language: python - :emphasize-lines: 19 + :emphasize-lines: 20 (Only the highlighted line needs to be added.) @@ -335,7 +335,7 @@ something like: .. literalinclude:: src/views/tutorial/__init__.py :linenos: :language: python - :emphasize-lines: 18-21 + :emphasize-lines: 19-22 (The highlighted lines are the ones that need to be added or edited.) -- cgit v1.2.3 From 70784a80c07cc831ab20c2e22e82b14afe834feb Mon Sep 17 00:00:00 2001 From: Michael Merickel Date: Fri, 6 Sep 2013 00:38:30 -0500 Subject: fix some more broken references --- docs/tutorials/wiki2/definingviews.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index ea49d4733..49dbed50f 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -272,9 +272,9 @@ by the view (row 45). The view will use the ``body`` and none of our tutorial views return in their dictionary. ``request`` is one of several names that are available "by default" in a template when a template - renderer is used. See :ref:`chameleon_template_renderers` for + renderer is used. See :ref:`renderer_system_values` for information about other names that are available by default - when a Chameleon template is used as a renderer. + when a template is used as a renderer. Static Assets ------------- -- cgit v1.2.3 From ee9676a8691dd18b88d3247fd8c1306c5aaa1543 Mon Sep 17 00:00:00 2001 From: Steve Piercy Date: Sun, 24 May 2015 19:15:22 -0700 Subject: - make templates html5 compliant - punctuation, grammar, spelling - fix linenos references - update outputs --- docs/tutorials/wiki2/definingviews.rst | 46 +++++++++++++++++----------------- 1 file changed, 23 insertions(+), 23 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 49dbed50f..dd1cb491d 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -11,8 +11,8 @@ The request object has a dictionary as an attribute named ``matchdict``. A 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'}`` +against ``/foo/bar`` and the ``matchdict`` would look like ``{'one':'foo', +'two':'bar'}``. Declaring Dependencies in Our ``setup.py`` File =============================================== @@ -32,7 +32,7 @@ Open ``tutorial/setup.py`` and edit it to look like the following: :language: python :emphasize-lines: 20 -(Only the highlighted line needs to be added.) +Only the highlighted line needs to be added. Running ``setup.py develop`` ============================ @@ -71,9 +71,9 @@ It's time for a major change. Open ``tutorial/tutorial/views.py`` and edit it t .. literalinclude:: src/views/tutorial/views.py :linenos: :language: python - :emphasize-lines: 1-7,12,15-70 + :emphasize-lines: 1-7,14,16-72 -(The highlighted lines are the ones that need to be added or edited.) +The highlighted lines are the ones that need to be added or edited. We got rid of the ``my_view`` view function and its decorator that was added when we originally rendered the ``alchemy`` scaffold. It was only an @@ -93,7 +93,7 @@ afterward. .. note:: There is nothing special about the filename ``views.py``. A project may - have many view callables throughout its codebase in arbitrarily-named + have many view callables throughout its codebase in arbitrarily named files. Files implementing view callables often have ``view`` in their filenames (or may live in a Python subpackage of your application package named ``views``), but this is only by convention. @@ -106,7 +106,7 @@ is made to the root URL of our wiki. It always redirects to a URL which represents the path to our "FrontPage". .. literalinclude:: src/views/tutorial/views.py - :lines: 18-21 + :lines: 20-23 :linenos: :language: python @@ -116,8 +116,8 @@ the :class:`pyramid.interfaces.IResponse` interface like :class:`pyramid.response.Response` does). It uses the :meth:`pyramid.request.Request.route_url` API to construct a -URL to the ``FrontPage`` page (e.g. ``http://localhost:6543/FrontPage``), which -is used as the "location" of the ``HTTPFound`` response, forming an HTTP redirect. +URL to the ``FrontPage`` page (e.g., ``http://localhost:6543/FrontPage``), which +is used as the location of the ``HTTPFound`` response, forming an HTTP redirect. The ``view_page`` view function ------------------------------- @@ -165,25 +165,25 @@ request passed to the ``add_page()`` view will have the values we need to construct URLs and find model objects. .. literalinclude:: src/views/tutorial/views.py - :lines: 45-56 + :lines: 47-58 :linenos: :language: python 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 value for +e.g., ``http://localhost:6543/add_page/SomeName``, the value for ``'pagename'`` in the ``matchdict`` will be ``'SomeName'``. -If the view execution *is* a result of a form submission (i.e. the expression -``'form.submitted' in request.params`` is ``True``), we scrape the page body +If the view execution *is* a result of a form submission (i.e., the expression +``'form.submitted' in request.params`` is ``True``), we grab the page body from the form data, create a Page object with this page body and the name taken from ``matchdict['pagename']``, and save it into the database using ``DBSession.add``. We then redirect back to the ``view_page`` view for the newly created page. -If the view execution is *not* a result of a form submission (i.e. the +If the view execution is *not* a result of a form submission (i.e., the expression ``'form.submitted' in request.params`` is ``False``), the view -callable renders a template. To do so, it generates a "save url" which the +callable renders a template. To do so, it generates a ``save_url`` which the template uses as the form post URL during rendering. We're lazy here, so we're going to use the same template (``templates/edit.pt``) for the add view as well as the page edit view. To do so we create a dummy Page object @@ -201,17 +201,17 @@ request passed to the ``edit_page`` view will have a ``'pagename'`` key matching the name of the page the user wants to edit. .. literalinclude:: src/views/tutorial/views.py - :lines: 58-70 + :lines: 60-72 :linenos: :language: python -If the view execution *is* a result of a form submission (i.e. the expression +If the view execution *is* a result of a form submission (i.e., the expression ``'form.submitted' in request.params`` is ``True``), the view grabs the ``body`` element of the request parameters and sets it as the ``data`` attribute of the page object. It then redirects to the ``view_page`` view of the wiki page. -If the view execution is *not* a result of a form submission (i.e. the +If the view execution is *not* a result of a form submission (i.e., the expression ``'form.submitted' in request.params`` is ``False``), the view simply renders the edit form, passing the page object and a ``save_url`` which will be used as the action of the generated form. @@ -239,12 +239,12 @@ This template is used by ``view_page()`` for displaying a single wiki page. It includes: - A ``div`` element that is replaced with the ``content`` - value provided by the view (rows 45-47). ``content`` + value provided by the view (lines 43-45). ``content`` contains HTML, so the ``structure`` keyword is used - to prevent escaping it (i.e. changing ">" to ">", etc.) + to prevent escaping it (i.e., changing ">" to ">", etc.) - A link that points at the "edit" URL which invokes the ``edit_page`` view for - the page being viewed (rows 49-51). + the page being viewed (lines 47-49). The ``edit.pt`` Template ------------------------ @@ -254,7 +254,7 @@ content: .. literalinclude:: src/views/tutorial/templates/edit.pt :linenos: - :language: xml + :language: html This template is used by ``add_page()`` and ``edit_page()`` for adding and editing a wiki page. It displays @@ -265,7 +265,7 @@ a page containing a form that includes: - A submit button that has the name ``form.submitted`` (row 48). The form POSTs back to the "save_url" argument supplied -by the view (row 45). The view will use the ``body`` and +by the view (row 43). The view will use the ``body`` and ``form.submitted`` values. .. note:: Our templates use a ``request`` object that -- cgit v1.2.3 From 735ad19201108e9598aff81a890b206c901493ed Mon Sep 17 00:00:00 2001 From: Steve Piercy Date: Sun, 24 May 2015 22:44:53 -0700 Subject: grammar, punctuation, line number fixes --- docs/tutorials/wiki2/definingviews.rst | 37 ++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 17 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index dd1cb491d..9a684fe3e 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -106,7 +106,8 @@ is made to the root URL of our wiki. It always redirects to a URL which represents the path to our "FrontPage". .. literalinclude:: src/views/tutorial/views.py - :lines: 20-23 + :lines: 20-24 + :lineno-start: 20 :linenos: :language: python @@ -129,7 +130,8 @@ HTML anchor for each *WikiWord* reference in the rendered HTML using a compiled regular expression. .. literalinclude:: src/views/tutorial/views.py - :lines: 23-43 + :lines: 25-45 + :lineno-start: 25 :linenos: :language: python @@ -166,6 +168,7 @@ to construct URLs and find model objects. .. literalinclude:: src/views/tutorial/views.py :lines: 47-58 + :lineno-start: 47 :linenos: :language: python @@ -202,6 +205,7 @@ matching the name of the page the user wants to edit. .. literalinclude:: src/views/tutorial/views.py :lines: 60-72 + :lineno-start: 60 :linenos: :language: python @@ -233,18 +237,18 @@ content: .. literalinclude:: src/views/tutorial/templates/view.pt :linenos: - :language: xml + :language: html This template is used by ``view_page()`` for displaying a single wiki page. It includes: - A ``div`` element that is replaced with the ``content`` - value provided by the view (lines 43-45). ``content`` + value provided by the view (lines 36-38). ``content`` contains HTML, so the ``structure`` keyword is used to prevent escaping it (i.e., changing ">" to ">", etc.) - A link that points at the "edit" URL which invokes the ``edit_page`` view for - the page being viewed (lines 47-49). + the page being viewed (lines 40-42). The ``edit.pt`` Template ------------------------ @@ -257,15 +261,14 @@ content: :language: html This template is used by ``add_page()`` and ``edit_page()`` for adding -and editing a wiki page. It displays -a page containing a form that includes: +and editing a wiki page. It displays a page containing a form that includes: - A 10 row by 60 column ``textarea`` field named ``body`` that is filled - with any existing page data when it is rendered (rows 46-47). -- A submit button that has the name ``form.submitted`` (row 48). + with any existing page data when it is rendered (line 45). +- A submit button that has the name ``form.submitted`` (line 48). -The form POSTs back to the "save_url" argument supplied -by the view (row 43). The view will use the ``body`` and +The form POSTs back to the ``save_url`` argument supplied +by the view (line 43). The view will use the ``body`` and ``form.submitted`` values. .. note:: Our templates use a ``request`` object that @@ -286,12 +289,12 @@ to replicate within the body of this guide, however it is available `online `_. This CSS file will be accessed via -e.g. ``http://localhost:6543/static/pylons.css`` by virtue of the call to +``http://localhost:6543/static/pylons.css`` by virtue of the call to the ``add_static_view`` directive we've made in the ``__init__.py`` file. Any number and type of static assets can be placed in this directory (or subdirectories) and are just referred to by URL or by using the convenience -method ``static_url`` -e.g. ``request.static_url('{{package}}:static/foo.css')`` within templates. +method ``static_url``, e.g., +``request.static_url(':static/foo.css')`` within templates. Adding Routes to ``__init__.py`` ================================ @@ -334,17 +337,17 @@ something like: .. literalinclude:: src/views/tutorial/__init__.py :linenos: - :language: python :emphasize-lines: 19-22 + :language: python -(The highlighted lines are the ones that need to be added or edited.) +The highlighted lines are the ones that need to be added or edited. Viewing the Application in a Browser ==================================== We can finally examine our application in a browser (See :ref:`wiki2-start-the-application`). Launch a browser and visit -each of the following URLs, check that the result is as expected: +each of the following URLs, checking that the result is as expected: - http://localhost:6543 in a browser invokes the ``view_wiki`` view. This always redirects to the ``view_page`` view -- cgit v1.2.3 From 492f6945b2be2874a97071a93fd786c28515efa6 Mon Sep 17 00:00:00 2001 From: Steve Piercy Date: Mon, 25 May 2015 00:09:57 -0700 Subject: update templates and static assets for each step --- docs/tutorials/wiki2/definingviews.rst | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 9a684fe3e..0981af268 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -282,14 +282,12 @@ by the view (line 43). The view will use the ``body`` and Static Assets ------------- -Our templates name a single static asset named ``pylons.css``. We don't need -to create this file within our package's ``static`` directory because it was -provided at the time we created the project. This file is a little too long -to replicate within the body of this guide, however it is available `online -`_. - -This CSS file will be accessed via -``http://localhost:6543/static/pylons.css`` by virtue of the call to the +Our templates name static assets, including CSS and images. We don't need +to create these files within our package's ``static`` directory because they +were provided at the time we created the project. + +As an example, the CSS file will be accessed via +``http://localhost:6543/static/theme.css`` by virtue of the call to the ``add_static_view`` directive we've made in the ``__init__.py`` file. Any number and type of static assets can be placed in this directory (or subdirectories) and are just referred to by URL or by using the convenience -- cgit v1.2.3 From a940e1ccaa6c3ca81b1dec6ba2e505af9b792222 Mon Sep 17 00:00:00 2001 From: Steve Piercy Date: Tue, 26 May 2015 13:12:01 -0700 Subject: - clean up and make defininingviews consistent between two wiki tutorials - sort imports to be consistent with scaffold setup.py - update templates, static assets --- docs/tutorials/wiki2/definingviews.rst | 163 +++++++++++++++++---------------- 1 file changed, 83 insertions(+), 80 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 0981af268..d7f63100d 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -23,26 +23,27 @@ application was generated by the ``pcreate`` command; it doesn't know about our custom application requirements. We need to add a dependency on the ``docutils`` package to our ``tutorial`` -package's ``setup.py`` file by assigning this dependency to the ``requires`` parameter in ``setup()``. +package's ``setup.py`` file by assigning this dependency to the ``requires`` +parameter in the ``setup()`` function. Open ``tutorial/setup.py`` and edit it to look like the following: .. literalinclude:: src/views/setup.py :linenos: - :language: python :emphasize-lines: 20 + :language: python Only the highlighted line needs to be added. Running ``setup.py develop`` ============================ -Since a new software dependency was added, you will need to rerun ``python -setup.py develop`` inside the root of the ``tutorial`` package to obtain and -register the newly added dependency distribution. +Since a new software dependency was added, you will need to run ``python +setup.py develop`` again inside the root of the ``tutorial`` package to obtain +and register the newly added dependency distribution. Make sure your current working directory is the root of the project (the -directory in which setup.py lives) and execute the following command. +directory in which ``setup.py`` lives) and execute the following command. On UNIX: @@ -63,21 +64,24 @@ like:: Finished processing dependencies for tutorial==0.0 -Changing the ``views.py`` File -============================== +Adding view functions in ``views.py`` +===================================== -It's time for a major change. Open ``tutorial/tutorial/views.py`` and edit it to look like the following: +It's time for a major change. Open ``tutorial/tutorial/views.py`` and edit it +to look like the following: .. literalinclude:: src/views/tutorial/views.py :linenos: :language: python :emphasize-lines: 1-7,14,16-72 -The highlighted lines are the ones that need to be added or edited. +The highlighted lines need to be added or edited. + +We added some imports and created a regular expression to find "WikiWords". -We got rid of the ``my_view`` view function and its decorator that was -added when we originally rendered the ``alchemy`` scaffold. It was only an -example and isn't relevant to our application. +We got rid of the ``my_view`` view function and its decorator that was added +when we originally rendered the ``alchemy`` scaffold. It was only an example +and isn't relevant to our application. Then we added four :term:`view callable` functions to our ``views.py`` module: @@ -87,8 +91,7 @@ module: * ``add_page()`` - Allows the user to add a page. * ``edit_page()`` - Allows the user to edit a page. -We'll describe each one briefly and show the resulting ``views.py`` file -afterward. +We'll describe each one briefly in the following sections. .. note:: @@ -101,9 +104,7 @@ afterward. The ``view_wiki`` view function ------------------------------- -``view_wiki()`` is the :term:`default view` that gets called when a request -is made to the root URL of our wiki. It always redirects to -a URL which represents the path to our "FrontPage". +Following is the code for the ``view_wiki`` view function and its decorator: .. literalinclude:: src/views/tutorial/views.py :lines: 20-24 @@ -111,23 +112,23 @@ a URL which represents the path to our "FrontPage". :linenos: :language: python -``view_wiki()`` returns an instance of the -:class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement -the :class:`pyramid.interfaces.IResponse` interface like -:class:`pyramid.response.Response` does). +``view_wiki()`` is the :term:`default view` that gets called when a request is +made to the root URL of our wiki. It always redirects to an URL which +represents the path to our "FrontPage". -It uses the :meth:`pyramid.request.Request.route_url` API to construct a -URL to the ``FrontPage`` page (e.g., ``http://localhost:6543/FrontPage``), which -is used as the location of the ``HTTPFound`` response, forming an HTTP redirect. +The ``view_wiki`` view callable always redirects to the URL of a Page resource +named "FrontPage". To do so, it returns an instance of the +:class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement +the :class:`pyramid.interfaces.IResponse` interface, like +:class:`pyramid.response.Response` does). It uses the +:meth:`pyramid.request.Request.route_url` API to construct an URL to the +``FrontPage`` page (i.e., ``http://localhost:6543/FrontPage``), and uses it as +the "location" of the ``HTTPFound`` response, forming an HTTP redirect. The ``view_page`` view function ------------------------------- -``view_page()`` is used to display a single page of our -wiki. It renders the :term:`reStructuredText` body of a page (stored as -the ``data`` attribute of a ``Page`` model object) as HTML. Then it substitutes an -HTML anchor for each *WikiWord* reference in the rendered HTML using a -compiled regular expression. +Here is the code for the ``view_page`` view function and its decorator: .. literalinclude:: src/views/tutorial/views.py :lines: 25-45 @@ -135,7 +136,12 @@ compiled regular expression. :linenos: :language: python -The ``check()`` function is used as the first argument to +``view_page()`` is used to display a single page of our wiki. It renders the +:term:`reStructuredText` body of a page (stored as the ``data`` attribute of a +``Page`` model object) as HTML. Then it substitutes an HTML anchor for each +*WikiWord* reference in the rendered HTML using a compiled regular expression. + +The curried function named ``check`` is used as the first argument to ``wikiwords.sub``, indicating that it should be called to provide a value for each WikiWord match found in the content. If the wiki already contains a page with the matched WikiWord name, ``check()`` generates a view @@ -158,6 +164,14 @@ renderer used will be the ``templates/view.pt`` template, as indicated in the The ``add_page`` view function ------------------------------ +Here is the code for the ``add_page`` view function and its decorator: + +.. literalinclude:: src/views/tutorial/views.py + :lines: 47-58 + :lineno-start: 47 + :linenos: + :language: python + ``add_page()`` is 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. @@ -166,12 +180,6 @@ 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. -.. literalinclude:: src/views/tutorial/views.py - :lines: 47-58 - :lineno-start: 47 - :linenos: - :language: python - 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 value for @@ -197,11 +205,7 @@ with this view to a response. The ``edit_page`` view function ------------------------------- -``edit_page()`` is 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 ``matchdict`` attribute of the -request passed to the ``edit_page`` view will have a ``'pagename'`` key -matching the name of the page the user wants to edit. +Here is the code for the ``edit_page`` view function and its decorator: .. literalinclude:: src/views/tutorial/views.py :lines: 60-72 @@ -209,6 +213,12 @@ matching the name of the page the user wants to edit. :linenos: :language: python +``edit_page()`` is 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 ``matchdict`` attribute of the +request passed to the ``edit_page`` view will have a ``'pagename'`` key +matching the name of the page the user wants to edit. + If the view execution *is* a result of a form submission (i.e., the expression ``'form.submitted' in request.params`` is ``True``), the view grabs the ``body`` element of the request parameters and sets it as the ``data`` @@ -220,16 +230,16 @@ expression ``'form.submitted' in request.params`` is ``False``), the view simply renders the edit form, passing the page object and a ``save_url`` which will be used as the action of the generated form. -Adding Templates +Adding templates ================ The ``view_page``, ``add_page`` and ``edit_page`` views that we've added -reference a :term:`template`. Each template is a :term:`Chameleon` :term:`ZPT` -template. These templates will live in the ``templates`` directory of our -tutorial package. Chameleon templates must have a ``.pt`` extension to be -recognized as such. +reference a :term:`template`. Each template is a :term:`Chameleon` +:term:`ZPT` template. These templates will live in the ``templates`` +directory of our tutorial package. Chameleon templates must have a ``.pt`` +extension to be recognized as such. -The ``view.pt`` Template +The ``view.pt`` template ------------------------ Create ``tutorial/tutorial/templates/view.pt`` and add the following @@ -242,15 +252,13 @@ content: This template is used by ``view_page()`` for displaying a single wiki page. It includes: -- A ``div`` element that is replaced with the ``content`` - value provided by the view (lines 36-38). ``content`` - contains HTML, so the ``structure`` keyword is used - to prevent escaping it (i.e., changing ">" to ">", etc.) -- A link that points - at the "edit" URL which invokes the ``edit_page`` view for - the page being viewed (lines 40-42). +- A ``div`` element that is replaced with the ``content`` value provided by + the view (lines 36-38). ``content`` contains HTML, so the ``structure`` + keyword is used to prevent escaping it (i.e., changing ">" to ">", etc.) +- A link that points at the "edit" URL which invokes the ``edit_page`` view + for the page being viewed (lines 40-42). -The ``edit.pt`` Template +The ``edit.pt`` template ------------------------ Create ``tutorial/tutorial/templates/edit.pt`` and add the following @@ -260,24 +268,21 @@ content: :linenos: :language: html -This template is used by ``add_page()`` and ``edit_page()`` for adding -and editing a wiki page. It displays a page containing a form that includes: +This template is used by ``add_page()`` and ``edit_page()`` for adding and +editing a wiki page. It displays a page containing a form that includes: - A 10 row by 60 column ``textarea`` field named ``body`` that is filled with any existing page data when it is rendered (line 45). - A submit button that has the name ``form.submitted`` (line 48). -The form POSTs back to the ``save_url`` argument supplied -by the view (line 43). The view will use the ``body`` and -``form.submitted`` values. +The form POSTs back to the ``save_url`` argument supplied by the view (line +43). The view will use the ``body`` and ``form.submitted`` values. -.. note:: Our templates use a ``request`` object that - none of our tutorial views return in their dictionary. - ``request`` is one of several - names that are available "by default" in a template when a template - renderer is used. See :ref:`renderer_system_values` for - information about other names that are available by default - when a template is used as a renderer. +.. note:: Our templates use a ``request`` object that none of our tutorial + views return in their dictionary. ``request`` is one of several names that + are available "by default" in a template when a template renderer is used. + See :ref:`renderer_system_values` for information about other names that + are available by default when a template is used as a renderer. Static Assets ------------- @@ -347,21 +352,19 @@ We can finally examine our application in a browser (See :ref:`wiki2-start-the-application`). Launch a browser and visit each of the following URLs, checking that the result is as expected: -- http://localhost:6543 in a browser invokes the - ``view_wiki`` view. This always redirects to the ``view_page`` view - of the FrontPage page object. +- ``http://localhost:6543/`` invokes the ``view_wiki`` view. This always + redirects to the ``view_page`` view of the ``FrontPage`` page object. -- http://localhost:6543/FrontPage in a browser invokes - the ``view_page`` view of the front page object. +- http://localhost:6543/FrontPage invokes the ``view_page`` view of the front + page object. -- http://localhost:6543/FrontPage/edit_page in a browser - invokes the edit view for the front page object. +- http://localhost:6543/FrontPage/edit_page invokes the edit view for the + front page object. -- http://localhost:6543/add_page/SomePageName in a - browser invokes the add view for a page. +- http://localhost:6543/add_page/SomePageName invokes the add view for a page. - To generate an error, visit http://localhost:6543/foobars/edit_page which - will generate a ``NoResultFound: No row was found for one()`` error. - You'll see an interactive traceback facility provided - by :term:`pyramid_debugtoolbar`. + will generate a ``NoResultFound: No row was found for one()`` error. You'll + see an interactive traceback facility provided by + :term:`pyramid_debugtoolbar`. -- cgit v1.2.3 From 6901d74698da7b8457f92f0771fe03015acb9261 Mon Sep 17 00:00:00 2001 From: Steve Piercy Date: Wed, 27 May 2015 03:38:39 -0700 Subject: - clean up and make consistent across wiki tutorials - update templates and static assets for new design --- docs/tutorials/wiki2/definingviews.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index d7f63100d..0b495445a 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -345,14 +345,14 @@ something like: The highlighted lines are the ones that need to be added or edited. -Viewing the Application in a Browser +Viewing the application in a browser ==================================== We can finally examine our application in a browser (See :ref:`wiki2-start-the-application`). Launch a browser and visit each of the following URLs, checking that the result is as expected: -- ``http://localhost:6543/`` invokes the ``view_wiki`` view. This always +- http://localhost:6543/ invokes the ``view_wiki`` view. This always redirects to the ``view_page`` view of the ``FrontPage`` page object. - http://localhost:6543/FrontPage invokes the ``view_page`` view of the front @@ -367,4 +367,3 @@ each of the following URLs, checking that the result is as expected: will generate a ``NoResultFound: No row was found for one()`` error. You'll see an interactive traceback facility provided by :term:`pyramid_debugtoolbar`. - -- cgit v1.2.3 From 3214690b08e3c495ab64170e1430ece240853110 Mon Sep 17 00:00:00 2001 From: Steve Piercy Date: Fri, 13 Nov 2015 02:30:32 -0800 Subject: update wiki2/src/views and wiki2/definingviews.rst --- docs/tutorials/wiki2/definingviews.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 0b495445a..8a96e433c 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -14,7 +14,7 @@ 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 +Declaring dependencies in our ``setup.py`` file =============================================== The view code in our application will depend on a package which is not a @@ -47,7 +47,7 @@ directory in which ``setup.py`` lives) and execute the following command. On UNIX: -.. code-block:: text +.. code-block:: bash $ cd tutorial $ $VENV/bin/python setup.py develop @@ -60,17 +60,17 @@ On Windows: c:\pyramidtut\tutorial> %VENV%\Scripts\python setup.py develop Success executing this command will end with a line to the console something -like:: +like this:: Finished processing dependencies for tutorial==0.0 Adding view functions in ``views.py`` ===================================== -It's time for a major change. Open ``tutorial/tutorial/views.py`` and edit it -to look like the following: +It's time for a major change. Open ``tutorial/tutorial/views/default.py`` and +edit it to look like the following: -.. literalinclude:: src/views/tutorial/views.py +.. literalinclude:: src/views/tutorial/views/default.py :linenos: :language: python :emphasize-lines: 1-7,14,16-72 -- cgit v1.2.3 From 429529a09992554229ef7274bfc4f43394256105 Mon Sep 17 00:00:00 2001 From: Steve Piercy Date: Fri, 13 Nov 2015 03:46:13 -0800 Subject: update wiki2/src/views and wiki2/definingviews.rst --- docs/tutorials/wiki2/definingviews.rst | 113 +++++++++++++++++---------------- 1 file changed, 58 insertions(+), 55 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 8a96e433c..08fa8f16b 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -64,8 +64,8 @@ like this:: Finished processing dependencies for tutorial==0.0 -Adding view functions in ``views.py`` -===================================== +Adding view functions in ``views/default.py`` +============================================= It's time for a major change. Open ``tutorial/tutorial/views/default.py`` and edit it to look like the following: @@ -73,18 +73,19 @@ edit it to look like the following: .. literalinclude:: src/views/tutorial/views/default.py :linenos: :language: python - :emphasize-lines: 1-7,14,16-72 + :emphasize-lines: 1-9,12-70 The highlighted lines need to be added or edited. -We added some imports and created a regular expression to find "WikiWords". +We added some imports, and created a regular expression to find "WikiWords". We got rid of the ``my_view`` view function and its decorator that was added when we originally rendered the ``alchemy`` scaffold. It was only an example -and isn't relevant to our application. +and isn't relevant to our application. We also delated the ``db_err_msg`` +string. -Then we added four :term:`view callable` functions to our ``views.py`` -module: +Then we added four :term:`view callable` functions to our ``views/default.py`` +module: * ``view_wiki()`` - Displays the wiki itself. It will answer on the root URL. * ``view_page()`` - Displays an individual page. @@ -95,20 +96,20 @@ We'll describe each one briefly in the following sections. .. note:: - There is nothing special about the filename ``views.py``. A project may - have many view callables throughout its codebase in arbitrarily named - files. Files implementing view callables often have ``view`` in their - filenames (or may live in a Python subpackage of your application package - named ``views``), but this is only by convention. + There is nothing special about the filename ``default.py``. A project may + have many view callables throughout its codebase in arbitrarily named files. + Files implementing view callables often have ``view`` in their filenames (or + may live in a Python subpackage of your application package named ``views``, + as in our case), but this is only by convention. The ``view_wiki`` view function ------------------------------- Following is the code for the ``view_wiki`` view function and its decorator: -.. literalinclude:: src/views/tutorial/views.py - :lines: 20-24 - :lineno-start: 20 +.. literalinclude:: src/views/tutorial/views/default.py + :lines: 17-20 + :lineno-start: 17 :linenos: :language: python @@ -130,9 +131,9 @@ The ``view_page`` view function Here is the code for the ``view_page`` view function and its decorator: -.. literalinclude:: src/views/tutorial/views.py - :lines: 25-45 - :lineno-start: 25 +.. literalinclude:: src/views/tutorial/views/default.py + :lines: 22-42 + :lineno-start: 22 :linenos: :language: python @@ -158,17 +159,17 @@ 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()``. +renderer used will be the ``templates/view.jinja2`` template, as indicated in +the ``@view_config`` decorator that is applied to ``view_page()``. The ``add_page`` view function ------------------------------ Here is the code for the ``add_page`` view function and its decorator: -.. literalinclude:: src/views/tutorial/views.py - :lines: 47-58 - :lineno-start: 47 +.. literalinclude:: src/views/tutorial/views/default.py + :lines: 44-55 + :lineno-start: 44 :linenos: :language: python @@ -189,15 +190,15 @@ If the view execution *is* a result of a form submission (i.e., the expression ``'form.submitted' in request.params`` is ``True``), we grab the page body from the form data, create a Page object with this page body and the name taken from ``matchdict['pagename']``, and save it into the database using -``DBSession.add``. We then redirect back to the ``view_page`` view for the -newly created page. +``request.dbession.add``. We then redirect back to the ``view_page`` view for +the newly created page. If the view execution is *not* a result of a form submission (i.e., the expression ``'form.submitted' in request.params`` is ``False``), the view callable renders a template. To do so, it generates a ``save_url`` which the template uses as the form post URL during rendering. We're lazy here, so -we're going to use the same template (``templates/edit.pt``) for the add -view as well as the page edit view. To do so we create a dummy Page object +we're going to use the same template (``templates/edit.jinja2``) for the add +view as well as the page edit view. To do so we create a dummy ``Page`` object in order to satisfy the edit form's desire to have *some* page object exposed as ``page``. :app:`Pyramid` will render the template associated with this view to a response. @@ -207,14 +208,14 @@ The ``edit_page`` view function Here is the code for the ``edit_page`` view function and its decorator: -.. literalinclude:: src/views/tutorial/views.py - :lines: 60-72 - :lineno-start: 60 +.. literalinclude:: src/views/tutorial/views/default.py + :lines: 57-69 + :lineno-start: 57 :linenos: :language: python ``edit_page()`` is invoked when a user clicks the "Edit this -Page" button on the view form. It renders an edit form but it also acts as +Page" button on the view form. It renders an edit form, but it also acts as the handler for the form it renders. The ``matchdict`` attribute of the request passed to the ``edit_page`` view will have a ``'pagename'`` key matching the name of the page the user wants to edit. @@ -234,49 +235,51 @@ Adding templates ================ The ``view_page``, ``add_page`` and ``edit_page`` views that we've added -reference a :term:`template`. Each template is a :term:`Chameleon` -:term:`ZPT` template. These templates will live in the ``templates`` -directory of our tutorial package. Chameleon templates must have a ``.pt`` -extension to be recognized as such. +reference a :term:`template`. Each template is a :term:`Jinja2` template. +These templates will live in the ``templates`` directory of our tutorial +package. Jinja2 templates must have a ``.jinja2`` extension to be recognized +as such. -The ``view.pt`` template ------------------------- +The ``view.jinja2`` template +---------------------------- -Create ``tutorial/tutorial/templates/view.pt`` and add the following +Create ``tutorial/tutorial/templates/view.jinja2`` and add the following content: -.. literalinclude:: src/views/tutorial/templates/view.pt +.. literalinclude:: src/views/tutorial/templates/view.jinja2 :linenos: + :emphasize-lines: 36,38-40 :language: html This template is used by ``view_page()`` for displaying a single wiki page. It includes: -- A ``div`` element that is replaced with the ``content`` value provided by - the view (lines 36-38). ``content`` contains HTML, so the ``structure`` - keyword is used to prevent escaping it (i.e., changing ">" to ">", etc.) -- A link that points at the "edit" URL which invokes the ``edit_page`` view - for the page being viewed (lines 40-42). +- A variable that is replaced with the ``content`` value provided by the view + (line 36). ``content`` contains HTML, so the ``|safe`` filter is used to + prevent escaping it (e.g., changing ">" to ">"). +- A link that points at the "edit" URL which invokes the ``edit_page`` view for + the page being viewed (lines 38-40). -The ``edit.pt`` template ------------------------- +The ``edit.jinja2`` template +---------------------------- -Create ``tutorial/tutorial/templates/edit.pt`` and add the following +Create ``tutorial/tutorial/templates/edit.jinja2`` and add the following content: -.. literalinclude:: src/views/tutorial/templates/edit.pt +.. literalinclude:: src/views/tutorial/templates/edit.jinja2 :linenos: + :emphasize-lines: 42,44,47 :language: html This template is used by ``add_page()`` and ``edit_page()`` for adding and editing a wiki page. It displays a page containing a form that includes: -- A 10 row by 60 column ``textarea`` field named ``body`` that is filled - with any existing page data when it is rendered (line 45). -- A submit button that has the name ``form.submitted`` (line 48). +- A 10-row by 60-column ``textarea`` field named ``body`` that is filled with + any existing page data when it is rendered (line 44). +- A submit button that has the name ``form.submitted`` (line 47). The form POSTs back to the ``save_url`` argument supplied by the view (line -43). The view will use the ``body`` and ``form.submitted`` values. +42). The view will use the ``body`` and ``form.submitted`` values. .. note:: Our templates use a ``request`` object that none of our tutorial views return in their dictionary. ``request`` is one of several names that @@ -284,7 +287,7 @@ The form POSTs back to the ``save_url`` argument supplied by the view (line See :ref:`renderer_system_values` for information about other names that are available by default when a template is used as a renderer. -Static Assets +Static assets ------------- Our templates name static assets, including CSS and images. We don't need @@ -299,7 +302,7 @@ subdirectories) and are just referred to by URL or by using the convenience method ``static_url``, e.g., ``request.static_url(':static/foo.css')`` within templates. -Adding Routes to ``__init__.py`` +Adding routes to ``__init__.py`` ================================ The ``__init__.py`` file contains @@ -340,7 +343,7 @@ something like: .. literalinclude:: src/views/tutorial/__init__.py :linenos: - :emphasize-lines: 19-22 + :emphasize-lines: 11-14 :language: python The highlighted lines are the ones that need to be added or edited. -- cgit v1.2.3 From d1cb34643e086ac74965455b486ce0058764324f Mon Sep 17 00:00:00 2001 From: Michael Merickel Date: Sun, 7 Feb 2016 13:57:51 -0600 Subject: assume the user is in the tutorial folder this is already assumed inside of installation where commands are run relative to setup.py --- docs/tutorials/wiki2/definingviews.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 08fa8f16b..8660c2772 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -67,7 +67,7 @@ like this:: Adding view functions in ``views/default.py`` ============================================= -It's time for a major change. Open ``tutorial/tutorial/views/default.py`` and +It's time for a major change. Open ``tutorial/views/default.py`` and edit it to look like the following: .. literalinclude:: src/views/tutorial/views/default.py @@ -243,7 +243,7 @@ as such. The ``view.jinja2`` template ---------------------------- -Create ``tutorial/tutorial/templates/view.jinja2`` and add the following +Create ``tutorial/templates/view.jinja2`` and add the following content: .. literalinclude:: src/views/tutorial/templates/view.jinja2 @@ -263,7 +263,7 @@ wiki page. It includes: The ``edit.jinja2`` template ---------------------------- -Create ``tutorial/tutorial/templates/edit.jinja2`` and add the following +Create ``tutorial/templates/edit.jinja2`` and add the following content: .. literalinclude:: src/views/tutorial/templates/edit.jinja2 -- cgit v1.2.3 From 4b23c9f1344a359214455668741b52c3db8cf6ea Mon Sep 17 00:00:00 2001 From: Michael Merickel Date: Sun, 7 Feb 2016 22:08:52 -0600 Subject: update definingviews chapter of wiki2 tutorial --- docs/tutorials/wiki2/definingviews.rst | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 8660c2772..4bc7f461b 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -96,11 +96,12 @@ We'll describe each one briefly in the following sections. .. note:: - There is nothing special about the filename ``default.py``. A project may - have many view callables throughout its codebase in arbitrarily named files. - Files implementing view callables often have ``view`` in their filenames (or + There is nothing special about the filename ``default.py`` exept that + it is a Python module. A project may have many view callables throughout + its codebase in arbitrarily named modules. + Modules implementing view callables often have ``view`` in their name (or may live in a Python subpackage of your application package named ``views``, - as in our case), but this is only by convention. + as in our case), but this is only by convention, not a requirement. The ``view_wiki`` view function ------------------------------- @@ -109,7 +110,7 @@ Following is the code for the ``view_wiki`` view function and its decorator: .. literalinclude:: src/views/tutorial/views/default.py :lines: 17-20 - :lineno-start: 17 + :lineno-match: :linenos: :language: python @@ -119,8 +120,8 @@ represents the path to our "FrontPage". The ``view_wiki`` view callable always redirects to the URL of a Page resource named "FrontPage". To do so, it returns an instance of the -:class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement -the :class:`pyramid.interfaces.IResponse` interface, like +:class:`pyramid.httpexceptions.HTTPFound` class (instances of which +implement the :class:`pyramid.interfaces.IResponse` interface, like :class:`pyramid.response.Response` does). It uses the :meth:`pyramid.request.Request.route_url` API to construct an URL to the ``FrontPage`` page (i.e., ``http://localhost:6543/FrontPage``), and uses it as @@ -133,7 +134,7 @@ Here is the code for the ``view_page`` view function and its decorator: .. literalinclude:: src/views/tutorial/views/default.py :lines: 22-42 - :lineno-start: 22 + :lineno-match: :linenos: :language: python @@ -159,7 +160,7 @@ 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.jinja2`` template, as indicated in +renderer used will be the ``view.jinja2`` template, as indicated in the ``@view_config`` decorator that is applied to ``view_page()``. The ``add_page`` view function @@ -169,7 +170,7 @@ Here is the code for the ``add_page`` view function and its decorator: .. literalinclude:: src/views/tutorial/views/default.py :lines: 44-55 - :lineno-start: 44 + :lineno-match: :linenos: :language: python @@ -209,8 +210,8 @@ The ``edit_page`` view function Here is the code for the ``edit_page`` view function and its decorator: .. literalinclude:: src/views/tutorial/views/default.py - :lines: 57-69 - :lineno-start: 57 + :lines: 57-68 + :lineno-match: :linenos: :language: python @@ -281,7 +282,9 @@ editing a wiki page. It displays a page containing a form that includes: The form POSTs back to the ``save_url`` argument supplied by the view (line 42). The view will use the ``body`` and ``form.submitted`` values. -.. note:: Our templates use a ``request`` object that none of our tutorial +.. note:: + + Our templates use a ``request`` object that none of our tutorial views return in their dictionary. ``request`` is one of several names that are available "by default" in a template when a template renderer is used. See :ref:`renderer_system_values` for information about other names that -- cgit v1.2.3 From e01b270c451ce6f23b53181ad79b430666ebe003 Mon Sep 17 00:00:00 2001 From: Michael Merickel Date: Wed, 10 Feb 2016 23:45:32 -0600 Subject: explain the base layout.jinja2 template and notfound view --- docs/tutorials/wiki2/definingviews.rst | 81 ++++++++++++++++++++++++++++++---- 1 file changed, 73 insertions(+), 8 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 4bc7f461b..6629839f8 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -73,7 +73,7 @@ edit it to look like the following: .. literalinclude:: src/views/tutorial/views/default.py :linenos: :language: python - :emphasize-lines: 1-9,12-70 + :emphasize-lines: 1-9,12-68 The highlighted lines need to be added or edited. @@ -241,6 +241,26 @@ These templates will live in the ``templates`` directory of our tutorial package. Jinja2 templates must have a ``.jinja2`` extension to be recognized as such. +The ``layout.jinja2`` template +------------------------------ + +Replace ``tutorial/templates/layout.jinja2`` with the following content: + +.. literalinclude:: src/views/tutorial/templates/layout.jinja2 + :linenos: + :emphasize-lines: 11,36 + :language: html + +Since we're using a templating engine we can factor common boilerplate out of +our page templates into reusable components. One method for doing this +is template inheritance via blocks. + +- We have defined 2 placeholders in the layout template where a child template + can override the content. These blocks are named ``title`` (line 11) and + ``content`` (line 36). +- Please refer to the Jinja2_ documentation for more information about + template inheritance. + The ``view.jinja2`` template ---------------------------- @@ -249,17 +269,21 @@ content: .. literalinclude:: src/views/tutorial/templates/view.jinja2 :linenos: - :emphasize-lines: 36,38-40 + :emphasize-lines: 1,4,6-8 :language: html This template is used by ``view_page()`` for displaying a single wiki page. It includes: +- We begin by extending the ``layout.jinja2`` template defined above + which provides the skeleton of the page (line 1). +- We override the ``content`` block from the base layout to insert our markup + into the body (line 3). - A variable that is replaced with the ``content`` value provided by the view - (line 36). ``content`` contains HTML, so the ``|safe`` filter is used to + (line 4). ``content`` contains HTML, so the ``|safe`` filter is used to prevent escaping it (e.g., changing ">" to ">"). - A link that points at the "edit" URL which invokes the ``edit_page`` view for - the page being viewed (lines 38-40). + the page being viewed (lines 6-8). The ``edit.jinja2`` template ---------------------------- @@ -269,18 +293,57 @@ content: .. literalinclude:: src/views/tutorial/templates/edit.jinja2 :linenos: - :emphasize-lines: 42,44,47 + :emphasize-lines: 3,12,14,17 :language: html This template is used by ``add_page()`` and ``edit_page()`` for adding and editing a wiki page. It displays a page containing a form that includes: +- Again we are extending the ``layout.jinja2`` template which provides + the skeleton of the page. +- Override the ``title`` block to affect the ```` tag in the + ``head`` of the page (line 3). - A 10-row by 60-column ``textarea`` field named ``body`` that is filled with - any existing page data when it is rendered (line 44). -- A submit button that has the name ``form.submitted`` (line 47). + any existing page data when it is rendered (line 14). +- A submit button that has the name ``form.submitted`` (line 17). The form POSTs back to the ``save_url`` argument supplied by the view (line -42). The view will use the ``body`` and ``form.submitted`` values. +12). The view will use the ``body`` and ``form.submitted`` values. + +The ``404.jinja2`` template +--------------------------- + +Replace ``tutorial/templates/404.jinja2`` with the following content: + +.. literalinclude:: src/views/tutorial/templates/404.jinja2 + :linenos: + :language: html + +This template is linked from the ``notfound_view`` defined in +``tutorial/views/notfound.py`` as shown here: + +.. literalinclude:: src/views/tutorial/views/notfound.py + :linenos: + :language: python + +There are several important things to note about this configuration: + +- The ``notfound_view`` in the above snippet is called an + :term:`exception view`. For more information see + :ref:`special_exceptions_in_callables`. +- The ``notfound_view`` sets the response status to 404. It's possible to + affect the response object used by the renderer via + :ref:`request_response_attr`. +- The ``notfound_view`` is registered as an exception view and will be invoked + **only** if ``pyramid.httpexceptions.HTTPNotFound`` is raised as an + exception. This means it will not be invoked for any responses returned + from a view normally. For example, on line 27 of + ``tutorial/views/default.py`` the exception is raised which will trigger + the view. + +Finally, you may delete the ``tutorial/templates/mytemplate.jinja2`` +template that was provided by the ``alchemy`` scaffold as we have created +our own templates for the wiki. .. note:: @@ -373,3 +436,5 @@ each of the following URLs, checking that the result is as expected: will generate a ``NoResultFound: No row was found for one()`` error. You'll see an interactive traceback facility provided by :term:`pyramid_debugtoolbar`. + +.. _jinja2: http://jinja.pocoo.org/ -- cgit v1.2.3 From 23c2d7b337a5873dba0ca6c146e1174136ac2187 Mon Sep 17 00:00:00 2001 From: Michael Merickel <michael@merickel.org> Date: Fri, 12 Feb 2016 02:54:37 -0600 Subject: update the views/models with setup.py develop --- docs/tutorials/wiki2/definingviews.rst | 43 +++++++--------------------------- 1 file changed, 8 insertions(+), 35 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 6629839f8..8bccc3fc0 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -14,13 +14,12 @@ 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 -=============================================== +Adding the ``docutils`` dependency +================================== -The view code in our application will depend on a package which is not a -dependency of the original "tutorial" application. The original "tutorial" -application was generated by the ``pcreate`` command; it doesn't know -about our custom application requirements. +Remember in the previous chapter we added a new dependency on the ``bcrypt`` +package. Again, the view code in our application will depend on a package which +is not a dependency of the original "tutorial" application. We need to add a dependency on the ``docutils`` package to our ``tutorial`` package's ``setup.py`` file by assigning this dependency to the ``requires`` @@ -30,39 +29,13 @@ Open ``tutorial/setup.py`` and edit it to look like the following: .. literalinclude:: src/views/setup.py :linenos: - :emphasize-lines: 20 + :emphasize-lines: 13 :language: python Only the highlighted line needs to be added. -Running ``setup.py develop`` -============================ - -Since a new software dependency was added, you will need to run ``python -setup.py develop`` again inside the root of the ``tutorial`` package to obtain -and register the newly added dependency distribution. - -Make sure your current working directory is the root of the project (the -directory in which ``setup.py`` lives) and execute the following command. - -On UNIX: - -.. code-block:: bash - - $ cd tutorial - $ $VENV/bin/python setup.py develop - -On Windows: - -.. code-block:: text - - c:\pyramidtut> cd tutorial - c:\pyramidtut\tutorial> %VENV%\Scripts\python setup.py develop - -Success executing this command will end with a line to the console something -like this:: - - Finished processing dependencies for tutorial==0.0 +Again, as we did in the previous chapter, the dependency now needs to be +installed so re-run the ``python setup.py develop`` command. Adding view functions in ``views/default.py`` ============================================= -- cgit v1.2.3 From 60891b844c883d2c9ce864522f2202d9514d8d83 Mon Sep 17 00:00:00 2001 From: Michael Merickel <michael@merickel.org> Date: Sat, 13 Feb 2016 13:26:05 -0600 Subject: improve the views section by removing quirks and explaining transactions --- docs/tutorials/wiki2/definingviews.rst | 274 +++++++++++++++++++-------------- 1 file changed, 159 insertions(+), 115 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 8bccc3fc0..8f0f7b51d 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -37,6 +37,80 @@ Only the highlighted line needs to be added. Again, as we did in the previous chapter, the dependency now needs to be installed so re-run the ``python setup.py develop`` command. +Static assets +------------- + +Our templates name static assets, including CSS and images. We don't need +to create these files within our package's ``static`` directory because they +were provided at the time we created the project. + +As an example, the CSS file will be accessed via +``http://localhost:6543/static/theme.css`` by virtue of the call to the +``add_static_view`` directive we've made in the ``__init__.py`` file. Any +number and type of static assets can be placed in this directory (or +subdirectories) and are just referred to by URL or by using the convenience +method ``static_url``, e.g., +``request.static_url('<package>:static/foo.css')`` within templates. + +Adding routes to ``__init__.py`` +================================ + +This is the URL Dispatch tutorial and so let's start by adding some +URL patterns to our app. Later we'll attach views to handle the URLs. + +The ``__init__.py`` file contains +:meth:`pyramid.config.Configurator.add_route` calls which serve to add routes +to our application. 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 then need to add four calls to ``add_route``. Note that the *ordering* of +these declarations is very important. ``route`` declarations are matched in +the order they're found in the ``__init__.py`` file. + +#. Add a declaration which maps the pattern ``/`` (signifying the root URL) + to the route named ``view_wiki``. It maps to our ``view_wiki`` view + callable by virtue of the ``@view_config`` attached to the ``view_wiki`` + view function indicating ``route_name='view_wiki'``. + +#. Add a declaration which maps the pattern ``/{pagename}`` to the route named + ``view_page``. This is the regular view for a page. It maps + to our ``view_page`` view callable by virtue of the ``@view_config`` + attached to the ``view_page`` view function indicating + ``route_name='view_page'``. + +#. Add a declaration which maps the pattern ``/add_page/{pagename}`` to the + route named ``add_page``. This is the add view for a new page. It maps + to our ``add_page`` view callable by virtue of the ``@view_config`` + attached to the ``add_page`` view function indicating + ``route_name='add_page'``. + +#. Add a declaration which maps the pattern ``/{pagename}/edit_page`` to the + route named ``edit_page``. This is the edit view for a page. It maps + to our ``edit_page`` view callable by virtue of the ``@view_config`` + attached to the ``edit_page`` view function indicating + ``route_name='edit_page'``. + +As a result of our edits, the ``__init__.py`` file should look +something like: + +.. literalinclude:: src/views/tutorial/__init__.py + :linenos: + :emphasize-lines: 11-14 + :language: python + +The highlighted lines are the ones that need to be added or edited. + +.. warn:: + + The order of the routes is important! If you placed + ``/{pagename}/edit_page`` **before** ``/add_page/{pagename}`` then we would + never be able to add pages because the first route would always match + a request to ``/add_page/edit_page`` whereas we want ``/add_page/..`` to + have priority. This isn't a huge problem in this particular app because + wiki pages are always camel case but it's important to be aware of this + behavior in your own apps. + Adding view functions in ``views/default.py`` ============================================= @@ -46,7 +120,7 @@ edit it to look like the following: .. literalinclude:: src/views/tutorial/views/default.py :linenos: :language: python - :emphasize-lines: 1-9,12-68 + :emphasize-lines: 1-9,12-70 The highlighted lines need to be added or edited. @@ -54,7 +128,7 @@ We added some imports, and created a regular expression to find "WikiWords". We got rid of the ``my_view`` view function and its decorator that was added when we originally rendered the ``alchemy`` scaffold. It was only an example -and isn't relevant to our application. We also delated the ``db_err_msg`` +and isn't relevant to our application. We also deleted the ``db_err_msg`` string. Then we added four :term:`view callable` functions to our ``views/default.py`` @@ -88,7 +162,7 @@ Following is the code for the ``view_wiki`` view function and its decorator: :language: python ``view_wiki()`` is the :term:`default view` that gets called when a request is -made to the root URL of our wiki. It always redirects to an URL which +made to the root URL of our wiki. It always redirects to a URL which represents the path to our "FrontPage". The ``view_wiki`` view callable always redirects to the URL of a Page resource @@ -96,7 +170,7 @@ named "FrontPage". To do so, it returns an instance of the :class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement the :class:`pyramid.interfaces.IResponse` interface, like :class:`pyramid.response.Response` does). It uses the -:meth:`pyramid.request.Request.route_url` API to construct an URL to the +:meth:`pyramid.request.Request.route_url` API to construct a URL to the ``FrontPage`` page (i.e., ``http://localhost:6543/FrontPage``), and uses it as the "location" of the ``HTTPFound`` response, forming an HTTP redirect. @@ -116,12 +190,12 @@ Here is the code for the ``view_page`` view function and its decorator: ``Page`` model object) as HTML. Then it substitutes an HTML anchor for each *WikiWord* reference in the rendered HTML using a compiled regular expression. -The curried function named ``check`` is used as the first argument to +The curried function named ``add_link`` is used as the first argument to ``wikiwords.sub``, indicating that it should be called to provide a value for each WikiWord match found in the content. If the wiki already contains a -page with the matched WikiWord name, ``check()`` generates a view +page with the matched WikiWord name, ``add_link()`` generates a view link to be used as the substitution value and returns it. If the wiki does -not already contain a page with the matched WikiWord name, ``check()`` +not already contain a page with the matched WikiWord name, ``add_link()`` generates an "add" link as the substitution value and returns it. As a result, the ``content`` variable is now a fully formed bit of HTML @@ -136,19 +210,73 @@ associated with the view configuration to render a response. In our case, the renderer used will be the ``view.jinja2`` template, as indicated in the ``@view_config`` decorator that is applied to ``view_page()``. +If the page does not exist then we need to handle that by raising +:class:`pyramid.httpexceptions.HTTPNotFound`` to trigger our 404 handling +defined in ``tutorial/views/notfound.py``. + +.. note:: + + Using ``raise`` versus ``return`` with the http exceptions is an important + distinction that can commonly mess people up. In + ``tutorial/views/notfound.py`` there is an :term:`exception view` + registered for handling the ``HTTPNotFound`` exception. Exception views + are only triggered for raised exceptions. If the ``HTTPNotFound`` is + returned then it has an internal "stock" template that it will use + to render itself as a response. If you aren't seeing your exception + view being executed this is probably the problem! See + :ref:`special_exceptions_in_callables` for more information about + exception views. + +The ``edit_page`` view function +------------------------------- + +Here is the code for the ``edit_page`` view function and its decorator: + +.. literalinclude:: src/views/tutorial/views/default.py + :lines: 44-56 + :lineno-match: + :linenos: + :language: python + +``edit_page()`` is 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 ``matchdict`` attribute of the +request passed to the ``edit_page`` view will have a ``'pagename'`` key +matching the name of the page the user wants to edit. + +If the view execution *is* a result of a form submission (i.e., the expression +``'form.submitted' in request.params`` is ``True``), the view grabs the +``body`` element of the request parameters and sets it as the ``data`` +attribute of the page object. It then redirects to the ``view_page`` view +of the wiki page. + +If the view execution is *not* a result of a form submission (i.e., the +expression ``'form.submitted' in request.params`` is ``False``), the view +simply renders the edit form, passing the page object and a ``save_url`` +which will be used as the action of the generated form. + +.. note:: + + Since our ``request.dbsession`` defined in the previous chapter is + registered with the ``pyramid_tm`` transaction manager any changes we make + to objects managed by the that session will be committed automatically. + In the event that there was an error (even later, in our template code) the + changes would be aborted. This means the view itself does not need to + concern itself with commit/rollback logic. + The ``add_page`` view function ------------------------------ Here is the code for the ``add_page`` view function and its decorator: .. literalinclude:: src/views/tutorial/views/default.py - :lines: 44-55 + :lines: 58-70 :lineno-match: :linenos: :language: python ``add_page()`` is invoked when a user clicks on a *WikiWord* which -isn't yet represented as a page in the system. The ``check`` function +isn't yet represented as a page in the system. The ``add_link`` function within the ``view_page`` view generates URLs to this view. ``add_page()`` also acts as a handler for the form that is generated when we want to add a page object. The ``matchdict`` attribute of the @@ -164,8 +292,12 @@ If the view execution *is* a result of a form submission (i.e., the expression ``'form.submitted' in request.params`` is ``True``), we grab the page body from the form data, create a Page object with this page body and the name taken from ``matchdict['pagename']``, and save it into the database using -``request.dbession.add``. We then redirect back to the ``view_page`` view for -the newly created page. +``request.dbession.add``. Since we have not yet covered authentication we +don't have a logged-in user to add as the page's ``creator``. Until we +get to that point in the tutorial we'll just assume that all pages are created +by the ``editor`` user so we query that object and set it on ``page.creator``. +Finally, we redirect the client back to the ``view_page`` view for the newly +created page. If the view execution is *not* a result of a form submission (i.e., the expression ``'form.submitted' in request.params`` is ``False``), the view @@ -177,34 +309,6 @@ in order to satisfy the edit form's desire to have *some* page object exposed as ``page``. :app:`Pyramid` will render the template associated with this view to a response. -The ``edit_page`` view function -------------------------------- - -Here is the code for the ``edit_page`` view function and its decorator: - -.. literalinclude:: src/views/tutorial/views/default.py - :lines: 57-68 - :lineno-match: - :linenos: - :language: python - -``edit_page()`` is 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 ``matchdict`` attribute of the -request passed to the ``edit_page`` view will have a ``'pagename'`` key -matching the name of the page the user wants to edit. - -If the view execution *is* a result of a form submission (i.e., the expression -``'form.submitted' in request.params`` is ``True``), the view grabs the -``body`` element of the request parameters and sets it as the ``data`` -attribute of the page object. It then redirects to the ``view_page`` view -of the wiki page. - -If the view execution is *not* a result of a form submission (i.e., the -expression ``'form.submitted' in request.params`` is ``False``), the view -simply renders the edit form, passing the page object and a ``save_url`` -which will be used as the action of the generated form. - Adding templates ================ @@ -229,7 +333,7 @@ our page templates into reusable components. One method for doing this is template inheritance via blocks. - We have defined 2 placeholders in the layout template where a child template - can override the content. These blocks are named ``title`` (line 11) and + can override the content. These blocks are named ``subtitle`` (line 11) and ``content`` (line 36). - Please refer to the Jinja2_ documentation for more information about template inheritance. @@ -237,44 +341,45 @@ is template inheritance via blocks. The ``view.jinja2`` template ---------------------------- -Create ``tutorial/templates/view.jinja2`` and add the following -content: +Create ``tutorial/templates/view.jinja2`` and add the following content: .. literalinclude:: src/views/tutorial/templates/view.jinja2 :linenos: :emphasize-lines: 1,4,6-8 :language: html -This template is used by ``view_page()`` for displaying a single -wiki page. It includes: +This template is used by ``view_page()`` for displaying a single wiki page. +It includes: - We begin by extending the ``layout.jinja2`` template defined above which provides the skeleton of the page (line 1). +- We override the ``subtitle`` block from the base layout to insert the + page name of the page into the page's title (line 3). - We override the ``content`` block from the base layout to insert our markup - into the body (line 3). + into the body (line 5-18). - A variable that is replaced with the ``content`` value provided by the view - (line 4). ``content`` contains HTML, so the ``|safe`` filter is used to + (line 6). ``content`` contains HTML, so the ``|safe`` filter is used to prevent escaping it (e.g., changing ">" to ">"). - A link that points at the "edit" URL which invokes the ``edit_page`` view for - the page being viewed (lines 6-8). + the page being viewed (line 9). The ``edit.jinja2`` template ---------------------------- -Create ``tutorial/templates/edit.jinja2`` and add the following -content: +Create ``tutorial/templates/edit.jinja2`` and add the following content: .. literalinclude:: src/views/tutorial/templates/edit.jinja2 :linenos: :emphasize-lines: 3,12,14,17 :language: html -This template is used by ``add_page()`` and ``edit_page()`` for adding and -editing a wiki page. It displays a page containing a form that includes: +This template serves two use-cases. It is used by ``add_page()`` and +``edit_page()`` for adding and editing a wiki page. It displays a page +containing a form that includes: -- Again we are extending the ``layout.jinja2`` template which provides - the skeleton of the page. -- Override the ``title`` block to affect the ``<title>`` tag in the +- Again, we are extending the ``layout.jinja2`` template which provides + the skeleton of the page (line 1). +- Override the ``subtitle`` block to affect the ``<title>`` tag in the ``head`` of the page (line 3). - A 10-row by 60-column ``textarea`` field named ``body`` that is filled with any existing page data when it is rendered (line 14). @@ -326,67 +431,6 @@ our own templates for the wiki. See :ref:`renderer_system_values` for information about other names that are available by default when a template is used as a renderer. -Static assets -------------- - -Our templates name static assets, including CSS and images. We don't need -to create these files within our package's ``static`` directory because they -were provided at the time we created the project. - -As an example, the CSS file will be accessed via -``http://localhost:6543/static/theme.css`` by virtue of the call to the -``add_static_view`` directive we've made in the ``__init__.py`` file. Any -number and type of static assets can be placed in this directory (or -subdirectories) and are just referred to by URL or by using the convenience -method ``static_url``, e.g., -``request.static_url('<package>:static/foo.css')`` within templates. - -Adding routes to ``__init__.py`` -================================ - -The ``__init__.py`` file contains -:meth:`pyramid.config.Configurator.add_route` calls which serve to add routes -to our application. 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 then need to add four calls to ``add_route``. Note that the *ordering* of -these declarations is very important. ``route`` declarations are matched in -the order they're found in the ``__init__.py`` file. - -#. Add a declaration which maps the pattern ``/`` (signifying the root URL) - to the route named ``view_wiki``. It maps to our ``view_wiki`` view - callable by virtue of the ``@view_config`` attached to the ``view_wiki`` - view function indicating ``route_name='view_wiki'``. - -#. Add a declaration which maps the pattern ``/{pagename}`` to the route named - ``view_page``. This is the regular view for a page. It maps - to our ``view_page`` view callable by virtue of the ``@view_config`` - attached to the ``view_page`` view function indicating - ``route_name='view_page'``. - -#. Add a declaration which maps the pattern ``/add_page/{pagename}`` to the - route named ``add_page``. This is the add view for a new page. It maps - to our ``add_page`` view callable by virtue of the ``@view_config`` - attached to the ``add_page`` view function indicating - ``route_name='add_page'``. - -#. Add a declaration which maps the pattern ``/{pagename}/edit_page`` to the - route named ``edit_page``. This is the edit view for a page. It maps - to our ``edit_page`` view callable by virtue of the ``@view_config`` - attached to the ``edit_page`` view function indicating - ``route_name='edit_page'``. - -As a result of our edits, the ``__init__.py`` file should look -something like: - -.. literalinclude:: src/views/tutorial/__init__.py - :linenos: - :emphasize-lines: 11-14 - :language: python - -The highlighted lines are the ones that need to be added or edited. - Viewing the application in a browser ==================================== -- cgit v1.2.3 From 4c391c55057acbb36df28215f562c42d2b616872 Mon Sep 17 00:00:00 2001 From: Michael Merickel <michael@merickel.org> Date: Sat, 13 Feb 2016 21:01:09 -0600 Subject: fix syntax --- docs/tutorials/wiki2/definingviews.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 8f0f7b51d..acaefe6e8 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -101,7 +101,7 @@ something like: The highlighted lines are the ones that need to be added or edited. -.. warn:: +.. warning:: The order of the routes is important! If you placed ``/{pagename}/edit_page`` **before** ``/add_page/{pagename}`` then we would -- cgit v1.2.3 From bca6c996d9e879c21d8b207bb36bc10ebe1db256 Mon Sep 17 00:00:00 2001 From: Michael Merickel <michael@merickel.org> Date: Sat, 13 Feb 2016 21:08:58 -0600 Subject: highlight more appropriate lines in views --- docs/tutorials/wiki2/definingviews.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index acaefe6e8..fea682628 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -345,7 +345,7 @@ Create ``tutorial/templates/view.jinja2`` and add the following content: .. literalinclude:: src/views/tutorial/templates/view.jinja2 :linenos: - :emphasize-lines: 1,4,6-8 + :emphasize-lines: 1,3,6 :language: html This template is used by ``view_page()`` for displaying a single wiki page. @@ -402,6 +402,7 @@ This template is linked from the ``notfound_view`` defined in .. literalinclude:: src/views/tutorial/views/notfound.py :linenos: + :emphasize-lines: 6 :language: python There are several important things to note about this configuration: @@ -409,8 +410,8 @@ There are several important things to note about this configuration: - The ``notfound_view`` in the above snippet is called an :term:`exception view`. For more information see :ref:`special_exceptions_in_callables`. -- The ``notfound_view`` sets the response status to 404. It's possible to - affect the response object used by the renderer via +- The ``notfound_view`` sets the response status to 404. It's possible + to affect the response object used by the renderer via :ref:`request_response_attr`. - The ``notfound_view`` is registered as an exception view and will be invoked **only** if ``pyramid.httpexceptions.HTTPNotFound`` is raised as an -- cgit v1.2.3 From da5ebc28c38ea32ad99389b5bc23e2f847af8047 Mon Sep 17 00:00:00 2001 From: Michael Merickel <michael@merickel.org> Date: Sun, 14 Feb 2016 17:40:03 -0600 Subject: split routes into a separate module --- docs/tutorials/wiki2/definingviews.rst | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index fea682628..184f9e1fa 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -46,19 +46,19 @@ were provided at the time we created the project. As an example, the CSS file will be accessed via ``http://localhost:6543/static/theme.css`` by virtue of the call to the -``add_static_view`` directive we've made in the ``__init__.py`` file. Any +``add_static_view`` directive we've made in the ``routes.py`` file. Any number and type of static assets can be placed in this directory (or subdirectories) and are just referred to by URL or by using the convenience method ``static_url``, e.g., ``request.static_url('<package>:static/foo.css')`` within templates. -Adding routes to ``__init__.py`` -================================ +Adding routes to ``routes.py`` +============================== This is the URL Dispatch tutorial and so let's start by adding some URL patterns to our app. Later we'll attach views to handle the URLs. -The ``__init__.py`` file contains +The ``routes.py`` file contains :meth:`pyramid.config.Configurator.add_route` calls which serve to add routes to our application. 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 @@ -66,7 +66,7 @@ relevant to our application. We then need to add four calls to ``add_route``. Note that the *ordering* of these declarations is very important. ``route`` declarations are matched in -the order they're found in the ``__init__.py`` file. +the order they're registered. #. Add a declaration which maps the pattern ``/`` (signifying the root URL) to the route named ``view_wiki``. It maps to our ``view_wiki`` view @@ -91,12 +91,11 @@ the order they're found in the ``__init__.py`` file. attached to the ``edit_page`` view function indicating ``route_name='edit_page'``. -As a result of our edits, the ``__init__.py`` file should look -something like: +As a result of our edits, the ``routes.py`` file should look something like: -.. literalinclude:: src/views/tutorial/__init__.py +.. literalinclude:: src/views/tutorial/routes.py :linenos: - :emphasize-lines: 11-14 + :emphasize-lines: 3-6 :language: python The highlighted lines are the ones that need to be added or edited. -- cgit v1.2.3 From c956c9bf07607dbd66f092a11b8cbd1d359829df Mon Sep 17 00:00:00 2001 From: Steve Piercy <web@stevepiercy.com> Date: Fri, 26 Feb 2016 02:02:59 -0800 Subject: update definingviews (done) - minor grammar and syntax --- docs/tutorials/wiki2/definingviews.rst | 249 +++++++++++++++++---------------- 1 file changed, 130 insertions(+), 119 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 184f9e1fa..e48980dc8 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -3,10 +3,10 @@ Defining Views ============== 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. +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 +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}``, @@ -14,10 +14,11 @@ 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'}``. + Adding the ``docutils`` dependency ================================== -Remember in the previous chapter we added a new dependency on the ``bcrypt`` +Remember in the previous chapter we added a new dependency of the ``bcrypt`` package. Again, the view code in our application will depend on a package which is not a dependency of the original "tutorial" application. @@ -35,7 +36,8 @@ Open ``tutorial/setup.py`` and edit it to look like the following: Only the highlighted line needs to be added. Again, as we did in the previous chapter, the dependency now needs to be -installed so re-run the ``python setup.py develop`` command. +installed, so re-run the ``python setup.py develop`` command. + Static assets ------------- @@ -46,52 +48,54 @@ were provided at the time we created the project. As an example, the CSS file will be accessed via ``http://localhost:6543/static/theme.css`` by virtue of the call to the -``add_static_view`` directive we've made in the ``routes.py`` file. Any -number and type of static assets can be placed in this directory (or -subdirectories) and are just referred to by URL or by using the convenience -method ``static_url``, e.g., -``request.static_url('<package>:static/foo.css')`` within templates. +``add_static_view`` directive we've made in the ``routes.py`` file. Any number +and type of static assets can be placed in this directory (or subdirectories) +and are just referred to by URL or by using the convenience method +``static_url``, e.g., ``request.static_url('<package>:static/foo.css')`` within +templates. + Adding routes to ``routes.py`` ============================== -This is the URL Dispatch tutorial and so let's start by adding some -URL patterns to our app. Later we'll attach views to handle the URLs. +This is the `URL Dispatch` tutorial, so let's start by adding some URL patterns +to our app. Later we'll attach views to handle the URLs. -The ``routes.py`` file contains -:meth:`pyramid.config.Configurator.add_route` calls which serve to add routes -to our application. 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. +The ``routes.py`` file contains :meth:`pyramid.config.Configurator.add_route` +calls which serve to add routes to our application. 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 then need to add four calls to ``add_route``. Note that the *ordering* of -these declarations is very important. ``route`` declarations are matched in -the order they're registered. +We then need to add four calls to ``add_route``. Note that the *ordering* of +these declarations is very important. Route declarations are matched in the +order they're registered. -#. Add a declaration which maps the pattern ``/`` (signifying the root URL) - to the route named ``view_wiki``. It maps to our ``view_wiki`` view - callable by virtue of the ``@view_config`` attached to the ``view_wiki`` - view function indicating ``route_name='view_wiki'``. +#. Add a declaration which maps the pattern ``/`` (signifying the root URL) to + the route named ``view_wiki``. In the next step, we will map it to our + ``view_wiki`` view callable by virtue of the ``@view_config`` decorator + attached to the ``view_wiki`` view function, which in turn will be indicated + by ``route_name='view_wiki'``. #. Add a declaration which maps the pattern ``/{pagename}`` to the route named - ``view_page``. This is the regular view for a page. It maps - to our ``view_page`` view callable by virtue of the ``@view_config`` - attached to the ``view_page`` view function indicating - ``route_name='view_page'``. + ``view_page``. This is the regular view for a page. Again, in the next step, + we will map it to our ``view_page`` view callable by virtue of the + ``@view_config`` decorator attached to the ``view_page`` view function, + whin in turn will be indicated by ``route_name='view_page'``. #. Add a declaration which maps the pattern ``/add_page/{pagename}`` to the - route named ``add_page``. This is the add view for a new page. It maps - to our ``add_page`` view callable by virtue of the ``@view_config`` - attached to the ``add_page`` view function indicating - ``route_name='add_page'``. + route named ``add_page``. This is the add view for a new page. We will map + it to our ``add_page`` view callable by virtue of the ``@view_config`` + decorator attached to the ``add_page`` view function, which in turn will be + indicated by ``route_name='add_page'``. #. Add a declaration which maps the pattern ``/{pagename}/edit_page`` to the - route named ``edit_page``. This is the edit view for a page. It maps + route named ``edit_page``. This is the edit view for a page. We will map it to our ``edit_page`` view callable by virtue of the ``@view_config`` - attached to the ``edit_page`` view function indicating - ``route_name='edit_page'``. + decorator attached to the ``edit_page`` view function, which in turn will be + indicated by ``route_name='edit_page'``. -As a result of our edits, the ``routes.py`` file should look something like: +As a result of our edits, the ``routes.py`` file should look like the +following: .. literalinclude:: src/views/tutorial/routes.py :linenos: @@ -103,13 +107,14 @@ The highlighted lines are the ones that need to be added or edited. .. warning:: The order of the routes is important! If you placed - ``/{pagename}/edit_page`` **before** ``/add_page/{pagename}`` then we would - never be able to add pages because the first route would always match - a request to ``/add_page/edit_page`` whereas we want ``/add_page/..`` to - have priority. This isn't a huge problem in this particular app because - wiki pages are always camel case but it's important to be aware of this + ``/{pagename}/edit_page`` *before* ``/add_page/{pagename}``, then we would + never be able to add pages. This is because the first route would always + match a request to ``/add_page/edit_page`` whereas we want ``/add_page/..`` + to have priority. This isn't a huge problem in this particular app because + wiki pages are always camel case, but it's important to be aware of this behavior in your own apps. + Adding view functions in ``views/default.py`` ============================================= @@ -131,23 +136,24 @@ and isn't relevant to our application. We also deleted the ``db_err_msg`` string. Then we added four :term:`view callable` functions to our ``views/default.py`` -module: +module, as mentioned in the previous step: * ``view_wiki()`` - Displays the wiki itself. It will answer on the root URL. * ``view_page()`` - Displays an individual page. -* ``add_page()`` - Allows the user to add a page. * ``edit_page()`` - Allows the user to edit a page. +* ``add_page()`` - Allows the user to add a page. We'll describe each one briefly in the following sections. .. note:: - There is nothing special about the filename ``default.py`` exept that - it is a Python module. A project may have many view callables throughout - its codebase in arbitrarily named modules. - Modules implementing view callables often have ``view`` in their name (or - may live in a Python subpackage of your application package named ``views``, - as in our case), but this is only by convention, not a requirement. + There is nothing special about the filename ``default.py`` exept that it is a + Python module. A project may have many view callables throughout its codebase + in arbitrarily named modules. Modules implementing view callables often have + ``view`` in their name (or may live in a Python subpackage of your + application package named ``views``, as in our case), but this is only by + convention, not a requirement. + The ``view_wiki`` view function ------------------------------- @@ -166,13 +172,14 @@ represents the path to our "FrontPage". The ``view_wiki`` view callable always redirects to the URL of a Page resource named "FrontPage". To do so, it returns an instance of the -:class:`pyramid.httpexceptions.HTTPFound` class (instances of which -implement the :class:`pyramid.interfaces.IResponse` interface, like -:class:`pyramid.response.Response` does). It uses the +:class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement +the :class:`pyramid.interfaces.IResponse` interface, like +:class:`pyramid.response.Response`). It uses the :meth:`pyramid.request.Request.route_url` API to construct a URL to the ``FrontPage`` page (i.e., ``http://localhost:6543/FrontPage``), and uses it as the "location" of the ``HTTPFound`` response, forming an HTTP redirect. + The ``view_page`` view function ------------------------------- @@ -201,7 +208,7 @@ 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 +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` @@ -209,22 +216,22 @@ associated with the view configuration to render a response. In our case, the renderer used will be the ``view.jinja2`` template, as indicated in the ``@view_config`` decorator that is applied to ``view_page()``. -If the page does not exist then we need to handle that by raising -:class:`pyramid.httpexceptions.HTTPNotFound`` to trigger our 404 handling +If the page does not exist, then we need to handle that by raising a +:class:`pyramid.httpexceptions.HTTPNotFound` to trigger our 404 handling, defined in ``tutorial/views/notfound.py``. .. note:: - Using ``raise`` versus ``return`` with the http exceptions is an important + Using ``raise`` versus ``return`` with the HTTP exceptions is an important distinction that can commonly mess people up. In ``tutorial/views/notfound.py`` there is an :term:`exception view` - registered for handling the ``HTTPNotFound`` exception. Exception views - are only triggered for raised exceptions. If the ``HTTPNotFound`` is - returned then it has an internal "stock" template that it will use - to render itself as a response. If you aren't seeing your exception - view being executed this is probably the problem! See - :ref:`special_exceptions_in_callables` for more information about - exception views. + registered for handling the ``HTTPNotFound`` exception. Exception views are + only triggered for raised exceptions. If the ``HTTPNotFound`` is returned, + then it has an internal "stock" template that it will use to render itself + as a response. If you aren't seeing your exception view being executed, this + is most likely the problem! See :ref:`special_exceptions_in_callables` for + more information about exception views. + The ``edit_page`` view function ------------------------------- @@ -237,11 +244,11 @@ Here is the code for the ``edit_page`` view function and its decorator: :linenos: :language: python -``edit_page()`` is 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 ``matchdict`` attribute of the -request passed to the ``edit_page`` view will have a ``'pagename'`` key -matching the name of the page the user wants to edit. +``edit_page()`` is 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 which it renders. The ``matchdict`` attribute of the request passed to the +``edit_page`` view will have a ``'pagename'`` key matching the name of the page +that the user wants to edit. If the view execution *is* a result of a form submission (i.e., the expression ``'form.submitted' in request.params`` is ``True``), the view grabs the @@ -257,12 +264,13 @@ which will be used as the action of the generated form. .. note:: Since our ``request.dbsession`` defined in the previous chapter is - registered with the ``pyramid_tm`` transaction manager any changes we make - to objects managed by the that session will be committed automatically. - In the event that there was an error (even later, in our template code) the + registered with the ``pyramid_tm`` transaction manager, any changes we make + to objects managed by the that session will be committed automatically. In + the event that there was an error (even later, in our template code), the changes would be aborted. This means the view itself does not need to concern itself with commit/rollback logic. + The ``add_page`` view function ------------------------------ @@ -274,27 +282,26 @@ Here is the code for the ``add_page`` view function and its decorator: :linenos: :language: python -``add_page()`` is invoked when a user clicks on a *WikiWord* which -isn't yet represented as a page in the system. The ``add_link`` function -within the ``view_page`` view generates URLs to this view. -``add_page()`` also acts as a handler for the form that is generated -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. +``add_page()`` is invoked when a user clicks on a *WikiWord* which isn't yet +represented as a page in the system. The ``add_link`` function within the +``view_page`` view generates URLs to this view. ``add_page()`` also acts as a +handler for the form that is generated 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 ``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 value for -``'pagename'`` in the ``matchdict`` will be ``'SomeName'``. +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, for example, +``http://localhost:6543/add_page/SomeName``, the value for ``'pagename'`` in +the ``matchdict`` will be ``'SomeName'``. If the view execution *is* a result of a form submission (i.e., the expression -``'form.submitted' in request.params`` is ``True``), we grab the page body -from the form data, create a Page object with this page body and the name -taken from ``matchdict['pagename']``, and save it into the database using -``request.dbession.add``. Since we have not yet covered authentication we -don't have a logged-in user to add as the page's ``creator``. Until we -get to that point in the tutorial we'll just assume that all pages are created -by the ``editor`` user so we query that object and set it on ``page.creator``. +``'form.submitted' in request.params`` is ``True``), we grab the page body from +the form data, create a Page object with this page body and the name taken from +``matchdict['pagename']``, and save it into the database using +``request.dbession.add``. Since we have not yet covered authentication, we +don't have a logged-in user to add as the page's ``creator``. Until we get to +that point in the tutorial, we'll just assume that all pages are created by the +``editor`` user. Thus we query for that object, and set it on ``page.creator``. Finally, we redirect the client back to the ``view_page`` view for the newly created page. @@ -308,6 +315,7 @@ in order to satisfy the edit form's desire to have *some* page object exposed as ``page``. :app:`Pyramid` will render the template associated with this view to a response. + Adding templates ================ @@ -317,25 +325,28 @@ These templates will live in the ``templates`` directory of our tutorial package. Jinja2 templates must have a ``.jinja2`` extension to be recognized as such. + The ``layout.jinja2`` template ------------------------------ -Replace ``tutorial/templates/layout.jinja2`` with the following content: +Update ``tutorial/templates/layout.jinja2`` with the following content, as +indicated by the emphasized lines: .. literalinclude:: src/views/tutorial/templates/layout.jinja2 :linenos: :emphasize-lines: 11,36 :language: html -Since we're using a templating engine we can factor common boilerplate out of -our page templates into reusable components. One method for doing this -is template inheritance via blocks. +Since we're using a templating engine, we can factor common boilerplate out of +our page templates into reusable components. One method for doing this is +template inheritance via blocks. + +- We have defined two placeholders in the layout template where a child + template can override the content. These blocks are named ``subtitle`` (line + 11) and ``content`` (line 36). +- Please refer to the Jinja2_ documentation for more information about template + inheritance. -- We have defined 2 placeholders in the layout template where a child template - can override the content. These blocks are named ``subtitle`` (line 11) and - ``content`` (line 36). -- Please refer to the Jinja2_ documentation for more information about - template inheritance. The ``view.jinja2`` template ---------------------------- @@ -344,23 +355,22 @@ Create ``tutorial/templates/view.jinja2`` and add the following content: .. literalinclude:: src/views/tutorial/templates/view.jinja2 :linenos: - :emphasize-lines: 1,3,6 :language: html This template is used by ``view_page()`` for displaying a single wiki page. -It includes: -- We begin by extending the ``layout.jinja2`` template defined above - which provides the skeleton of the page (line 1). -- We override the ``subtitle`` block from the base layout to insert the - page name of the page into the page's title (line 3). +- We begin by extending the ``layout.jinja2`` template defined above, which + provides the skeleton of the page (line 1). +- We override the ``subtitle`` block from the base layout, inserting the page + name into the page's title (line 3). - We override the ``content`` block from the base layout to insert our markup - into the body (line 5-18). -- A variable that is replaced with the ``content`` value provided by the view - (line 6). ``content`` contains HTML, so the ``|safe`` filter is used to + into the body (lines 5-18). +- We use a variable that is replaced with the ``content`` value provided by the + view (line 6). ``content`` contains HTML, so the ``|safe`` filter is used to prevent escaping it (e.g., changing ">" to ">"). -- A link that points at the "edit" URL which invokes the ``edit_page`` view for - the page being viewed (line 9). +- We create a link that points at the "edit" URL, which when clicked invokes + the ``edit_page`` view for the requested page (line 9). + The ``edit.jinja2`` template ---------------------------- @@ -369,23 +379,23 @@ Create ``tutorial/templates/edit.jinja2`` and add the following content: .. literalinclude:: src/views/tutorial/templates/edit.jinja2 :linenos: - :emphasize-lines: 3,12,14,17 + :emphasize-lines: 1,3,12,14,17 :language: html -This template serves two use-cases. It is used by ``add_page()`` and +This template serves two use cases. It is used by ``add_page()`` and ``edit_page()`` for adding and editing a wiki page. It displays a page -containing a form that includes: +containing a form and which provides the following: -- Again, we are extending the ``layout.jinja2`` template which provides - the skeleton of the page (line 1). +- Again, we extend the ``layout.jinja2`` template, which provides the skeleton + of the page (line 1). - Override the ``subtitle`` block to affect the ``<title>`` tag in the ``head`` of the page (line 3). - A 10-row by 60-column ``textarea`` field named ``body`` that is filled with any existing page data when it is rendered (line 14). - A submit button that has the name ``form.submitted`` (line 17). +- The form POSTs back to the ``save_url`` argument supplied by the view (line + 12). The view will use the ``body`` and ``form.submitted`` values. -The form POSTs back to the ``save_url`` argument supplied by the view (line -12). The view will use the ``body`` and ``form.submitted`` values. The ``404.jinja2`` template --------------------------- @@ -419,9 +429,9 @@ There are several important things to note about this configuration: ``tutorial/views/default.py`` the exception is raised which will trigger the view. -Finally, you may delete the ``tutorial/templates/mytemplate.jinja2`` -template that was provided by the ``alchemy`` scaffold as we have created -our own templates for the wiki. +Finally, we may delete the ``tutorial/templates/mytemplate.jinja2`` template +that was provided by the ``alchemy`` scaffold, as we have created our own +templates for the wiki. .. note:: @@ -431,6 +441,7 @@ our own templates for the wiki. See :ref:`renderer_system_values` for information about other names that are available by default when a template is used as a renderer. + Viewing the application in a browser ==================================== -- cgit v1.2.3 From 3e30040da7c2d5c38b330727b48d9f6b852956d9 Mon Sep 17 00:00:00 2001 From: Steve Piercy <web@stevepiercy.com> Date: Sun, 28 Feb 2016 22:30:22 -0800 Subject: redirect to edit page when user attempts to add page that already exists - update src/*/views/default.py - update src/*/routes.py - write new test - revise docs, double-checking line counts and highlighting --- docs/tutorials/wiki2/definingviews.rst | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index e48980dc8..b0cbe7dc4 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -124,7 +124,7 @@ edit it to look like the following: .. literalinclude:: src/views/tutorial/views/default.py :linenos: :language: python - :emphasize-lines: 1-9,12-70 + :emphasize-lines: 1-9,12- The highlighted lines need to be added or edited. @@ -277,7 +277,7 @@ The ``add_page`` view function Here is the code for the ``add_page`` view function and its decorator: .. literalinclude:: src/views/tutorial/views/default.py - :lines: 58-70 + :lines: 58- :lineno-match: :linenos: :language: python @@ -294,6 +294,10 @@ page we'd like to add. If our add view is invoked via, for example, ``http://localhost:6543/add_page/SomeName``, the value for ``'pagename'`` in the ``matchdict`` will be ``'SomeName'``. +Next a check is performed to determine whether the ``Page`` already exists in +the database. If it already exists, then the client is redirected to the +``edit_page`` view, else we continue to the next check. + If the view execution *is* a result of a form submission (i.e., the expression ``'form.submitted' in request.params`` is ``True``), we grab the page body from the form data, create a Page object with this page body and the name taken from @@ -452,13 +456,18 @@ each of the following URLs, checking that the result is as expected: - http://localhost:6543/ invokes the ``view_wiki`` view. This always redirects to the ``view_page`` view of the ``FrontPage`` page object. -- http://localhost:6543/FrontPage invokes the ``view_page`` view of the front - page object. +- http://localhost:6543/FrontPage invokes the ``view_page`` view of the + ``FrontPage`` page object. + +- http://localhost:6543/FrontPage/edit_page invokes the ``edit_page`` view for + the ``FrontPage`` page object. -- http://localhost:6543/FrontPage/edit_page invokes the edit view for the - front page object. +- http://localhost:6543/add_page/SomePageName invokes the ``add_page`` view for + a page. If the page already exists, then it redirects the user to the + ``edit_page`` view for the page object. -- http://localhost:6543/add_page/SomePageName invokes the add view for a page. +- http://localhost:6543/SomePageName/edit_page invokes the ``edit_page`` view + for an existing page, or generates an error if the page does not exist. - To generate an error, visit http://localhost:6543/foobars/edit_page which will generate a ``NoResultFound: No row was found for one()`` error. You'll -- cgit v1.2.3 From cf733e9613ecff104acf561589abdc9ff64be2ee Mon Sep 17 00:00:00 2001 From: Steve Piercy <web@stevepiercy.com> Date: Sat, 9 Apr 2016 13:26:52 -0700 Subject: - update wiki2 definingviews --- docs/tutorials/wiki2/definingviews.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index b0cbe7dc4..1083eca0e 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -36,7 +36,7 @@ Open ``tutorial/setup.py`` and edit it to look like the following: Only the highlighted line needs to be added. Again, as we did in the previous chapter, the dependency now needs to be -installed, so re-run the ``python setup.py develop`` command. +installed, so re-run the ``$VENV/bin/pip install -e .`` command. Static assets @@ -338,7 +338,7 @@ indicated by the emphasized lines: .. literalinclude:: src/views/tutorial/templates/layout.jinja2 :linenos: - :emphasize-lines: 11,36 + :emphasize-lines: 11,35-36 :language: html Since we're using a templating engine, we can factor common boilerplate out of -- cgit v1.2.3 From 640d7779b69f49ab11d7e276a7548684524bc215 Mon Sep 17 00:00:00 2001 From: Steve Piercy <web@stevepiercy.com> Date: Sat, 9 Apr 2016 13:36:11 -0700 Subject: - add intersphinx targets --- docs/tutorials/wiki2/definingviews.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'docs/tutorials/wiki2/definingviews.rst') diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index 1083eca0e..996bff88c 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -1,3 +1,5 @@ +.. _wiki2_defining_views: + ============== Defining Views ============== -- cgit v1.2.3