Issue #24852: Remove outdated "HOWTO Use Python in the web" document
This commit is contained in:
Berker Peksag
commit
f1fc8f953e
|
|
@ -25,7 +25,6 @@ Currently, the HOWTOs are:
|
|||
sorting.rst
|
||||
unicode.rst
|
||||
urllib2.rst
|
||||
webservers.rst
|
||||
argparse.rst
|
||||
ipaddress.rst
|
||||
clinic.rst
|
||||
|
|
|
|||
|
|
@ -1,731 +0,0 @@
|
|||
*******************************
|
||||
HOWTO Use Python in the web
|
||||
*******************************
|
||||
|
||||
:Author: Marek Kubica
|
||||
|
||||
.. topic:: Abstract
|
||||
|
||||
This document shows how Python fits into the web. It presents some ways
|
||||
to integrate Python with a web server, and general practices useful for
|
||||
developing web sites.
|
||||
|
||||
|
||||
Programming for the Web has become a hot topic since the rise of "Web 2.0",
|
||||
which focuses on user-generated content on web sites. It has always been
|
||||
possible to use Python for creating web sites, but it was a rather tedious task.
|
||||
Therefore, many frameworks and helper tools have been created to assist
|
||||
developers in creating faster and more robust sites. This HOWTO describes
|
||||
some of the methods used to combine Python with a web server to create
|
||||
dynamic content. It is not meant as a complete introduction, as this topic is
|
||||
far too broad to be covered in one single document. However, a short overview
|
||||
of the most popular libraries is provided.
|
||||
|
||||
.. seealso::
|
||||
|
||||
While this HOWTO tries to give an overview of Python in the web, it cannot
|
||||
always be as up to date as desired. Web development in Python is rapidly
|
||||
moving forward, so the wiki page on `Web Programming
|
||||
<https://wiki.python.org/moin/WebProgramming>`_ may be more in sync with
|
||||
recent development.
|
||||
|
||||
|
||||
The Low-Level View
|
||||
==================
|
||||
|
||||
When a user enters a web site, their browser makes a connection to the site's
|
||||
web server (this is called the *request*). The server looks up the file in the
|
||||
file system and sends it back to the user's browser, which displays it (this is
|
||||
the *response*). This is roughly how the underlying protocol, HTTP, works.
|
||||
|
||||
Dynamic web sites are not based on files in the file system, but rather on
|
||||
programs which are run by the web server when a request comes in, and which
|
||||
*generate* the content that is returned to the user. They can do all sorts of
|
||||
useful things, like display the postings of a bulletin board, show your email,
|
||||
configure software, or just display the current time. These programs can be
|
||||
written in any programming language the server supports. Since most servers
|
||||
support Python, it is easy to use Python to create dynamic web sites.
|
||||
|
||||
Most HTTP servers are written in C or C++, so they cannot execute Python code
|
||||
directly -- a bridge is needed between the server and the program. These
|
||||
bridges, or rather interfaces, define how programs interact with the server.
|
||||
There have been numerous attempts to create the best possible interface, but
|
||||
there are only a few worth mentioning.
|
||||
|
||||
Not every web server supports every interface. Many web servers only support
|
||||
old, now-obsolete interfaces; however, they can often be extended using
|
||||
third-party modules to support newer ones.
|
||||
|
||||
|
||||
Common Gateway Interface
|
||||
------------------------
|
||||
|
||||
This interface, most commonly referred to as "CGI", is the oldest, and is
|
||||
supported by nearly every web server out of the box. Programs using CGI to
|
||||
communicate with their web server need to be started by the server for every
|
||||
request. So, every request starts a new Python interpreter -- which takes some
|
||||
time to start up -- thus making the whole interface only usable for low load
|
||||
situations.
|
||||
|
||||
The upside of CGI is that it is simple -- writing a Python program which uses
|
||||
CGI is a matter of about three lines of code. This simplicity comes at a
|
||||
price: it does very few things to help the developer.
|
||||
|
||||
Writing CGI programs, while still possible, is no longer recommended. With
|
||||
:ref:`WSGI <WSGI>`, a topic covered later in this document, it is possible to write
|
||||
programs that emulate CGI, so they can be run as CGI if no better option is
|
||||
available.
|
||||
|
||||
.. seealso::
|
||||
|
||||
The Python standard library includes some modules that are helpful for
|
||||
creating plain CGI programs:
|
||||
|
||||
* :mod:`cgi` -- Handling of user input in CGI scripts
|
||||
* :mod:`cgitb` -- Displays nice tracebacks when errors happen in CGI
|
||||
applications, instead of presenting a "500 Internal Server Error" message
|
||||
|
||||
The Python wiki features a page on `CGI scripts
|
||||
<https://wiki.python.org/moin/CgiScripts>`_ with some additional information
|
||||
about CGI in Python.
|
||||
|
||||
|
||||
Simple script for testing CGI
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To test whether your web server works with CGI, you can use this short and
|
||||
simple CGI program::
|
||||
|
||||
#!/usr/bin/env python
|
||||
# -*- coding: UTF-8 -*-
|
||||
|
||||
# enable debugging
|
||||
import cgitb
|
||||
cgitb.enable()
|
||||
|
||||
print("Content-Type: text/plain;charset=utf-8")
|
||||
print()
|
||||
|
||||
print("Hello World!")
|
||||
|
||||
Depending on your web server configuration, you may need to save this code with
|
||||
a ``.py`` or ``.cgi`` extension. Additionally, this file may also need to be
|
||||
in a ``cgi-bin`` folder, for security reasons.
|
||||
|
||||
You might wonder what the ``cgitb`` line is about. This line makes it possible
|
||||
to display a nice traceback instead of just crashing and displaying an "Internal
|
||||
Server Error" in the user's browser. This is useful for debugging, but it might
|
||||
risk exposing some confidential data to the user. You should not use ``cgitb``
|
||||
in production code for this reason. You should *always* catch exceptions, and
|
||||
display proper error pages -- end-users don't like to see nondescript "Internal
|
||||
Server Errors" in their browsers.
|
||||
|
||||
|
||||
Setting up CGI on your own server
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you don't have your own web server, this does not apply to you. You can
|
||||
check whether it works as-is, and if not you will need to talk to the
|
||||
administrator of your web server. If it is a big host, you can try filing a
|
||||
ticket asking for Python support.
|
||||
|
||||
If you are your own administrator or want to set up CGI for testing purposes on
|
||||
your own computers, you have to configure it by yourself. There is no single
|
||||
way to configure CGI, as there are many web servers with different
|
||||
configuration options. Currently the most widely used free web server is
|
||||
`Apache HTTPd <http://httpd.apache.org/>`_, or Apache for short. Apache can be
|
||||
easily installed on nearly every system using the system's package management
|
||||
tool. `lighttpd <http://www.lighttpd.net>`_ is another alternative and is
|
||||
said to have better performance. On many systems this server can also be
|
||||
installed using the package management tool, so manually compiling the web
|
||||
server may not be needed.
|
||||
|
||||
* On Apache you can take a look at the `Dynamic Content with CGI
|
||||
<http://httpd.apache.org/docs/2.2/howto/cgi.html>`_ tutorial, where everything
|
||||
is described. Most of the time it is enough just to set ``+ExecCGI``. The
|
||||
tutorial also describes the most common gotchas that might arise.
|
||||
|
||||
* On lighttpd you need to use the `CGI module
|
||||
<http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModCGI>`_\ , which can be configured
|
||||
in a straightforward way. It boils down to setting ``cgi.assign`` properly.
|
||||
|
||||
|
||||
Common problems with CGI scripts
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Using CGI sometimes leads to small annoyances while trying to get these
|
||||
scripts to run. Sometimes a seemingly correct script does not work as
|
||||
expected, the cause being some small hidden problem that's difficult to spot.
|
||||
|
||||
Some of these potential problems are:
|
||||
|
||||
* The Python script is not marked as executable. When CGI scripts are not
|
||||
executable most web servers will let the user download it, instead of
|
||||
running it and sending the output to the user. For CGI scripts to run
|
||||
properly on Unix-like operating systems, the ``+x`` bit needs to be set.
|
||||
Using ``chmod a+x your_script.py`` may solve this problem.
|
||||
|
||||
* On a Unix-like system, The line endings in the program file must be Unix
|
||||
style line endings. This is important because the web server checks the
|
||||
first line of the script (called shebang) and tries to run the program
|
||||
specified there. It gets easily confused by Windows line endings (Carriage
|
||||
Return & Line Feed, also called CRLF), so you have to convert the file to
|
||||
Unix line endings (only Line Feed, LF). This can be done automatically by
|
||||
uploading the file via FTP in text mode instead of binary mode, but the
|
||||
preferred way is just telling your editor to save the files with Unix line
|
||||
endings. Most editors support this.
|
||||
|
||||
* Your web server must be able to read the file, and you need to make sure the
|
||||
permissions are correct. On unix-like systems, the server often runs as user
|
||||
and group ``www-data``, so it might be worth a try to change the file
|
||||
ownership, or making the file world readable by using ``chmod a+r
|
||||
your_script.py``.
|
||||
|
||||
* The web server must know that the file you're trying to access is a CGI script.
|
||||
Check the configuration of your web server, as it may be configured
|
||||
to expect a specific file extension for CGI scripts.
|
||||
|
||||
* On Unix-like systems, the path to the interpreter in the shebang
|
||||
(``#!/usr/bin/env python``) must be correct. This line calls
|
||||
``/usr/bin/env`` to find Python, but it will fail if there is no
|
||||
``/usr/bin/env``, or if Python is not in the web server's path. If you know
|
||||
where your Python is installed, you can also use that full path. The
|
||||
commands ``whereis python`` and ``type -p python`` could help you find
|
||||
where it is installed. Once you know the path, you can change the shebang
|
||||
accordingly: ``#!/usr/bin/python``.
|
||||
|
||||
* The file must not contain a BOM (Byte Order Mark). The BOM is meant for
|
||||
determining the byte order of UTF-16 and UTF-32 encodings, but some editors
|
||||
write this also into UTF-8 files. The BOM interferes with the shebang line,
|
||||
so be sure to tell your editor not to write the BOM.
|
||||
|
||||
* If the web server is using :ref:`mod-python`, ``mod_python`` may be having
|
||||
problems. ``mod_python`` is able to handle CGI scripts by itself, but it can
|
||||
also be a source of issues.
|
||||
|
||||
|
||||
.. _mod-python:
|
||||
|
||||
mod_python
|
||||
----------
|
||||
|
||||
People coming from PHP often find it hard to grasp how to use Python in the web.
|
||||
Their first thought is mostly `mod_python <http://modpython.org/>`_\ ,
|
||||
because they think that this is the equivalent to ``mod_php``. Actually, there
|
||||
are many differences. What ``mod_python`` does is embed the interpreter into
|
||||
the Apache process, thus speeding up requests by not having to start a Python
|
||||
interpreter for each request. On the other hand, it is not "Python intermixed
|
||||
with HTML" in the way that PHP is often intermixed with HTML. The Python
|
||||
equivalent of that is a template engine. ``mod_python`` itself is much more
|
||||
powerful and provides more access to Apache internals. It can emulate CGI,
|
||||
work in a "Python Server Pages" mode (similar to JSP) which is "HTML
|
||||
intermingled with Python", and it has a "Publisher" which designates one file
|
||||
to accept all requests and decide what to do with them.
|
||||
|
||||
``mod_python`` does have some problems. Unlike the PHP interpreter, the Python
|
||||
interpreter uses caching when executing files, so changes to a file will
|
||||
require the web server to be restarted. Another problem is the basic concept
|
||||
-- Apache starts child processes to handle the requests, and unfortunately
|
||||
every child process needs to load the whole Python interpreter even if it does
|
||||
not use it. This makes the whole web server slower. Another problem is that,
|
||||
because ``mod_python`` is linked against a specific version of ``libpython``,
|
||||
it is not possible to switch from an older version to a newer (e.g. 2.4 to 2.5)
|
||||
without recompiling ``mod_python``. ``mod_python`` is also bound to the Apache
|
||||
web server, so programs written for ``mod_python`` cannot easily run on other
|
||||
web servers.
|
||||
|
||||
These are the reasons why ``mod_python`` should be avoided when writing new
|
||||
programs. In some circumstances it still might be a good idea to use
|
||||
``mod_python`` for deployment, but WSGI makes it possible to run WSGI programs
|
||||
under ``mod_python`` as well.
|
||||
|
||||
|
||||
FastCGI and SCGI
|
||||
----------------
|
||||
|
||||
FastCGI and SCGI try to solve the performance problem of CGI in another way.
|
||||
Instead of embedding the interpreter into the web server, they create
|
||||
long-running background processes. There is still a module in the web server
|
||||
which makes it possible for the web server to "speak" with the background
|
||||
process. As the background process is independent of the server, it can be
|
||||
written in any language, including Python. The language just needs to have a
|
||||
library which handles the communication with the webserver.
|
||||
|
||||
The difference between FastCGI and SCGI is very small, as SCGI is essentially
|
||||
just a "simpler FastCGI". As the web server support for SCGI is limited,
|
||||
most people use FastCGI instead, which works the same way. Almost everything
|
||||
that applies to SCGI also applies to FastCGI as well, so we'll only cover
|
||||
the latter.
|
||||
|
||||
These days, FastCGI is never used directly. Just like ``mod_python``, it is only
|
||||
used for the deployment of WSGI applications.
|
||||
|
||||
|
||||
Setting up FastCGI
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Each web server requires a specific module.
|
||||
|
||||
* Apache has both `mod_fastcgi <http://www.fastcgi.com/drupal/>`_ and `mod_fcgid
|
||||
<https://httpd.apache.org/mod_fcgid/>`_. ``mod_fastcgi`` is the original one, but it
|
||||
has some licensing issues, which is why it is sometimes considered non-free.
|
||||
``mod_fcgid`` is a smaller, compatible alternative. One of these modules needs
|
||||
to be loaded by Apache.
|
||||
|
||||
* lighttpd ships its own `FastCGI module
|
||||
<http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModFastCGI>`_ as well as an
|
||||
`SCGI module <http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModSCGI>`_.
|
||||
|
||||
* `nginx <http://nginx.org/>`_ also supports `FastCGI
|
||||
<https://www.nginx.com/resources/wiki/start/topics/examples/simplepythonfcgi/>`_.
|
||||
|
||||
Once you have installed and configured the module, you can test it with the
|
||||
following WSGI-application::
|
||||
|
||||
#!/usr/bin/env python
|
||||
# -*- coding: UTF-8 -*-
|
||||
|
||||
import sys, os
|
||||
from html import escape
|
||||
from flup.server.fcgi import WSGIServer
|
||||
|
||||
def app(environ, start_response):
|
||||
start_response('200 OK', [('Content-Type', 'text/html')])
|
||||
|
||||
yield '<h1>FastCGI Environment</h1>'
|
||||
yield '<table>'
|
||||
for k, v in sorted(environ.items()):
|
||||
yield '<tr><th>{0}</th><td>{1}</td></tr>'.format(
|
||||
escape(k), escape(v))
|
||||
yield '</table>'
|
||||
|
||||
WSGIServer(app).run()
|
||||
|
||||
This is a simple WSGI application, but you need to install `flup
|
||||
<https://pypi.python.org/pypi/flup/1.0>`_ first, as flup handles the low level
|
||||
FastCGI access.
|
||||
|
||||
.. seealso::
|
||||
|
||||
There is some documentation on `setting up Django with WSGI
|
||||
<https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/>`_, most of
|
||||
which can be reused for other WSGI-compliant frameworks and libraries.
|
||||
Only the ``manage.py`` part has to be changed, the example used here can be
|
||||
used instead. Django does more or less the exact same thing.
|
||||
|
||||
|
||||
mod_wsgi
|
||||
--------
|
||||
|
||||
`mod_wsgi <http://code.google.com/p/modwsgi/>`_ is an attempt to get rid of the
|
||||
low level gateways. Given that FastCGI, SCGI, and mod_python are mostly used to
|
||||
deploy WSGI applications, mod_wsgi was started to directly embed WSGI applications
|
||||
into the Apache web server. mod_wsgi is specifically designed to host WSGI
|
||||
applications. It makes the deployment of WSGI applications much easier than
|
||||
deployment using other low level methods, which need glue code. The downside
|
||||
is that mod_wsgi is limited to the Apache web server; other servers would need
|
||||
their own implementations of mod_wsgi.
|
||||
|
||||
mod_wsgi supports two modes: embedded mode, in which it integrates with the
|
||||
Apache process, and daemon mode, which is more FastCGI-like. Unlike FastCGI,
|
||||
mod_wsgi handles the worker-processes by itself, which makes administration
|
||||
easier.
|
||||
|
||||
|
||||
.. _WSGI:
|
||||
|
||||
Step back: WSGI
|
||||
===============
|
||||
|
||||
WSGI has already been mentioned several times, so it has to be something
|
||||
important. In fact it really is, and now it is time to explain it.
|
||||
|
||||
The *Web Server Gateway Interface*, or WSGI for short, is defined in
|
||||
:pep:`333` and is currently the best way to do Python web programming. While
|
||||
it is great for programmers writing frameworks, a normal web developer does not
|
||||
need to get in direct contact with it. When choosing a framework for web
|
||||
development it is a good idea to choose one which supports WSGI.
|
||||
|
||||
The big benefit of WSGI is the unification of the application programming
|
||||
interface. When your program is compatible with WSGI -- which at the outer
|
||||
level means that the framework you are using has support for WSGI -- your
|
||||
program can be deployed via any web server interface for which there are WSGI
|
||||
wrappers. You do not need to care about whether the application user uses
|
||||
mod_python or FastCGI or mod_wsgi -- with WSGI your application will work on
|
||||
any gateway interface. The Python standard library contains its own WSGI
|
||||
server, :mod:`wsgiref`, which is a small web server that can be used for
|
||||
testing.
|
||||
|
||||
A really great WSGI feature is middleware. Middleware is a layer around your
|
||||
program which can add various functionality to it. There is quite a bit of
|
||||
`middleware <https://wsgi.readthedocs.org/en/latest/libraries.html>`_ already
|
||||
available. For example, instead of writing your own session management (HTTP
|
||||
is a stateless protocol, so to associate multiple HTTP requests with a single
|
||||
user your application must create and manage such state via a session), you can
|
||||
just download middleware which does that, plug it in, and get on with coding
|
||||
the unique parts of your application. The same thing with compression -- there
|
||||
is existing middleware which handles compressing your HTML using gzip to save
|
||||
on your server's bandwidth. Authentication is another a problem easily solved
|
||||
using existing middleware.
|
||||
|
||||
Although WSGI may seem complex, the initial phase of learning can be very
|
||||
rewarding because WSGI and the associated middleware already have solutions to
|
||||
many problems that might arise while developing web sites.
|
||||
|
||||
|
||||
WSGI Servers
|
||||
------------
|
||||
|
||||
The code that is used to connect to various low level gateways like CGI or
|
||||
mod_python is called a *WSGI server*. One of these servers is ``flup``, which
|
||||
supports FastCGI and SCGI, as well as `AJP
|
||||
<https://en.wikipedia.org/wiki/Apache_JServ_Protocol>`_. Some of these servers
|
||||
are written in Python, as ``flup`` is, but there also exist others which are
|
||||
written in C and can be used as drop-in replacements.
|
||||
|
||||
There are many servers already available, so a Python web application
|
||||
can be deployed nearly anywhere. This is one big advantage that Python has
|
||||
compared with other web technologies.
|
||||
|
||||
.. seealso::
|
||||
|
||||
A good overview of WSGI-related code can be found in the `WSGI homepage
|
||||
<https://wsgi.readthedocs.org/>`_, which contains an extensive list of `WSGI servers
|
||||
<https://wsgi.readthedocs.org/en/latest/servers.html>`_ which can be used by *any* application
|
||||
supporting WSGI.
|
||||
|
||||
You might be interested in some WSGI-supporting modules already contained in
|
||||
the standard library, namely:
|
||||
|
||||
* :mod:`wsgiref` -- some tiny utilities and servers for WSGI
|
||||
|
||||
|
||||
Case study: MoinMoin
|
||||
--------------------
|
||||
|
||||
What does WSGI give the web application developer? Let's take a look at
|
||||
an application that's been around for a while, which was written in
|
||||
Python without using WSGI.
|
||||
|
||||
One of the most widely used wiki software packages is `MoinMoin
|
||||
<https://moinmo.in/>`_. It was created in 2000, so it predates WSGI by about
|
||||
three years. Older versions needed separate code to run on CGI, mod_python,
|
||||
FastCGI and standalone.
|
||||
|
||||
It now includes support for WSGI. Using WSGI, it is possible to deploy
|
||||
MoinMoin on any WSGI compliant server, with no additional glue code.
|
||||
Unlike the pre-WSGI versions, this could include WSGI servers that the
|
||||
authors of MoinMoin know nothing about.
|
||||
|
||||
|
||||
Model-View-Controller
|
||||
=====================
|
||||
|
||||
The term *MVC* is often encountered in statements such as "framework *foo*
|
||||
supports MVC". MVC is more about the overall organization of code, rather than
|
||||
any particular API. Many web frameworks use this model to help the developer
|
||||
bring structure to their program. Bigger web applications can have lots of
|
||||
code, so it is a good idea to have an effective structure right from the beginning.
|
||||
That way, even users of other frameworks (or even other languages, since MVC is
|
||||
not Python-specific) can easily understand the code, given that they are
|
||||
already familiar with the MVC structure.
|
||||
|
||||
MVC stands for three components:
|
||||
|
||||
* The *model*. This is the data that will be displayed and modified. In
|
||||
Python frameworks, this component is often represented by the classes used by
|
||||
an object-relational mapper.
|
||||
|
||||
* The *view*. This component's job is to display the data of the model to the
|
||||
user. Typically this component is implemented via templates.
|
||||
|
||||
* The *controller*. This is the layer between the user and the model. The
|
||||
controller reacts to user actions (like opening some specific URL), tells
|
||||
the model to modify the data if necessary, and tells the view code what to
|
||||
display,
|
||||
|
||||
While one might think that MVC is a complex design pattern, in fact it is not.
|
||||
It is used in Python because it has turned out to be useful for creating clean,
|
||||
maintainable web sites.
|
||||
|
||||
.. note::
|
||||
|
||||
While not all Python frameworks explicitly support MVC, it is often trivial
|
||||
to create a web site which uses the MVC pattern by separating the data logic
|
||||
(the model) from the user interaction logic (the controller) and the
|
||||
templates (the view). That's why it is important not to write unnecessary
|
||||
Python code in the templates -- it works against the MVC model and creates
|
||||
chaos in the code base, making it harder to understand and modify.
|
||||
|
||||
.. seealso::
|
||||
|
||||
The English Wikipedia has an article about the `Model-View-Controller pattern
|
||||
<https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller>`_. It includes a long
|
||||
list of web frameworks for various programming languages.
|
||||
|
||||
|
||||
Ingredients for Websites
|
||||
========================
|
||||
|
||||
Websites are complex constructs, so tools have been created to help web
|
||||
developers make their code easier to write and more maintainable. Tools like
|
||||
these exist for all web frameworks in all languages. Developers are not forced
|
||||
to use these tools, and often there is no "best" tool. It is worth learning
|
||||
about the available tools because they can greatly simplify the process of
|
||||
developing a web site.
|
||||
|
||||
|
||||
.. seealso::
|
||||
|
||||
There are far more components than can be presented here. The Python wiki
|
||||
has a page about these components, called
|
||||
`Web Components <https://wiki.python.org/moin/WebComponents>`_.
|
||||
|
||||
|
||||
Templates
|
||||
---------
|
||||
|
||||
Mixing of HTML and Python code is made possible by a few libraries. While
|
||||
convenient at first, it leads to horribly unmaintainable code. That's why
|
||||
templates exist. Templates are, in the simplest case, just HTML files with
|
||||
placeholders. The HTML is sent to the user's browser after filling in the
|
||||
placeholders.
|
||||
|
||||
Python already includes a way to build simple templates::
|
||||
|
||||
# a simple template
|
||||
template = "<html><body><h1>Hello {who}!</h1></body></html>"
|
||||
print(template.format(who="Reader"))
|
||||
|
||||
To generate complex HTML based on non-trivial model data, conditional
|
||||
and looping constructs like Python's *for* and *if* are generally needed.
|
||||
*Template engines* support templates of this complexity.
|
||||
|
||||
There are a lot of template engines available for Python which can be used with
|
||||
or without a `framework`_. Some of these define a plain-text programming
|
||||
language which is easy to learn, partly because it is limited in scope.
|
||||
Others use XML, and the template output is guaranteed to be always be valid
|
||||
XML. There are many other variations.
|
||||
|
||||
Some `frameworks`_ ship their own template engine or recommend one in
|
||||
particular. In the absence of a reason to use a different template engine,
|
||||
using the one provided by or recommended by the framework is a good idea.
|
||||
|
||||
Popular template engines include:
|
||||
|
||||
* `Mako <http://www.makotemplates.org/>`_
|
||||
* `Genshi <http://genshi.edgewall.org/>`_
|
||||
* `Jinja <http://jinja.pocoo.org/>`_
|
||||
|
||||
.. seealso::
|
||||
|
||||
There are many template engines competing for attention, because it is
|
||||
pretty easy to create them in Python. The page `Templating
|
||||
<https://wiki.python.org/moin/Templating>`_ in the wiki lists a big,
|
||||
ever-growing number of these. The three listed above are considered "second
|
||||
generation" template engines and are a good place to start.
|
||||
|
||||
|
||||
Data persistence
|
||||
----------------
|
||||
|
||||
*Data persistence*, while sounding very complicated, is just about storing data.
|
||||
This data might be the text of blog entries, the postings on a bulletin board or
|
||||
the text of a wiki page. There are, of course, a number of different ways to store
|
||||
information on a web server.
|
||||
|
||||
Often, relational database engines like `MySQL <http://www.mysql.com/>`_ or
|
||||
`PostgreSQL <http://www.postgresql.org/>`_ are used because of their good
|
||||
performance when handling very large databases consisting of millions of
|
||||
entries. There is also a small database engine called `SQLite
|
||||
<http://www.sqlite.org/>`_, which is bundled with Python in the :mod:`sqlite3`
|
||||
module, and which uses only one file. It has no other dependencies. For
|
||||
smaller sites SQLite is just enough.
|
||||
|
||||
Relational databases are *queried* using a language called `SQL
|
||||
<https://en.wikipedia.org/wiki/SQL>`_. Python programmers in general do not
|
||||
like SQL too much, as they prefer to work with objects. It is possible to save
|
||||
Python objects into a database using a technology called `ORM
|
||||
<https://en.wikipedia.org/wiki/Object-relational_mapping>`_ (Object Relational
|
||||
Mapping). ORM translates all object-oriented access into SQL code under the
|
||||
hood, so the developer does not need to think about it. Most `frameworks`_ use
|
||||
ORMs, and it works quite well.
|
||||
|
||||
A second possibility is storing data in normal, plain text files (some
|
||||
times called "flat files"). This is very easy for simple sites,
|
||||
but can be difficult to get right if the web site is performing many
|
||||
updates to the stored data.
|
||||
|
||||
A third possibility are object oriented databases (also called "object
|
||||
databases"). These databases store the object data in a form that closely
|
||||
parallels the way the objects are structured in memory during program
|
||||
execution. (By contrast, ORMs store the object data as rows of data in tables
|
||||
and relations between those rows.) Storing the objects directly has the
|
||||
advantage that nearly all objects can be saved in a straightforward way, unlike
|
||||
in relational databases where some objects are very hard to represent.
|
||||
|
||||
`Frameworks`_ often give hints on which data storage method to choose. It is
|
||||
usually a good idea to stick to the data store recommended by the framework
|
||||
unless the application has special requirements better satisfied by an
|
||||
alternate storage mechanism.
|
||||
|
||||
.. seealso::
|
||||
|
||||
* `Persistence Tools <https://wiki.python.org/moin/PersistenceTools>`_ lists
|
||||
possibilities on how to save data in the file system. Some of these
|
||||
modules are part of the standard library
|
||||
|
||||
* `Database Programming <https://wiki.python.org/moin/DatabaseProgramming>`_
|
||||
helps with choosing a method for saving data
|
||||
|
||||
* `SQLAlchemy <http://www.sqlalchemy.org/>`_, the most powerful OR-Mapper
|
||||
for Python, and `Elixir <https://pypi.python.org/pypi/Elixir>`_, which makes
|
||||
SQLAlchemy easier to use
|
||||
|
||||
* `SQLObject <http://www.sqlobject.org/>`_, another popular OR-Mapper
|
||||
|
||||
* `ZODB <https://launchpad.net/zodb>`_ and `Durus
|
||||
<https://www.mems-exchange.org/software/>`_, two object oriented
|
||||
databases
|
||||
|
||||
|
||||
.. _framework:
|
||||
|
||||
Frameworks
|
||||
==========
|
||||
|
||||
The process of creating code to run web sites involves writing code to provide
|
||||
various services. The code to provide a particular service often works the
|
||||
same way regardless of the complexity or purpose of the web site in question.
|
||||
Abstracting these common solutions into reusable code produces what are called
|
||||
"frameworks" for web development. Perhaps the most well-known framework for
|
||||
web development is Ruby on Rails, but Python has its own frameworks. Some of
|
||||
these were partly inspired by Rails, or borrowed ideas from Rails, but many
|
||||
existed a long time before Rails.
|
||||
|
||||
Originally Python web frameworks tended to incorporate all of the services
|
||||
needed to develop web sites as a giant, integrated set of tools. No two web
|
||||
frameworks were interoperable: a program developed for one could not be
|
||||
deployed on a different one without considerable re-engineering work. This led
|
||||
to the development of "minimalist" web frameworks that provided just the tools
|
||||
to communicate between the Python code and the http protocol, with all other
|
||||
services to be added on top via separate components. Some ad hoc standards
|
||||
were developed that allowed for limited interoperability between frameworks,
|
||||
such as a standard that allowed different template engines to be used
|
||||
interchangeably.
|
||||
|
||||
Since the advent of WSGI, the Python web framework world has been evolving
|
||||
toward interoperability based on the WSGI standard. Now many web frameworks,
|
||||
whether "full stack" (providing all the tools one needs to deploy the most
|
||||
complex web sites) or minimalist, or anything in between, are built from
|
||||
collections of reusable components that can be used with more than one
|
||||
framework.
|
||||
|
||||
The majority of users will probably want to select a "full stack" framework
|
||||
that has an active community. These frameworks tend to be well documented,
|
||||
and provide the easiest path to producing a fully functional web site in
|
||||
minimal time.
|
||||
|
||||
|
||||
Some notable frameworks
|
||||
-----------------------
|
||||
|
||||
There are an incredible number of frameworks, so they cannot all be covered
|
||||
here. Instead we will briefly touch on some of the most popular.
|
||||
|
||||
|
||||
Django
|
||||
^^^^^^
|
||||
|
||||
`Django <https://www.djangoproject.com/>`_ is a framework consisting of several
|
||||
tightly coupled elements which were written from scratch and work together very
|
||||
well. It includes an ORM which is quite powerful while being simple to use,
|
||||
and has a great online administration interface which makes it possible to edit
|
||||
the data in the database with a browser. The template engine is text-based and
|
||||
is designed to be usable for page designers who cannot write Python. It
|
||||
supports template inheritance and filters (which work like Unix pipes). Django
|
||||
has many handy features bundled, such as creation of RSS feeds or generic views,
|
||||
which make it possible to create web sites almost without writing any Python code.
|
||||
|
||||
It has a big, international community, the members of which have created many
|
||||
web sites. There are also a lot of add-on projects which extend Django's normal
|
||||
functionality. This is partly due to Django's well written `online
|
||||
documentation <https://docs.djangoproject.com/>`_ and the `Django book
|
||||
<http://www.djangobook.com/>`_.
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
Although Django is an MVC-style framework, it names the elements
|
||||
differently, which is described in the `Django FAQ
|
||||
<https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names>`_.
|
||||
|
||||
|
||||
TurboGears
|
||||
^^^^^^^^^^
|
||||
|
||||
Another popular web framework for Python is `TurboGears
|
||||
<http://www.turbogears.org/>`_. TurboGears takes the approach of using already
|
||||
existing components and combining them with glue code to create a seamless
|
||||
experience. TurboGears gives the user flexibility in choosing components. For
|
||||
example the ORM and template engine can be changed to use packages different
|
||||
from those used by default.
|
||||
|
||||
The documentation can be found in the `TurboGears documentation
|
||||
<https://turbogears.readthedocs.org/>`_, where links to screencasts can be found.
|
||||
TurboGears has also an active user community which can respond to most related
|
||||
questions. There is also a `TurboGears book <http://turbogears.org/1.0/docs/TGBooks.html>`_
|
||||
published, which is a good starting point.
|
||||
|
||||
The newest version of TurboGears, version 2.0, moves even further in direction
|
||||
of WSGI support and a component-based architecture. TurboGears 2 is based on
|
||||
the WSGI stack of another popular component-based web framework, `Pylons
|
||||
<http://www.pylonsproject.org/>`_.
|
||||
|
||||
|
||||
Zope
|
||||
^^^^
|
||||
|
||||
The Zope framework is one of the "old original" frameworks. Its current
|
||||
incarnation in Zope2 is a tightly integrated full-stack framework. One of its
|
||||
most interesting feature is its tight integration with a powerful object
|
||||
database called the `ZODB <https://launchpad.net/zodb>`_ (Zope Object Database).
|
||||
Because of its highly integrated nature, Zope wound up in a somewhat isolated
|
||||
ecosystem: code written for Zope wasn't very usable outside of Zope, and
|
||||
vice-versa. To solve this problem the Zope 3 effort was started. Zope 3
|
||||
re-engineers Zope as a set of more cleanly isolated components. This effort
|
||||
was started before the advent of the WSGI standard, but there is WSGI support
|
||||
for Zope 3 from the `Repoze <http://repoze.org/>`_ project. Zope components
|
||||
have many years of production use behind them, and the Zope 3 project gives
|
||||
access to these components to the wider Python community. There is even a
|
||||
separate framework based on the Zope components: `Grok
|
||||
<http://grok.zope.org/>`_.
|
||||
|
||||
Zope is also the infrastructure used by the `Plone <https://plone.org/>`_ content
|
||||
management system, one of the most powerful and popular content management
|
||||
systems available.
|
||||
|
||||
|
||||
Other notable frameworks
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Of course these are not the only frameworks that are available. There are
|
||||
many other frameworks worth mentioning.
|
||||
|
||||
Another framework that's already been mentioned is `Pylons`_. Pylons is much
|
||||
like TurboGears, but with an even stronger emphasis on flexibility, which comes
|
||||
at the cost of being more difficult to use. Nearly every component can be
|
||||
exchanged, which makes it necessary to use the documentation of every single
|
||||
component, of which there are many. Pylons builds upon `Paste
|
||||
<http://pythonpaste.org/>`_, an extensive set of tools which are handy for WSGI.
|
||||
|
||||
And that's still not everything. The most up-to-date information can always be
|
||||
found in the Python wiki.
|
||||
|
||||
.. seealso::
|
||||
|
||||
The Python wiki contains an extensive list of `web frameworks
|
||||
<https://wiki.python.org/moin/WebFrameworks>`_.
|
||||
|
||||
Most frameworks also have their own mailing lists and IRC channels, look out
|
||||
for these on the projects' web sites.
|
||||
Loading…
Reference in New Issue