/Doc/howto/webservers.rst

http://unladen-swallow.googlecode.com/ · ReStructuredText · 698 lines · 537 code · 161 blank · 0 comment · 0 complexity · 5ddebd87b0175902c270432d2d710077 MD5 · raw file

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