| CODENOTIFIER | HelpYou are not signed inSign in |
Project: Python
Revision: 66294
Author: georg.brandl
Date: 07 Sep 2008 13:00:17
Changes:Add a new howto about Python and the web, by Marek Kubica.
Files:| ... | ...@@ -0,0 +1,697 @@ | |
| 1 | ******************************* | |
| 2 | HOWTO Use Python in the web | |
| 3 | ******************************* | |
| 4 | ||
| 5 | :Author: Marek Kubica | |
| 6 | ||
| 7 | .. topic:: Abstract | |
| 8 | ||
| 9 | This document shows how Python fits into the web. It presents some ways on | |
| 10 | how to integrate Python with the web server and general practices useful for | |
| 11 | developing web sites. | |
| 12 | ||
| 13 | ||
| 14 | Programming for the Web has become a hot topic since the raise of the "Web 2.0", | |
| 15 | which focuses on user-generated content on web sites. It has always been | |
| 16 | possible to use Python for creating web sites, but it was a rather tedious task. | |
| 17 | Therefore, many so-called "frameworks" and helper tools were created to help | |
| 18 | developers creating sites faster and these sites being more robust. This HOWTO | |
| 19 | describes some of the methods used to combine Python with a web server to create | |
| 20 | dynamic content. It is not meant as a general introduction as this topic is far | |
| 21 | too broad to be covered in one single document. However, a short overview of | |
| 22 | the most popular libraries is provided. | |
| 23 | ||
| 24 | .. seealso:: | |
| 25 | ||
| 26 | While this HOWTO tries to give an overview over Python in the Web, it cannot | |
| 27 | always be as up to date as desired. Web development in Python is moving | |
| 28 | forward rapidly, so the wiki page on `Web Programming | |
| 29 | <http://wiki.python.org/moin/WebProgramming>`_ might be more in sync with | |
| 30 | recent development. | |
| 31 | ||
| 32 | ||
| 33 | The low-level view | |
| 34 | ================== | |
| 35 | ||
| 36 | .. .. image:: http.png | |
| 37 | ||
| 38 | When a user enters a web site, his browser makes a connection to the site's | |
| 39 | webserver (this is called the *request*). The server looks up the file in the | |
| 40 | file system and sends it back to the user's browser, which displays it (this is | |
| 41 | the *response*). This is roughly how the unterlying protocol, HTTP works. | |
| 42 | ||
| 43 | Now, dynamic web sites are not files in the file system, but rather programs | |
| 44 | which are run by the web server when a request comes in. They can do all sorts | |
| 45 | of useful things, like display the postings of a bulletin board, show your | |
| 46 | mails, configurate software or just display the current time. These programs | |
| 47 | can be written in about any programming language the server supports, so it is | |
| 48 | easy to use Python for creating dynamic web sites. | |
| 49 | ||
| 50 | As most of HTTP servers are written in C or C++, they cannot execute Python code | |
| 51 | in a simple way -- a bridge is needed between the server and the program. These | |
| 52 | bridges or rather interfaces define how programs interact with the server. In | |
| 53 | the past there have been numerous attempts to create the best possible | |
| 54 | interface, but there are only a few worth mentioning. | |
| 55 | ||
| 56 | Not every web server supports every interface. Many web servers do support only | |
| 57 | old, now-obsolete interfaces. But they can often be extended using some | |
| 58 | third-party modules to support new interfaces. | |
| 59 | ||
| 60 | ||
| 61 | Common Gateway Interface | |
| 62 | ------------------------ | |
| 63 | ||
| 64 | This interface is the oldest one, supported by nearly every web server out of | |
| 65 | the box. Programs using CGI to communicate with their web server need to be | |
| 66 | started by the server for every request. So, every request starts a new Python | |
| 67 | interpreter -- which takes some time to start up -- thus making the whole | |
| 68 | interface only usable for low load situations. | |
| 69 | ||
| 70 | The upside of CGI is that it is simple -- writing a program which uses CGI is a | |
| 71 | matter of about three lines of code. But this simplicity comes at a price: it | |
| 72 | does very few things to help the developer. | |
| 73 | ||
| 74 | Writing CGI programs, while still possible, is not recommended anymore. With | |
| 75 | WSGI (more on that later) it is possible to write programs that emulate CGI, so | |
| 76 | they can be run as CGI if no better option is available. | |
| 77 | ||
| 78 | .. seealso:: | |
| 79 | ||
| 80 | The Python standard library includes some modules that are helpful for | |
| 81 | creating plain CGI programs: | |
| 82 | ||
| 83 | * :mod:`cgi` -- Handling of user input in CGI scripts | |
| 84 | * :mod:`cgitb` -- Displays nice tracebacks when errors happen in of CGI | |
| 85 | applications, instead of presenting a "500 Internal Server Error" message | |
| 86 | ||
| 87 | The Python wiki features a page on `CGI scripts | |
| 88 | <http://wiki.python.org/moin/CgiScripts>`_ with some additional information | |
| 89 | about CGI in Python. | |
| 90 | ||
| 91 | ||
| 92 | Simple script for testing CGI | |
| 93 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
| 94 | ||
| 95 | To test whether your web server works with CGI, you can use this short and | |
| 96 | simple CGI program:: | |
| 97 | ||
| 98 | #!/usr/bin/env python | |
| 99 | # -*- coding: UTF-8 -*- | |
| 100 | ||
| 101 | # enable debugging | |
| 102 | import cgitb; cgitb.enable() | |
| 103 | ||
| 104 | print "Content-Type: text/plain;charset=utf-8" | |
| 105 | ||
| 106 | ||
| 107 | print "Hello World!" | |
| 108 | ||
| 109 | You need to write this code into a file with a ``.py`` or ``.cgi`` extension, | |
| 110 | this depends on your web server configuration. Depending on your web server | |
| 111 | configuration, this file may also need to be in a ``cgi-bin`` folder, for | |
| 112 | security reasons. | |
| 113 | ||
| 114 | You might wonder what the ``cgitb`` line is about. This line makes it possible | |
| 115 | to display a nice traceback instead of just crashing and displaying an "Internal | |
| 116 | Server Error" in the user's browser. This is useful for debugging, but it might | |
| 117 | risk exposing some confident data to the user. Don't use it when the script is | |
| 118 | ready for production use. Still, you should *always* catch exceptions, and | |
| 119 | display proper error pages -- end-users don't like to see nondescript "Internal | |
| 120 | Server Errors" in their browsers. | |
| 121 | ||
| 122 | ||
| 123 | Setting up CGI on your own server | |
| 124 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
| 125 | ||
| 126 | If you don't have your own web server, this does not apply to you. You can | |
| 127 | check whether if works as-is and if not you need to talk to the administrator of | |
| 128 | your web server anyway. If it is a big hoster, you can try filing a ticket | |
| 129 | asking for Python support. | |
| 130 | ||
| 131 | If you're your own administrator or want to install it for testing purposes on | |
| 132 | your own computers, you have to configure it by yourself. There is no one and | |
| 133 | single way on how to configure CGI, as there are many web servers with different | |
| 134 | configuration options. The currently most widely used free web server is | |
| 135 | `Apache HTTPd <http://httpd.apache.org/>`_, Apache for short -- this is the one | |
| 136 | that most people use, it can be easily installed on nearly every system using | |
| 137 | the systems' package management. But `lighttpd <http://www.lighttpd.net>`_ has | |
| 138 | been gaining attention since some time and is said to have a better performance. | |
| 139 | On many systems this server can also be installed using the package management, | |
| 140 | so manually compiling the web server is never needed. | |
| 141 | ||
| 142 | * On Apache you can take a look into the `Dynamic Content with CGI | |
| 143 | <http://httpd.apache.org/docs/2.2/howto/cgi.html>`_ tutorial, where everything | |
| 144 | is described. Most of the time it is enough just to set ``+ExecCGI``. The | |
| 145 | tutorial also describes the most common gotchas that might arise. | |
| 146 | * On lighttpd you need to use the `CGI module | |
| 147 | <http://trac.lighttpd.net/trac/wiki/Docs%3AModCGI>`_ which can be configured | |
| 148 | in a straightforward way. It boils down to setting ``cgi.assign`` properly. | |
| 149 | ||
| 150 | ||
| 151 | Common problems with CGI scripts | |
| 152 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
| 153 | ||
| 154 | Trying to use CGI sometimes leads to small annoyances that one might experience | |
| 155 | while trying to get these scripts to run. Sometimes it happens that a seemingly | |
| 156 | correct script does not work as expected, which is caused by some small hidden | |
| 157 | reason that's difficult to spot. | |
| 158 | ||
| 159 | Some of these reasons are: | |
| 160 | ||
| 161 | * The Python script is not marked executable. When CGI scripts are not | |
| 162 | executable most of the web servers will let the user download it, instead of | |
| 163 | running it and sending the output to the user. For CGI scripts to run | |
| 164 | properly the ``+x`` bit needs to be set. Using ``chmod a+x your_script.py`` | |
| 165 | might already solve the problem. | |
| 166 | * The line endings must be of Unix-type. This is important because the web | |
| 167 | server checks the first line of the script (called shebang) and tries to run | |
| 168 | the program specified there. It gets easily confused by Windows line endings | |
| 169 | (Carriage Return & Line Feed, also called CRLF), so you have to convert the | |
| 170 | file to Unix line endings (only Line Feed, LF). This can be done | |
| 171 | automatically by uploading the file via FTP in text mode instead of binary | |
| 172 | mode, but the preferred way is just telling your editor to save the files with | |
| 173 | Unix line endings. Most proper editors support this. | |
| 174 | * Your web server must be able to read the file, you need to make sure the | |
| 175 | permissions are fine. Often the server runs as user and group ``www-data``, | |
| 176 | so it might be worth a try to change the file ownership or making the file | |
| 177 | world readable by using ``chmod a+r your_script.py``. | |
| 178 | * The webserver must be able to know that the file you're trying to access is a | |
| 179 | CGI script. Check the configuration of your web server, maybe there is some | |
| 180 | mistake. | |
| 181 | * The path to the interpreter in the shebang (``#!/usr/bin/env python``) must be | |
| 182 | currect. This line calls ``/usr/bin/env`` to find Python, but it'll fail if | |
| 183 | there is no ``/usr/bin/env``. If you know where your Python is installed, you | |
| 184 | can also use that path. The commands ``whereis python`` and ``type -p | |
| 185 | python`` might also help to find where it is installed. Once this is known, | |
| 186 | the shebang line can be changed accordingly: ``#!/usr/bin/python``. | |
| 187 | * The file must not contain a BOM (Byte Order Mark). The BOM is meant for | |
| 188 | determining the byte order of UTF-16 encodings, but some editors write this | |
| 189 | also into UTF-8 files. The BOM interferes with the shebang line, so be sure | |
| 190 | to tell your editor not to write the BOM. | |
| 191 | * :ref:`mod-python` might be making problems. mod_python is able to handle CGI | |
| 192 | scripts by itself, but it can also be a source for problems. Be sure you | |
| 193 | disable it. | |
| 194 | ||
| 195 | ||
| 196 | .. _mod-python: | |
| 197 | ||
| 198 | mod_python | |
| 199 | ---------- | |
| 200 | ||
| 201 | People coming from PHP often find it hard to grasp how to use Python in the web. | |
| 202 | Their first thought is mostly `mod_python <http://www.modpython.org/>`_ because | |
| 203 | they think that this is the equivalent to ``mod_php``. Actually it is not | |
| 204 | really. It does embed the interpreter into the Apache process, thus speeding up | |
| 205 | requests by not having to start a Python interpreter every request. On the | |
| 206 | other hand, it is by far not "Python intermixed with HTML" as PHP often does. | |
| 207 | The Python equivalent of that is a template engine. mod_python itself is much | |
| 208 | more powerful and gives more access to Apache internals. It can emulate CGI, it | |
| 209 | can work an a "Python Server Pages" mode similar to JSP which is "HTML | |
| 210 | intermangled with Python" and it has a "Publisher" which destignates one file to | |
| 211 | accept all requests and decide on what to do then. | |
| 212 | ||
| 213 | But mod_python has some problems. Unlike the PHP interpreter the Python | |
| 214 | interpreter uses caching when executing files, so when changing a file the whole | |
| 215 | web server needs to be re-started to update. Another problem ist the basic | |
| 216 | concept -- Apache starts some child processes to handle the requests and | |
| 217 | unfortunately every child process needs to load the whole Python interpreter | |
| 218 | even if it does not use it. This makes the whole web server slower. Another | |
| 219 | problem is that as mod_python is linked against a specific version of | |
| 220 | ``libpython``, it is not possible to switch from an older version to a newer | |
| 221 | (e.g. 2.4 to 2.5) without recompiling mod_python. mod_python is also bound to | |
| 222 | the Apache web server, so programs written for mod_python cannot easily run on | |
| 223 | other web servers. | |
| 224 | ||
| 225 | These are the reasons why mod_python should be avoided when writing new | |
| 226 | programs. In some circumstances it might be still a good idea to use mod_python | |
| 227 | for deployment, but WSGI makes it possible to run WSGI programs under mod_python | |
| 228 | as well. | |
| 229 | ||
| 230 | ||
| 231 | FastCGI and SCGI | |
| 232 | ---------------- | |
| 233 | ||
| 234 | FastCGI and SCGI try to solve the performance problem of CGI in another way. | |
| 235 | Instead of embedding the interpreter into the web server, they create | |
| 236 | long-running processes which run in the background. There still is some module | |
| 237 | in the web server which makes it possible for the web server to "speak" with the | |
| 238 | background process. As the background process is independent from the server, | |
| 239 | it can be written in any language of course also in Python. The language just | |
| 240 | needs to have a library which handles the communication with the web server. | |
| 241 | ||
| 242 | The difference between FastCGI and SCGI is very small, as SCGI is essentially | |
| 243 | just a "simpler FastCGI". But as the web server support for SCGI is limited | |
| 244 | most people use FastCGI instead, which works the same way. Almost everything | |
| 245 | that applies to SCGI also applies to FastCGI as well, so we'll only write about | |
| 246 | the latter. | |
| 247 | ||
| 248 | These days, FastCGI is never used directly. Just like ``mod_python`` it is only | |
| 249 | used for the deployment of WSGI applications. | |
| 250 | ||
| 251 | .. seealso:: | |
| 252 | ||
| 253 | * `FastCGI, SCGI, and Apache: Background and Future | |
| 254 | <http://www.vmunix.com/mark/blog/archives/2006/01/02/fastcgi-scgi-and-apache-background-and-future/>`_ | |
| 255 | is a discussion on why the concept of FastCGI and SCGI is better that that | |
| 256 | of mod_python. | |
| 257 | ||
| 258 | ||
| 259 | Setting up FastCGI | |
| 260 | ^^^^^^^^^^^^^^^^^^ | |
| 261 | ||
| 262 | Depending on the web server you need to have a special module. | |
| 263 | ||
| 264 | * Apache has both `mod_fastcgi <http://www.fastcgi.com/>`_ and `mod_fcgid | |
| 265 | <http://fastcgi.coremail.cn/>`_. ``mod_fastcgi`` is the original one, but it | |
| 266 | has some licensing issues that's why it is sometimes considered non-free. | |
| 267 | ``mod_fcgid`` is a smaller, compatible alternative. One of these modules needs | |
| 268 | to be loaded by Apache. | |
| 269 | * lighttpd ships its own `FastCGI module | |
| 270 | <http://trac.lighttpd.net/trac/wiki/Docs%3AModFastCGI>`_ as well as an `SCGI | |
| 271 | module <http://trac.lighttpd.net/trac/wiki/Docs%3AModSCGI>`_. | |
| 272 | * nginx also supports `FastCGI | |
| 273 | <http://wiki.codemongers.com/NginxSimplePythonFCGI>`_. | |
| 274 | ||
| 275 | Once you have installed and configured the module, you can test it with the | |
| 276 | following WSGI-application:: | |
| 277 | ||
| 278 | #!/usr/bin/env python | |
| 279 | # -*- coding: UTF-8 -*- | |
| 280 | ||
| 281 | from cgi import escape | |
| 282 | import sys, os | |
| 283 | from flup.server.fcgi import WSGIServer | |
| 284 | ||
| 285 | def app(environ, start_response): | |
| 286 | start_response('200 OK', [('Content-Type', 'text/html')]) | |
| 287 | ||
| 288 | yield '<h1>FastCGI Environment</h1>' | |
| 289 | yield '<table>' | |
| 290 | for k, v in sorted(environ.items()): | |
| 291 | yield '<tr><th>%s</th><td>%s</td></tr>' % (escape(k), escape(v)) | |
| 292 | yield '</table>' | |
| 293 | ||
| 294 | WSGIServer(app).run() | |
| 295 | ||
| 296 | This is a simple WSGI application, but you need to install `flup | |
| 297 | <http://pypi.python.org/pypi/flup/1.0>`_ first, as flup handles the low level | |
| 298 | FastCGI access. | |
| 299 | ||
| 300 | .. seealso:: | |
| 301 | ||
| 302 | There is some documentation on `setting up Django with FastCGI | |
| 303 | <http://www.djangoproject.com/documentation/fastcgi/>`_, most of which can be | |
| 304 | reused for other WSGI-compliant frameworks and libraries. Only the | |
| 305 | ``manage.py`` part has to be changed, the example used here can be used | |
| 306 | instead. Django does more or less the exact same thing. | |
| 307 | ||
| 308 | ||
| 309 | mod_wsgi | |
| 310 | -------- | |
| 311 | ||
| 312 | `mod_wsgi <http://www.modwsgi.org/>`_ is an attempt to get rid of the low level | |
| 313 | gateways. As FastCGI, SCGI, mod_python are mostly used to deploy WSGI | |
| 314 | applications anyway, mod_wsgi was started to directly embed WSGI aplications | |
| 315 | into the Apache web server. The benefit from this approach is that WSGI | |
| 316 | applications can be deployed much easier as is is specially designed to host | |
| 317 | WSGI applications -- unlike the other low level methods which have glue code to | |
| 318 | host WSGI applications (like flup which was mentioned before). The downside is | |
| 319 | that mod_wsgi is limited to the Apache web server, other servers would need | |
| 320 | their own implementations of mod_wsgi. | |
| 321 | ||
| 322 | It supports two modes: the embedded mode in which it integrates with the Apache | |
| 323 | process and the daemon mode which is more FastCGI-like. Contrary to FastCGI, | |
| 324 | mod_wsgi handles the worker-processes by itself which makes administration | |
| 325 | easier. | |
| 326 | ||
| 327 | ||
| 328 | .. _WSGI: | |
| 329 | ||
| 330 | Step back: WSGI | |
| 331 | =============== | |
| 332 | ||
| 333 | WSGI was already mentioned several times so it has to be something important. | |
| 334 | In fact it really is, so now it's time to explain. | |
| 335 | ||
| 336 | The *Web Server Gateway Interface*, :pep:`333` or WSGI for short is currently | |
| 337 | the best possible way to Python web programming. While it is great for | |
| 338 | programmers writing frameworks, the normal person does not need to get in direct | |
| 339 | contact with it. But when choosing a framework for web development it is a good | |
| 340 | idea to take one which supports WSGI. | |
| 341 | ||
| 342 | The big profit from WSGI is the unification. When your program is compatible | |
| 343 | with WSGI -- that means that your framework has support for WSGI, your program | |
| 344 | can be deployed on every web server interface for which there are WSGI wrappers. | |
| 345 | So you do not need to care about whether the user uses mod_python or FastCGI -- | |
| 346 | with WSGI it just works on any gateway interface. The Python standard library | |
| 347 | contains its own WSGI server :mod:`wsgiref`, which is a small web server that | |
| 348 | can be used for testing. | |
| 349 | ||
| 350 | A really great WSGI feature are the middlewares. Middlewares are layers around | |
| 351 | your program which can add various functionality to it. There is a `number of | |
| 352 | middlewares <http://wsgi.org/wsgi/Middleware_and_Utilities>`_ already available. | |
| 353 | For example, instead of writing your own session management (to identify a user | |
| 354 | in subsequent requests, as HTTP does not maintain state, so it does now know | |
| 355 | that the requests belong to the same user) you can just take one middleware, | |
| 356 | plug it in and you can rely an already existing functionality. The same thing | |
| 357 | is compression -- say you want to compress your HTML using gzip, to save your | |
| 358 | server's bandwidth. So you only need to plug-in a middleware and you're done. | |
| 359 | Authentication is also a problem easily solved using a middleware. | |
| 360 | ||
| 361 | So, generally -- although WSGI may seem complex, the initial phase of learning | |
| 362 | can be very rewarding as WSGI does already have solutions to many problems that | |
| 363 | might arise while writing web sites. | |
| 364 | ||
| 365 | ||
| 366 | WSGI Servers | |
| 367 | ------------ | |
| 368 | ||
| 369 | The code that is used to connect to various low level gateways like CGI or | |
| 370 | mod_python is called *WSGI server*. One of these servers is ``flup`` which was | |
| 371 | already mentioned and supports FastCGI, SCGI as well as `AJP | |
| 372 | <http://en.wikipedia.org/wiki/Apache_JServ_Protocol>`_. Some of these servers | |
| 373 | are written in Python as ``flup`` is, but there also exist others which are | |
| 374 | written in C and can be used as drop-in replacements. | |
| 375 | ||
| 376 | There are quite a lot of servers already available, so a Python web application | |
| 377 | can be deployed nearly everywhere. This is one big advantage that Python has | |
| 378 | compared with other web techniques. | |
| 379 | ||
| 380 | .. seealso:: | |
| 381 | ||
| 382 | A good overview of all WSGI-related code can be found in the `WSGI wiki | |
| 383 | <http://wsgi.org/wsgi>`_, which contains an extensive list of `WSGI servers | |
| 384 | <http://wsgi.org/wsgi/Servers>`_, which can be used by *every* application | |
| 385 | supporting WSGI. | |
| 386 | ||
| 387 | You might be interested in some WSGI-supporting modules already contained in | |
| 388 | the standard library, namely: | |
| 389 | ||
| 390 | * :mod:`wsgiref` -- some tiny utilities and servers for WSGI | |
| 391 | ||
| 392 | ||
| 393 | Case study: MoinMoin | |
| 394 | -------------------- | |
| 395 | ||
| 396 | What does WSGI give the web application developer? Let's take a look on one | |
| 397 | long existing web application written in Python without using WSGI. | |
| 398 | ||
| 399 | One of the most widely used wiki software is `MoinMoin <http://moinmo.in/>`_. | |
| 400 | It was created in 2000, so it predates WSGI by about three years. While it now | |
| 401 | includes support for WSGI, older versions needed separate code to run on CGI, | |
| 402 | mod_python, FastCGI and standalone. Now, this all is possible by using WSGI and | |
| 403 | the already-written gateways. For running with on FastCGI ``flup`` can be used, | |
| 404 | for running a standalone server :mod:`wsgiref` is the way to go. | |
| 405 | ||
| 406 | ||
| 407 | Model-view-controller | |
| 408 | ===================== | |
| 409 | ||
| 410 | The term *MVC* is often heard in statements like "framework *foo* supports MVC". | |
| 411 | While MVC is not really something technical but rather organisational, many web | |
| 412 | frameworks use this model to help the developer to bring structure into his | |
| 413 | program. Bigger web applications can have lots of code so it is a good idea to | |
| 414 | have structure in the program right from the beginnings. That way, even users | |
| 415 | of other frameworks (or even languages, as MVC is nothing Python-specific) can | |
| 416 | understand the existing code easier, as they are already familiar with the | |
| 417 | structure. | |
| 418 | ||
| 419 | MVC stands for three components: | |
| 420 | ||
| 421 | * The *model*. This is the data that is meant to modify. In Python frameworks | |
| 422 | this component is often represented by the classes used by the | |
| 423 | object-relational mapper. So, all declarations go here. | |
| 424 | * The *view*. This component's job is to display the data of the model to the | |
| 425 | user. Typically this component is represented by the templates. | |
| 426 | * The *controller*. This is the layer between the user and the model. The | |
| 427 | controller reacts on user actions (like opening some specific URL) and tells | |
| 428 | the model to modify the data if neccessary. | |
| 429 | ||
| 430 | While one might think that MVC is a complex design pattern, in fact it is not. | |
| 431 | It is used in Python because it has turned out to be useful for creating clean, | |
| 432 | maintainable web sites. | |
| 433 | ||
| 434 | .. note:: | |
| 435 | ||
| 436 | While not all Python frameworks explicitly support MVC, it is often trivial | |
| 437 | to create a web site which uses the MVC pattern by seperating the data logic | |
| 438 | (the model) from the user interaction logic (the controller) and the | |
| 439 | templates (the view). That's why it is important not to write unneccessary | |
| 440 | Python code in the templates -- it is against MVC and creates more chaos. | |
| 441 | ||
| 442 | .. seealso:: | |
| 443 | ||
| 444 | The english Wikipedia has an article about the `Model-View-Controller pattern | |
| 445 | <http://en.wikipedia.org/wiki/Model-view-controller>`_, which includes a long | |
| 446 | list of web frameworks for different programming languages. | |
| 447 | ||
| 448 | ||
| 449 | Ingredients for web sites | |
| 450 | ========================= | |
| 451 | ||
| 452 | Web sites are complex constructs, so tools were created to help the web site | |
| 453 | developer to make his work maintainable. None of these tools are in any way | |
| 454 | Python specific, they also exist for other programming languages as well. Of | |
| 455 | course, developers are not forced to use these tools and often there is no | |
| 456 | "best" tool, but it is worth informing yourself before choosing something | |
| 457 | because of the big number of helpers that the developer can use. | |
| 458 | ||
| 459 | ||
| 460 | .. seealso:: | |
| 461 | ||
| 462 | People have written far more components that can be combined than these | |
| 463 | presented here. The Python wiki has a page about these components, called | |
| 464 | `Web Components <http://wiki.python.org/moin/WebComponents>`_. | |
| 465 | ||
| 466 | ||
| 467 | Templates | |
| 468 | --------- | |
| 469 | ||
| 470 | Mixing of HTML and Python code is possible with some libraries. While | |
| 471 | convenient at first, it leads to horribly unmaintainable code. That's why | |
| 472 | templates exist. Templates are, in the simplest case, just HTML files with | |
| 473 | placeholders. The HTML is sent to the user's browser after filling out the | |
| 474 | placeholders. | |
| 475 | ||
| 476 | Python already includes such simple templates:: | |
| 477 | ||
| 478 | # a simple template | |
| 479 | template = "<html><body><h1>Hello %s!</h1></body></html>" | |
| 480 | print template % "Reader" | |
| 481 | ||
| 482 | The Python standard library also includes some more advanced templates usable | |
| 483 | through :class:`string.Template`, but in HTML templates it is needed to use | |
| 484 | conditional and looping contructs like Python's *for* and *if*. So, some | |
| 485 | *template engine* is needed. | |
| 486 | ||
| 487 | Now, Python has a lot of template engines which can be used with or without a | |
| 488 | `framework`_. Some of these are using a plain-text programming language which | |
| 489 | is very easy to learn as it is quite limited while others use XML so the | |
| 490 | template output is always guaranteed to be valid XML. Some `frameworks`_ ship | |
| 491 | their own template engine or recommend one particular. If one is not yet sure, | |
| 492 | using these is a good idea. | |
| 493 | ||
| 494 | .. note:: | |
| 495 | ||
| 496 | While Python has quite a lot of different template engines it usually does | |
| 497 | not make sense to use a homebrewed template system. The time needed to | |
| 498 | evaluate all templating systems is not really worth it, better invest the | |
| 499 | time in looking through the most popular ones. Some frameworks have their | |
| 500 | own template engine or have a recommentation for one. It's wise to use | |
| 501 | these. | |
| 502 | ||
| 503 | Popular template engines include: | |
| 504 | ||
| 505 | * Mako | |
| 506 | * Genshi | |
| 507 | * Jinja | |
| 508 | ||
| 509 | .. seealso:: | |
| 510 | ||
| 511 | Lots of different template engines divide the attention between themselves | |
| 512 | because it's easy to create them in Python. The page `Templating | |
| 513 | <http://wiki.python.org/moin/Templating>`_ in the wiki lists a big, | |
| 514 | ever-growing number of these. | |
| 515 | ||
| 516 | ||
| 517 | Data persistence | |
| 518 | ---------------- | |
| 519 | ||
| 520 | *Data persistence*, while sounding very complicated is just about storing data. | |
| 521 | This data might be the text of blog entries, the postings of a bulletin board or | |
| 522 | the text of a wiki page. As always, there are different ways to store | |
| 523 | informations on a web server. | |
| 524 | ||
| 525 | Often relational database engines like `MySQL <http://www.mysql.com/>`_ or | |
| 526 | `PostgreSQL <http://http://www.postgresql.org/>`_ are used due to their good | |
| 527 | performance handling very large databases consisting of up to millions of | |
| 528 | entries. These are *queried* using a language called `SQL | |
| 529 | <http://en.wikipedia.org/wiki/SQL>`_. Python programmers in general do not like | |
| 530 | SQL too much, they prefer to work with objects. It is possible to save Python | |
| 531 | objects into a database using a technology called `ORM | |
| 532 | <http://en.wikipedia.org/wiki/Object-relational_mapping>`_. ORM translates all | |
| 533 | object-oriented access into SQL code under the hood, the user does not need to | |
| 534 | think about it. Most `frameworks`_ use ORMs and it works quite well. | |
| 535 | ||
| 536 | A second possibility is using files that are saved on the hard disk (sometimes | |
| 537 | called flatfiles). This is very easy, but is not too fast. There is even a | |
| 538 | small database engine called `SQLite <http://www.sqlite.org/>`_ which is bundled | |
| 539 | with Python in the :mod:`sqlite` module and uses only one file. This database | |
| 540 | can be used to store objects via an ORM and has no other dependencies. For | |
| 541 | smaller sites SQLite is just enough. But it is not the only way in which data | |
| 542 | can be saved into the file systems. Sometimes normal, plain text files are | |
| 543 | enough. | |
| 544 | ||
| 545 | The third and least used possibility are so-called object oriented databases. | |
| 546 | These databases store the *actual objects* instead of the relations that | |
| 547 | OR-mapping creates between rows in a database. This has the advantage that | |
| 548 | nearly all objects can be saven in a straightforward way, unlike in relational | |
| 549 | databases where some objects are very hard to represent with ORMs. | |
| 550 | ||
| 551 | `Frameworks`_ often give the users hints on which method to choose, it is | |
| 552 | usually a good idea to stick to these unless there are some special requirements | |
| 553 | which require to use the one method and not the other. | |
| 554 | ||
| 555 | .. seealso:: | |
| 556 | ||
| 557 | * `Persistence Tools <http://wiki.python.org/moin/PersistenceTools>`_ lists | |
| 558 | possibilities on how to save data in the file system, some of these modules | |
| 559 | are part of the standard library | |
| 560 | * `Database Programming <http://wiki.python.org/moin/DatabaseProgramming>`_ | |
| 561 | helps on choosing a method on how to save the data | |
| 562 | * `SQLAlchemy <http://www.sqlalchemy.org/>`_, the most powerful OR-Mapper for | |
| 563 | Python and `Elixir <http://elixir.ematia.de/>`_ which makes it easier to | |
| 564 | use | |
| 565 | * `SQLObject <http://www.sqlobject.org/>`_, another popular OR-Mapper | |
| 566 | * `ZODB <https://launchpad.net/zodb>`_ and `Durus | |
| 567 | <http://www.mems-exchange.org/software/durus/>`_, two object oriented | |
| 568 | databases | |
| 569 | ||
| 570 | ||
| 571 | .. _framework: | |
| 572 | ||
| 573 | Frameworks | |
| 574 | ========== | |
| 575 | ||
| 576 | As web sites can easily become quite large, there are so-called frameworks which | |
| 577 | were created to help the developer with making these sites. Although the most | |
| 578 | well-known framework is Ruby on Rails, Python does also have its own frameworks | |
| 579 | which are partly inspired by Rails or which were existing a long time before | |
| 580 | Rails. | |
| 581 | ||
| 582 | Two possible approaches to web frameworks exist: the minimalistic approach and | |
| 583 | the all-inclusive approach (somtimes called *full-stack*). Frameworks which are | |
| 584 | all-inclusive give you everything you need to start working, like a template | |
| 585 | engine, some way to save and access data in databases and many features more. | |
| 586 | Most users are best off using these as they are widely used by lots of other | |
| 587 | users and well documented in form of books and tutorials. Other web frameworks | |
| 588 | go the minimalistic approach trying to be as flexible as possible leaving the | |
| 589 | user the freedom to choose what's best for him. | |
| 590 | ||
| 591 | The majority of users is best off with all-inclusive framewors. They bring | |
| 592 | everything along so a user can just jump in and start to code. While they do | |
| 593 | have some limitations they can fullfill 80% of what one will ever want to | |
| 594 | perfectly. They consist of various components which are designed to work | |
| 595 | together as good as possible. | |
| 596 | ||
| 597 | The multitude of web frameworks written in Python demonstrates that it is really | |
| 598 | easy to write one. One of the most well-known web applications written in | |
| 599 | Python is `Zope <http://www.zope.org/>`_ which can be regarded as some kind of | |
| 600 | big framework. But Zope was not the only framework, there were some others | |
| 601 | which are by now nearly forgotten. These do not need to be mentioned anymore, | |
| 602 | because most people that used them moved on to newer ones. | |
| 603 | ||
| 604 | ||
| 605 | Some notable frameworks | |
| 606 | ----------------------- | |
| 607 | ||
| 608 | There is an incredible number of frameworks, so there is no way to describe them | |
| 609 | all. It is not even neccessary, as most of these frameworks are nothing special | |
| 610 | and everything that can be done with these can also be done with one of the | |
| 611 | popular ones. | |
| 612 | ||
| 613 | ||
| 614 | Django | |
| 615 | ^^^^^^ | |
| 616 | ||
| 617 | `Django <http://www.djangoproject.com/>`_ is a framework consisting of several | |
| 618 | tightly coupled elements which were written from scratch and work together very | |
| 619 | well. It includes an ORM which is quite powerful while being simple to use and | |
| 620 | has a great online administration interface which makes it possible to edit the | |
| 621 | data in the database with a browser. The template engine is text-based and is | |
| 622 | designed to be usable for page designers who cannot write Python. It supports | |
| 623 | so-called template inheritance and filters (which work like Unix pipes). Django | |
| 624 | has many handy features bundled, like creation of RSS feeds or generic views | |
| 625 | which make it possible to write web sites nearly without any Python code. | |
| 626 | ||
| 627 | It has a big, international community which has created many sites using Django. | |
| 628 | There are also quite a lot of add-on projects which extend Django's normal | |
| 629 | functionality. This is partly due to Django's well written `online | |
| 630 | documentation <http://doc.djangoproject.com/>`_ and the `Django book | |
| 631 | <http://www.djangobook.com/>`_. | |
| 632 | ||
| 633 | ||
| 634 | .. note:: | |
| 635 | ||
| 636 | Although Django is an MVC-style framework, it calls the components | |
| 637 | differently, which is described in the `Django FAQ | |
| 638 | <http://www.djangoproject.com/documentation/faq/#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>`_. | |
| 639 | ||
| 640 | ||
| 641 | TurboGears | |
| 642 | ^^^^^^^^^^ | |
| 643 | ||
| 644 | The other popular web framework in Python is `TurboGears | |
| 645 | <http://www.turbogears.org/>`_. It takes the approach of using already existing | |
| 646 | components and combining them with glue code to create a seamless experience. | |
| 647 | TurboGears gives the user more flexibility on which components to choose, the | |
| 648 | ORM can be switched between some easy to use but limited and complex but very | |
| 649 | powerful. Same goes for the template engine. One strong point about TurboGears | |
| 650 | is that the components that it consists of can be used easily in other projects | |
| 651 | without depending on TurboGears, for example the underlying web server CherryPy. | |
| 652 | ||
| 653 | The documentation can be found in the `TurboGears wiki | |
| 654 | <http://docs.turbogears.org/>`_, where links to screencasts can be found. | |
| 655 | TurboGears has also an active user community which can respond to most related | |
| 656 | questions. There is also a `TurboGears book <http://turbogearsbook.com/>`_ | |
| 657 | published, which is a good starting point. | |
| 658 | ||
| 659 | The plan for the next major version of TurboGears, version 2.0 is to switch to a | |
| 660 | more flexible base provided by another very flexible web framework called | |
| 661 | `Pylons <http://pylonshq.com/>`_. | |
| 662 | ||
| 663 | ||
| 664 | Other notable frameworks | |
| 665 | ^^^^^^^^^^^^^^^^^^^^^^^^ | |
| 666 | ||
| 667 | These two are of course not the only frameworks that are available, there are | |
| 668 | also some less-popular frameworks worth mentioning. | |
| 669 | ||
| 670 | One of these is the already mentioned Zope, which has been around for quite a | |
| 671 | long time. With Zope 2.x having been known as rather un-pythonic, the newer | |
| 672 | Zope 3.x tries to change that and therefore gets more acceptance from Python | |
| 673 | programmers. These efforts already showed results, there is a project which | |
| 674 | connects Zope with WSGI called `Repoze <http://repoze.org/>`_ and another | |
| 675 | project called `Grok <http://grok.zope.org/>`_ which makes it possible for | |
| 676 | "normal" Python programmers use the very mature Zope components. | |
| 677 | ||
| 678 | Another framework that's already been mentioned is `Pylons`_. Pylons is much | |
| 679 | like TurboGears with ab even stronger emphasis on flexibility, which is bought | |
| 680 | at the cost of being more difficult to use. Nearly every component can be | |
| 681 | exchanged, which makes it neccessary to use the documentation of every single | |
| 682 | component, because there are so many Pylons combinations possible that can | |
| 683 | satisfy every requirement. Pylons builds upon `Paste | |
| 684 | <http://pythonpaste.org/>`_, an extensive set of tools which are handy for WSGI. | |
| 685 | ||
| 686 | And that's still not everything. The most up-to-date information can always be | |
| 687 | found in the Python wiki. | |
| 688 | ||
| 689 | .. seealso:: | |
| 690 | ||
| 691 | The Python wiki contains an extensive list of `web frameworks | |
| 692 | <http://wiki.python.org/moin/WebFrameworks>`_. | |
| 693 | ||
| 694 | Most frameworks also have their own mailing lists and IRC channels, look out | |
| 695 | for these on the projects' websites. There is also a general "Python in the | |
| 696 | Web" IRC channel on freenode called `#python.web | |
| 697 | <http://wiki.python.org/moin/PoundPythonWeb>`_. |
| ... | ...@@ -21,4 +21,5 @@ | |
| 21 | 21 | sockets.rst |
| 22 | 22 | unicode.rst |
| 23 | 23 | urllib2.rst |
| 24 | webservers.rst | |
| 24 | 25 |