Chapter 11 ■ the World Wide Web
210
The fields of the payment form, because the form gets written out as HTML and then pulled back in from the
POST parameters, are simply gone. As requested, it has left the debit field unspecified so that the code can fill it in
with the current username. But the Django forms library is taking care of everything else for you.
The one awkwardness is that a bit of logic that really belongs in the template—the choice of words and
presentation surrounding the display of payments on the main page—has now had to move into the Python code
because the Django template system did not make the logic as easy to express. But Python makes the alternative fairly
easy for you: the index() view calls a generator that produces a dict of information about each payment, converting
the raw object into the values in which the template will be interested.
Some programmers chafe at such an underpowered template system. Others learn how to write Django
“template tags” that let them invoke bits of their own logic from deep within a template. Still other developers argue
that code like Listing 11-11 is best in the long run anyway because it is easier to write tests for a routine such as
make_payment_views() than for logic stranded inside a template.
To run this Django application, check out the Chapter 11 source code from the link given earlier, install
Django 1.7 under Python 3, and run these three commands:
$ python manage.py syncdb
$ python manage.py loaddata start
$ python manage.py runserver
With the last command up and running, you can visit http://localhost:8000/ and see how Django has let you
construct much the same application that was built with Flask earlier in this chapter.
Choosing a Web Framework
The web framework landscape is always innovating in a strong and healthy community like the Python programming
language. Although it will probably make this book look dated in just a few short years, here is a quick survey of the
most popular frameworks in order to give you a flavor for the choices facing a typical developer:
• Django: A good framework for the first-time web programmer. Features such as CSRF
protection are built in. Its ORM and template language are built in. Not only does this relieve
the amateur from having to choose separate libraries of their own, but it means that all third-
party Django tools can assume a common set of interfaces for dealing with both HTML and
the database. Django is famous for its admin interface—try visiting the /admin page after
running Listing 11-11 to see an example of how administrators can interact directly with the
database through autogenerated create, edit, and delete forms!• Tornado: A web framework like none of the others listed here because it uses the
asynchronous callback pattern from Chapter 9 to allow many dozens or hundreds of client
connections to be supported per operating system thread, instead of just one client per
thread. It also stands out because it is not tied to supporting WSGI—it has direct support for
WebSockets (described in the next section). The cost is that many libraries have difficulty
working with its callback pattern, so the programmer has to find async alternatives to the
usual ORM or database connector that they would choose.• Flask: The most popular of the microframeworks, built atop solid tools and supporting many
modern features (if the programmer knows to look for and take advantage of them). Often
combined with SQLAlchemy or a nonrelational database back end.• Bottle: An alternative to Flask that fits in a single file bottle.py instead of requiring several
separate packages to be installed. Especially attractive to developers who have not yet worked
the pip install tool into their workflow. Its template language is particularly well designed.