![[Python logo]](http://www.python.org/images/python-logo.gif){kind=logo}
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:added: /python/trunk/Doc/howto/webservers.rst (try)
modified: /python/trunk/Doc/howto/index.rst (try)
/python/trunk/Doc/howto/webservers.rst
...... @@ -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 print 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>`_. /python/trunk/Doc/howto/index.rst
...... @@ -21,4 +21,5 @@ 21 21 sockets.rst 22 22 unicode.rst 23 23 urllib2.rst 24 webservers.rst 24 25