07: Basic Web Handling With Views
Organize a views module with decorators and multiple views.
For the examples so far, the hello_world function is a "view". In Pyramid, views are the primary way to accept web requests and return responses.
So far our examples place everything in one file:
- The view function
- Its registration with the configurator
- The route to map it to a URL
- The WSGI application launcher
Let's move the views out to their own views.py module and change our startup code to scan that module, looking for decorators that setup the views. Let's also add a second view and update our tests.
- Views in a module that is scanned by the configurator
- Decorators that do declarative configuration
Let's begin by using the previous package as a starting point for a new distribution, then making it active:
$ cd ..; cp -r functional_testing views; cd views $ $VENV/bin/python setup.py develop
Our views/tutorial/__init__.py gets a lot shorter:
Let's add a module views/tutorial/views.py that is focused on handling requests and responses:
Update the tests to cover the two new views:
Now run the tests:
$ $VENV/bin/nosetests tutorial . ---------------------------------------------------------------------- Ran 4 tests in 0.141s OK
Run your Pyramid application with:
$ $VENV/bin/pserve development.ini --reload
We added some more URLs, but we also removed the view code from the application startup code in tutorial/__init__.py. Our views, and their view registrations (via decorators) are now in a module views.py which is scanned via config.scan('.views').
We have 2 views, each leading to the other. If you start at http://localhost:6543/, you get a response with a link to the next view. The hello_view (available at the URL /howdy) has a link back to the first view.
This step also shows that the name appearing in the URL, the name of the "route" that maps a URL to a view, and the name of the view, can all be different. More on routes later.
Earlier we saw config.add_view as one way to configure a view. This section introduces @view_config. Pyramid's configuration supports :term:`imperative configuration`, such as the config.add_view in the previous example. You can also use :term:`declarative configuration`, in which a Python :term:`python:decorator` is placed on the line above the view. Both approaches result in the same final configuration, thus usually, it is simply a matter of taste.
- What does the dot in .views signify?
- Why might assertIn be a better choice in testing the text in responses than assertEqual?