mirror of
https://github.com/bookieio/breadability
synced 2024-11-16 12:13:11 +00:00
856 lines
70 KiB
HTML
856 lines
70 KiB
HTML
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
||
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||
|
<head>
|
||
|
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
|
||
|
<meta http-equiv="Content-Language" content="en-us" />
|
||
|
<title>Django | Writing your first Django app, part 1 | Django documentation</title>
|
||
|
<meta name="ROBOTS" content="ALL" />
|
||
|
<meta http-equiv="imagetoolbar" content="no" />
|
||
|
<meta name="MSSmartTagsPreventParsing" content="true" />
|
||
|
<meta name="Copyright" content="Django Software Foundation" />
|
||
|
<meta name="keywords" content="Python, Django, framework, open-source" />
|
||
|
<meta name="description" content="Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design." />
|
||
|
<link href="https://www.djangoproject.com/m/css/base.css" rel="stylesheet" type="text/css" media="screen" />
|
||
|
<link href="https://www.djangoproject.com/m/css/print.css" rel="stylesheet" type="text/css" media="print" />
|
||
|
|
||
|
|
||
|
<link rel="stylesheet" href="https://www.djangoproject.com/m/css/docs/docs.css" type="text/css" />
|
||
|
<link rel="stylesheet" href="https://www.djangoproject.com/m/css/pygments.css" type="text/css" />
|
||
|
|
||
|
</head>
|
||
|
<body id="documentation" class="default">
|
||
|
<div id="container">
|
||
|
<div id="header">
|
||
|
<h1 id="logo"><a href="https://www.djangoproject.com/"><img src="https://www.djangoproject.com/m/img/site/hdr_logo.gif" alt="Django" /></a></h1>
|
||
|
<ul id="nav-global">
|
||
|
<li id="nav-homepage"><a href="https://www.djangoproject.com/">Home</a></li>
|
||
|
<li id="nav-download"><a href="https://www.djangoproject.com/download/">Download</a></li>
|
||
|
<li id="nav-documentation"><a href="https://docs.djangoproject.com/">Documentation</a></li>
|
||
|
<li id="nav-weblog"><a href="https://www.djangoproject.com/weblog/">Weblog</a></li>
|
||
|
<li id="nav-community"><a href="https://www.djangoproject.com/community/">Community</a></li>
|
||
|
<li id="nav-code"><a href="https://code.djangoproject.com/">Code</a></li>
|
||
|
</ul>
|
||
|
</div>
|
||
|
<!-- END Header -->
|
||
|
<div id="billboard">
|
||
|
<h2><a href="/en/1.4/">Django documentation</a></h2>
|
||
|
</div>
|
||
|
<div id="columnwrap">
|
||
|
|
||
|
<div id="content-main">
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
<ul id="doc-versions">
|
||
|
|
||
|
|
||
|
<li class="other">
|
||
|
<a href="/en/1.0/intro/tutorial01/">1.0</a></li>
|
||
|
|
||
|
|
||
|
|
||
|
<li class="other">
|
||
|
<a href="/en/1.1/intro/tutorial01/">1.1</a></li>
|
||
|
|
||
|
|
||
|
|
||
|
<li class="other">
|
||
|
<a href="/en/1.2/intro/tutorial01/">1.2</a></li>
|
||
|
|
||
|
|
||
|
|
||
|
<li class="other">
|
||
|
<a href="/en/1.3/intro/tutorial01/">1.3</a></li>
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
<li class="other">
|
||
|
<a href="/en/dev/intro/tutorial01/">dev</a></li>
|
||
|
|
||
|
|
||
|
<li class="current"
|
||
|
title="This document describes Django 1.4. Click on the links on the left to see other versions.">
|
||
|
<span>Documentation version:
|
||
|
<strong>1.4</strong>
|
||
|
</span>
|
||
|
</li>
|
||
|
</ul>
|
||
|
<div class="section" id="s-writing-your-first-django-app-part-1">
|
||
|
<span id="writing-your-first-django-app-part-1"></span><h1>Writing your first Django app, part 1<a class="headerlink" href="#writing-your-first-django-app-part-1" title="Permalink to this headline">¶</a></h1>
|
||
|
<p>Let’s learn by example.</p>
|
||
|
<p>Throughout this tutorial, we’ll walk you through the creation of a basic
|
||
|
poll application.</p>
|
||
|
<p>It’ll consist of two parts:</p>
|
||
|
<ul class="simple">
|
||
|
<li>A public site that lets people view polls and vote in them.</li>
|
||
|
<li>An admin site that lets you add, change and delete polls.</li>
|
||
|
</ul>
|
||
|
<p>We’ll assume you have <a class="reference internal" href="../install/"><em>Django installed</em></a> already. You can
|
||
|
tell Django is installed by running the Python interactive interpreter and
|
||
|
typing <tt class="docutils literal"><span class="pre">import</span> <span class="pre">django</span></tt>. If that command runs successfully, with no errors,
|
||
|
Django is installed.</p>
|
||
|
<div class="admonition-where-to-get-help admonition ">
|
||
|
<p class="first admonition-title">Where to get help:</p>
|
||
|
<p class="last">If you’re having trouble going through this tutorial, please post a message
|
||
|
to <a class="reference external" href="http://groups.google.com/group/django-users">django-users</a> or drop by <a class="reference external" href="irc://irc.freenode.net/django">#django on irc.freenode.net</a> to chat
|
||
|
with other Django users who might be able to help.</p>
|
||
|
</div>
|
||
|
<div class="section" id="s-creating-a-project">
|
||
|
<span id="creating-a-project"></span><h2>Creating a project<a class="headerlink" href="#creating-a-project" title="Permalink to this headline">¶</a></h2>
|
||
|
<p>If this is your first time using Django, you’ll have to take care of some
|
||
|
initial setup. Namely, you’ll need to auto-generate some code that establishes a
|
||
|
Django <a class="reference internal" href="../../glossary/#term-project"><em class="xref std std-term">project</em></a> – a collection of settings for an instance of Django,
|
||
|
including database configuration, Django-specific options and
|
||
|
application-specific settings.</p>
|
||
|
<p>From the command line, <tt class="docutils literal"><span class="pre">cd</span></tt> into a directory where you’d like to store your
|
||
|
code, then run the following command:</p>
|
||
|
<div class="highlight-bash"><div class="highlight"><pre>django-admin.py startproject mysite
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>This will create a <tt class="docutils literal"><span class="pre">mysite</span></tt> directory in your current directory.</p>
|
||
|
<div class="admonition-script-name-may-differ-in-distribution-packages admonition ">
|
||
|
<p class="first admonition-title">Script name may differ in distribution packages</p>
|
||
|
<p class="last">If you installed Django using a Linux distribution's package manager
|
||
|
(e.g. apt-get or yum) <tt class="docutils literal"><span class="pre">django-admin.py</span></tt> may have been renamed to
|
||
|
<tt class="docutils literal"><span class="pre">django-admin</span></tt>. You may continue through this documentation by omitting
|
||
|
<tt class="docutils literal"><span class="pre">.py</span></tt> from each command.</p>
|
||
|
</div>
|
||
|
<div class="admonition-mac-os-x-permissions admonition ">
|
||
|
<p class="first admonition-title">Mac OS X permissions</p>
|
||
|
<p class="last">If you're using Mac OS X, you may see the message "permission denied" when
|
||
|
you try to run <tt class="docutils literal"><span class="pre">django-admin.py</span> <span class="pre">startproject</span></tt>. This is because, on
|
||
|
Unix-based systems like OS X, a file must be marked as "executable" before it
|
||
|
can be run as a program. To do this, open Terminal.app and navigate (using
|
||
|
the <tt class="docutils literal"><span class="pre">cd</span></tt> command) to the directory where <a class="reference internal" href="../../ref/django-admin/"><em>django-admin.py</em></a> is installed, then run the command
|
||
|
<tt class="docutils literal"><span class="pre">sudo</span> <span class="pre">chmod</span> <span class="pre">+x</span> <span class="pre">django-admin.py</span></tt>.</p>
|
||
|
</div>
|
||
|
<div class="admonition note">
|
||
|
<p class="first admonition-title">Note</p>
|
||
|
<p class="last">You'll need to avoid naming projects after built-in Python or Django
|
||
|
components. In particular, this means you should avoid using names like
|
||
|
<tt class="docutils literal"><span class="pre">django</span></tt> (which will conflict with Django itself) or <tt class="docutils literal"><span class="pre">test</span></tt> (which
|
||
|
conflicts with a built-in Python package).</p>
|
||
|
</div>
|
||
|
<p><a class="reference internal" href="../../ref/django-admin/"><em>django-admin.py</em></a> should be on your system path if you
|
||
|
installed Django via <tt class="docutils literal"><span class="pre">python</span> <span class="pre">setup.py</span></tt>. If it's not on your path, you can find
|
||
|
it in <tt class="docutils literal"><span class="pre">site-packages/django/bin</span></tt>, where <tt class="docutils literal"><span class="pre">site-packages</span></tt> is a directory
|
||
|
within your Python installation. Consider symlinking to <a class="reference internal" href="../../ref/django-admin/"><em>django-admin.py</em></a> from some place on your path, such as
|
||
|
<tt class="file docutils literal"><span class="pre">/usr/local/bin</span></tt>.</p>
|
||
|
<div class="admonition-where-should-this-code-live admonition ">
|
||
|
<p class="first admonition-title">Where should this code live?</p>
|
||
|
<p>If your background is in PHP, you're probably used to putting code under the
|
||
|
Web server's document root (in a place such as <tt class="docutils literal"><span class="pre">/var/www</span></tt>). With Django,
|
||
|
you don't do that. It's not a good idea to put any of this Python code
|
||
|
within your Web server's document root, because it risks the possibility
|
||
|
that people may be able to view your code over the Web. That's not good for
|
||
|
security.</p>
|
||
|
<p class="last">Put your code in some directory <strong>outside</strong> of the document root, such as
|
||
|
<tt class="file docutils literal"><span class="pre">/home/mycode</span></tt>.</p>
|
||
|
</div>
|
||
|
<p>Let's look at what <a class="reference internal" href="../../ref/django-admin/#django-admin-startproject"><tt class="xref std std-djadmin docutils literal"><span class="pre">startproject</span></tt></a> created:</p>
|
||
|
<div class="highlight-python"><pre>mysite/
|
||
|
manage.py
|
||
|
mysite/
|
||
|
__init__.py
|
||
|
settings.py
|
||
|
urls.py
|
||
|
wsgi.py</pre>
|
||
|
</div>
|
||
|
<div class="admonition-doesn-t-match-what-you-see admonition ">
|
||
|
<p class="first admonition-title">Doesn't match what you see?</p>
|
||
|
<p class="last">The default project layout recently changed. If you're seeing a "flat"
|
||
|
layout (with no inner <tt class="file docutils literal"><span class="pre">mysite/</span></tt> directory), you're probably using
|
||
|
a version of Django that doesn't match this tutorial version. You'll
|
||
|
want to either switch to the older tutorial or the newer Django version.</p>
|
||
|
</div>
|
||
|
<p>These files are:</p>
|
||
|
<ul class="simple">
|
||
|
<li>The outer <tt class="file docutils literal"><span class="pre">mysite/</span></tt> directory is just a container for your
|
||
|
project. Its name doesn't matter to Django; you can rename it to anything
|
||
|
you like.</li>
|
||
|
<li><tt class="file docutils literal"><span class="pre">manage.py</span></tt>: A command-line utility that lets you interact with this
|
||
|
Django project in various ways. You can read all the details about
|
||
|
<tt class="file docutils literal"><span class="pre">manage.py</span></tt> in <a class="reference internal" href="../../ref/django-admin/"><em>django-admin.py and manage.py</em></a>.</li>
|
||
|
<li>The inner <tt class="file docutils literal"><span class="pre">mysite/</span></tt> directory is the actual Python package for your
|
||
|
project. Its name is the Python package name you'll need to use to import
|
||
|
anything inside it (e.g. <tt class="docutils literal"><span class="pre">import</span> <span class="pre">mysite.settings</span></tt>).</li>
|
||
|
<li><tt class="file docutils literal"><span class="pre">mysite/__init__.py</span></tt>: An empty file that tells Python that this
|
||
|
directory should be considered a Python package. (Read <a class="reference external" href="http://docs.python.org/tutorial/modules.html#packages">more about
|
||
|
packages</a> in the official Python docs if you're a Python beginner.)</li>
|
||
|
<li><tt class="file docutils literal"><span class="pre">mysite/settings.py</span></tt>: Settings/configuration for this Django
|
||
|
project. <a class="reference internal" href="../../topics/settings/"><em>Django settings</em></a> will tell you all about how settings
|
||
|
work.</li>
|
||
|
<li><tt class="file docutils literal"><span class="pre">mysite/urls.py</span></tt>: The URL declarations for this Django project; a
|
||
|
"table of contents" of your Django-powered site. You can read more about
|
||
|
URLs in <a class="reference internal" href="../../topics/http/urls/"><em>URL dispatcher</em></a>.</li>
|
||
|
<li><tt class="file docutils literal"><span class="pre">mysite/wsgi.py</span></tt>: An entry-point for WSGI-compatible webservers to
|
||
|
serve your project. See <a class="reference internal" href="../../howto/deployment/wsgi/"><em>How to deploy with WSGI</em></a> for more details.</li>
|
||
|
</ul>
|
||
|
<div class="section" id="s-the-development-server">
|
||
|
<span id="the-development-server"></span><h3>The development server<a class="headerlink" href="#the-development-server" title="Permalink to this headline">¶</a></h3>
|
||
|
<p>Let's verify this worked. Change into the outer <tt class="file docutils literal"><span class="pre">mysite</span></tt> directory, if
|
||
|
you haven't already, and run the command <tt class="docutils literal"><span class="pre">python</span> <span class="pre">manage.py</span> <span class="pre">runserver</span></tt>. You'll
|
||
|
see the following output on the command line:</p>
|
||
|
<div class="highlight-python"><pre>Validating models...
|
||
|
0 errors found.
|
||
|
|
||
|
Django version 1.4, using settings 'mysite.settings'
|
||
|
Development server is running at http://127.0.0.1:8000/
|
||
|
Quit the server with CONTROL-C.</pre>
|
||
|
</div>
|
||
|
<p>You've started the Django development server, a lightweight Web server written
|
||
|
purely in Python. We've included this with Django so you can develop things
|
||
|
rapidly, without having to deal with configuring a production server -- such as
|
||
|
Apache -- until you're ready for production.</p>
|
||
|
<p>Now's a good time to note: DON'T use this server in anything resembling a
|
||
|
production environment. It's intended only for use while developing. (We're in
|
||
|
the business of making Web frameworks, not Web servers.)</p>
|
||
|
<p>Now that the server's running, visit <a class="reference external" href="http://127.0.0.1:8000/">http://127.0.0.1:8000/</a> with your Web
|
||
|
browser. You'll see a "Welcome to Django" page, in pleasant, light-blue pastel.
|
||
|
It worked!</p>
|
||
|
<div class="admonition-changing-the-port admonition ">
|
||
|
<p class="first admonition-title">Changing the port</p>
|
||
|
<p>By default, the <a class="reference internal" href="../../ref/django-admin/#django-admin-runserver"><tt class="xref std std-djadmin docutils literal"><span class="pre">runserver</span></tt></a> command starts the development server
|
||
|
on the internal IP at port 8000.</p>
|
||
|
<p>If you want to change the server's port, pass
|
||
|
it as a command-line argument. For instance, this command starts the server
|
||
|
on port 8080:</p>
|
||
|
<div class="highlight-bash"><div class="highlight"><pre>python manage.py runserver 8080
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>If you want to change the server's IP, pass it along with the port. So to
|
||
|
listen on all public IPs (useful if you want to show off your work on other
|
||
|
computers), use:</p>
|
||
|
<div class="highlight-bash"><div class="highlight"><pre>python manage.py runserver 0.0.0.0:8000
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p class="last">Full docs for the development server can be found in the
|
||
|
<a class="reference internal" href="../../ref/django-admin/#django-admin-runserver"><tt class="xref std std-djadmin docutils literal"><span class="pre">runserver</span></tt></a> reference.</p>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div class="section" id="s-database-setup">
|
||
|
<span id="database-setup"></span><h3>Database setup<a class="headerlink" href="#database-setup" title="Permalink to this headline">¶</a></h3>
|
||
|
<p>Now, edit <tt class="file docutils literal"><span class="pre">mysite/settings.py</span></tt>. It's a normal Python module with
|
||
|
module-level variables representing Django settings. Change the
|
||
|
following keys in the <a class="reference internal" href="../../ref/settings/#std:setting-DATABASES"><tt class="xref std std-setting docutils literal"><span class="pre">DATABASES</span></tt></a> <tt class="docutils literal"><span class="pre">'default'</span></tt> item to match
|
||
|
your database connection settings.</p>
|
||
|
<ul>
|
||
|
<li><p class="first"><a class="reference internal" href="../../ref/settings/#std:setting-DATABASE-ENGINE"><tt class="xref std std-setting docutils literal"><span class="pre">ENGINE</span></tt></a> -- Either
|
||
|
<tt class="docutils literal"><span class="pre">'django.db.backends.postgresql_psycopg2'</span></tt>,
|
||
|
<tt class="docutils literal"><span class="pre">'django.db.backends.mysql'</span></tt>, <tt class="docutils literal"><span class="pre">'django.db.backends.sqlite3'</span></tt> or
|
||
|
<tt class="docutils literal"><span class="pre">'django.db.backends.oracle'</span></tt>. Other backends are <a class="reference internal" href="../../ref/settings/#std:setting-DATABASE-ENGINE"><tt class="xref std std-setting docutils literal"><span class="pre">also</span> <span class="pre">available</span></tt></a>.</p>
|
||
|
</li>
|
||
|
<li><p class="first"><a class="reference internal" href="../../ref/settings/#std:setting-NAME"><tt class="xref std std-setting docutils literal"><span class="pre">NAME</span></tt></a> -- The name of your database. If you're using
|
||
|
SQLite, the database will be a file on your computer; in that
|
||
|
case, <a class="reference internal" href="../../ref/settings/#std:setting-NAME"><tt class="xref std std-setting docutils literal"><span class="pre">NAME</span></tt></a> should be the full absolute path,
|
||
|
including filename, of that file. If the file doesn't exist, it
|
||
|
will automatically be created when you synchronize the database
|
||
|
for the first time (see below).</p>
|
||
|
<p>When specifying the path, always use forward slashes, even on
|
||
|
Windows (e.g. <tt class="docutils literal"><span class="pre">C:/homes/user/mysite/sqlite3.db</span></tt>).</p>
|
||
|
</li>
|
||
|
<li><p class="first"><a class="reference internal" href="../../ref/settings/#std:setting-USER"><tt class="xref std std-setting docutils literal"><span class="pre">USER</span></tt></a> -- Your database username (not used for SQLite).</p>
|
||
|
</li>
|
||
|
<li><p class="first"><a class="reference internal" href="../../ref/settings/#std:setting-PASSWORD"><tt class="xref std std-setting docutils literal"><span class="pre">PASSWORD</span></tt></a> -- Your database password (not used for
|
||
|
SQLite).</p>
|
||
|
</li>
|
||
|
<li><p class="first"><a class="reference internal" href="../../ref/settings/#std:setting-HOST"><tt class="xref std std-setting docutils literal"><span class="pre">HOST</span></tt></a> -- The host your database is on. Leave this as
|
||
|
an empty string if your database server is on the same physical
|
||
|
machine (not used for SQLite).</p>
|
||
|
</li>
|
||
|
</ul>
|
||
|
<p>If you're new to databases, we recommend simply using SQLite by setting
|
||
|
<tt class="xref std std-setting docutils literal"><span class="pre">ENGINE</span></tt> to <tt class="docutils literal"><span class="pre">'django.db.backends.sqlite3'</span></tt> and <a class="reference internal" href="../../ref/settings/#std:setting-NAME"><tt class="xref std std-setting docutils literal"><span class="pre">NAME</span></tt></a> to
|
||
|
the place where you'd like to store the database. SQLite is included in Python,
|
||
|
so you won't need to install anything else to support your database.</p>
|
||
|
<div class="admonition note">
|
||
|
<p class="first admonition-title">Note</p>
|
||
|
<p>If you're using PostgreSQL or MySQL, make sure you've created a database by
|
||
|
this point. Do that with "<tt class="docutils literal"><span class="pre">CREATE</span> <span class="pre">DATABASE</span> <span class="pre">database_name;</span></tt>" within your
|
||
|
database's interactive prompt.</p>
|
||
|
<p class="last">If you're using SQLite, you don't need to create anything beforehand - the
|
||
|
database file will be created automatically when it is needed.</p>
|
||
|
</div>
|
||
|
<p>While you're editing <tt class="file docutils literal"><span class="pre">settings.py</span></tt>, set <a class="reference internal" href="../../ref/settings/#std:setting-TIME_ZONE"><tt class="xref std std-setting docutils literal"><span class="pre">TIME_ZONE</span></tt></a> to your
|
||
|
time zone. The default value is the Central time zone in the U.S. (Chicago).</p>
|
||
|
<p>Also, note the <a class="reference internal" href="../../ref/settings/#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a> setting toward the bottom of
|
||
|
the file. That holds the names of all Django applications that are
|
||
|
activated in this Django instance. Apps can be used in multiple projects, and
|
||
|
you can package and distribute them for use by others in their projects.</p>
|
||
|
<p>By default, <a class="reference internal" href="../../ref/settings/#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a> contains the following apps, all of which
|
||
|
come with Django:</p>
|
||
|
<ul class="simple">
|
||
|
<li><a class="reference internal" href="../../topics/auth/#module-django.contrib.auth" title="django.contrib.auth: Django's authentication framework."><tt class="xref py py-mod docutils literal"><span class="pre">django.contrib.auth</span></tt></a> -- An authentication system.</li>
|
||
|
<li><a class="reference internal" href="../../ref/contrib/contenttypes/#module-django.contrib.contenttypes" title="django.contrib.contenttypes: Provides generic interface to installed models."><tt class="xref py py-mod docutils literal"><span class="pre">django.contrib.contenttypes</span></tt></a> -- A framework for content types.</li>
|
||
|
<li><a class="reference internal" href="../../topics/http/sessions/#module-django.contrib.sessions" title="django.contrib.sessions: Provides session management for Django projects."><tt class="xref py py-mod docutils literal"><span class="pre">django.contrib.sessions</span></tt></a> -- A session framework.</li>
|
||
|
<li><a class="reference internal" href="../../ref/contrib/sites/#module-django.contrib.sites" title="django.contrib.sites: Lets you operate multiple Web sites from the same database and Django project"><tt class="xref py py-mod docutils literal"><span class="pre">django.contrib.sites</span></tt></a> -- A framework for managing multiple sites
|
||
|
with one Django installation.</li>
|
||
|
<li><a class="reference internal" href="../../ref/contrib/messages/#module-django.contrib.messages" title="django.contrib.messages: Provides cookie- and session-based temporary message storage."><tt class="xref py py-mod docutils literal"><span class="pre">django.contrib.messages</span></tt></a> -- A messaging framework.</li>
|
||
|
<li><a class="reference internal" href="../../ref/contrib/staticfiles/#module-django.contrib.staticfiles" title="django.contrib.staticfiles: An app for handling static files."><tt class="xref py py-mod docutils literal"><span class="pre">django.contrib.staticfiles</span></tt></a> -- A framework for managing
|
||
|
static files.</li>
|
||
|
</ul>
|
||
|
<p>These applications are included by default as a convenience for the common case.</p>
|
||
|
<p>Each of these applications makes use of at least one database table, though,
|
||
|
so we need to create the tables in the database before we can use them. To do
|
||
|
that, run the following command:</p>
|
||
|
<div class="highlight-bash"><div class="highlight"><pre>python manage.py syncdb
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>The <a class="reference internal" href="../../ref/django-admin/#django-admin-syncdb"><tt class="xref std std-djadmin docutils literal"><span class="pre">syncdb</span></tt></a> command looks at the <a class="reference internal" href="../../ref/settings/#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a> setting and
|
||
|
creates any necessary database tables according to the database settings in your
|
||
|
<tt class="file docutils literal"><span class="pre">settings.py</span></tt> file. You'll see a message for each database table it
|
||
|
creates, and you'll get a prompt asking you if you'd like to create a superuser
|
||
|
account for the authentication system. Go ahead and do that.</p>
|
||
|
<p>If you're interested, run the command-line client for your database and type
|
||
|
<tt class="docutils literal"><span class="pre">\dt</span></tt> (PostgreSQL), <tt class="docutils literal"><span class="pre">SHOW</span> <span class="pre">TABLES;</span></tt> (MySQL), or <tt class="docutils literal"><span class="pre">.schema</span></tt> (SQLite) to
|
||
|
display the tables Django created.</p>
|
||
|
<div class="admonition-for-the-minimalists admonition ">
|
||
|
<p class="first admonition-title">For the minimalists</p>
|
||
|
<p class="last">Like we said above, the default applications are included for the common
|
||
|
case, but not everybody needs them. If you don't need any or all of them,
|
||
|
feel free to comment-out or delete the appropriate line(s) from
|
||
|
<a class="reference internal" href="../../ref/settings/#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a> before running <a class="reference internal" href="../../ref/django-admin/#django-admin-syncdb"><tt class="xref std std-djadmin docutils literal"><span class="pre">syncdb</span></tt></a>. The
|
||
|
<a class="reference internal" href="../../ref/django-admin/#django-admin-syncdb"><tt class="xref std std-djadmin docutils literal"><span class="pre">syncdb</span></tt></a> command will only create tables for apps in
|
||
|
<a class="reference internal" href="../../ref/settings/#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a>.</p>
|
||
|
</div>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div class="section" id="s-creating-models">
|
||
|
<span id="s-id3"></span><span id="creating-models"></span><span id="id3"></span><h2>Creating models<a class="headerlink" href="#creating-models" title="Permalink to this headline">¶</a></h2>
|
||
|
<p>Now that your environment -- a "project" -- is set up, you're set to start
|
||
|
doing work.</p>
|
||
|
<p>Each application you write in Django consists of a Python package, somewhere
|
||
|
on your <a class="reference external" href="http://docs.python.org/tutorial/modules.html#the-module-search-path">Python path</a>, that follows a certain convention. Django comes with a
|
||
|
utility that automatically generates the basic directory structure of an app,
|
||
|
so you can focus on writing code rather than creating directories.</p>
|
||
|
<div class="admonition-projects-vs-apps admonition ">
|
||
|
<p class="first admonition-title">Projects vs. apps</p>
|
||
|
<p class="last">What's the difference between a project and an app? An app is a Web
|
||
|
application that does something -- e.g., a Weblog system, a database of
|
||
|
public records or a simple poll app. A project is a collection of
|
||
|
configuration and apps for a particular Web site. A project can contain
|
||
|
multiple apps. An app can be in multiple projects.</p>
|
||
|
</div>
|
||
|
<p>Your apps can live anywhere on your <a class="reference external" href="http://docs.python.org/tutorial/modules.html#the-module-search-path">Python path</a>. In this tutorial, we'll
|
||
|
create our poll app right next to your <tt class="file docutils literal"><span class="pre">manage.py</span></tt> file so that it can be
|
||
|
imported as its own top-level module, rather than a submodule of <tt class="docutils literal"><span class="pre">mysite</span></tt>.</p>
|
||
|
<p>To create your app, make sure you're in the same directory as <tt class="file docutils literal"><span class="pre">manage.py</span></tt>
|
||
|
and type this command:</p>
|
||
|
<div class="highlight-bash"><div class="highlight"><pre>python manage.py startapp polls
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>That'll create a directory <tt class="file docutils literal"><span class="pre">polls</span></tt>, which is laid out like this:</p>
|
||
|
<div class="highlight-python"><pre>polls/
|
||
|
__init__.py
|
||
|
models.py
|
||
|
tests.py
|
||
|
views.py</pre>
|
||
|
</div>
|
||
|
<p>This directory structure will house the poll application.</p>
|
||
|
<p>The first step in writing a database Web app in Django is to define your models
|
||
|
-- essentially, your database layout, with additional metadata.</p>
|
||
|
<div class="admonition-philosophy admonition ">
|
||
|
<p class="first admonition-title">Philosophy</p>
|
||
|
<p class="last">A model is the single, definitive source of data about your data. It contains
|
||
|
the essential fields and behaviors of the data you're storing. Django follows
|
||
|
the <a class="reference internal" href="../../misc/design-philosophies/#dry"><em>DRY Principle</em></a>. The goal is to define your data model in one
|
||
|
place and automatically derive things from it.</p>
|
||
|
</div>
|
||
|
<p>In our simple poll app, we'll create two models: polls and choices. A poll has
|
||
|
a question and a publication date. A choice has two fields: the text of the
|
||
|
choice and a vote tally. Each choice is associated with a poll.</p>
|
||
|
<p>These concepts are represented by simple Python classes. Edit the
|
||
|
<tt class="file docutils literal"><span class="pre">polls/models.py</span></tt> file so it looks like this:</p>
|
||
|
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.db</span> <span class="kn">import</span> <span class="n">models</span>
|
||
|
|
||
|
<span class="k">class</span> <span class="nc">Poll</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
|
||
|
<span class="n">question</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">200</span><span class="p">)</span>
|
||
|
<span class="n">pub_date</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">DateTimeField</span><span class="p">(</span><span class="s">'date published'</span><span class="p">)</span>
|
||
|
|
||
|
<span class="k">class</span> <span class="nc">Choice</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
|
||
|
<span class="n">poll</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">ForeignKey</span><span class="p">(</span><span class="n">Poll</span><span class="p">)</span>
|
||
|
<span class="n">choice</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">200</span><span class="p">)</span>
|
||
|
<span class="n">votes</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">IntegerField</span><span class="p">()</span>
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>The code is straightforward. Each model is represented by a class that
|
||
|
subclasses <a class="reference internal" href="../../ref/models/instances/#django.db.models.Model" title="django.db.models.Model"><tt class="xref py py-class docutils literal"><span class="pre">django.db.models.Model</span></tt></a>. Each model has a number of class
|
||
|
variables, each of which represents a database field in the model.</p>
|
||
|
<p>Each field is represented by an instance of a <a class="reference internal" href="../../howto/custom-model-fields/#django.db.models.Field" title="django.db.models.Field"><tt class="xref py py-class docutils literal"><span class="pre">Field</span></tt></a>
|
||
|
class -- e.g., <a class="reference internal" href="../../ref/models/fields/#django.db.models.CharField" title="django.db.models.CharField"><tt class="xref py py-class docutils literal"><span class="pre">CharField</span></tt></a> for character fields and
|
||
|
<a class="reference internal" href="../../ref/models/fields/#django.db.models.DateTimeField" title="django.db.models.DateTimeField"><tt class="xref py py-class docutils literal"><span class="pre">DateTimeField</span></tt></a> for datetimes. This tells Django what
|
||
|
type of data each field holds.</p>
|
||
|
<p>The name of each <a class="reference internal" href="../../howto/custom-model-fields/#django.db.models.Field" title="django.db.models.Field"><tt class="xref py py-class docutils literal"><span class="pre">Field</span></tt></a> instance (e.g. <tt class="docutils literal"><span class="pre">question</span></tt> or
|
||
|
<tt class="docutils literal"><span class="pre">pub_date</span></tt> ) is the field's name, in machine-friendly format. You'll use this
|
||
|
value in your Python code, and your database will use it as the column name.</p>
|
||
|
<p>You can use an optional first positional argument to a
|
||
|
<a class="reference internal" href="../../howto/custom-model-fields/#django.db.models.Field" title="django.db.models.Field"><tt class="xref py py-class docutils literal"><span class="pre">Field</span></tt></a> to designate a human-readable name. That's used
|
||
|
in a couple of introspective parts of Django, and it doubles as documentation.
|
||
|
If this field isn't provided, Django will use the machine-readable name. In this
|
||
|
example, we've only defined a human-readable name for <tt class="docutils literal"><span class="pre">Poll.pub_date</span></tt>. For all
|
||
|
other fields in this model, the field's machine-readable name will suffice as
|
||
|
its human-readable name.</p>
|
||
|
<p>Some <a class="reference internal" href="../../howto/custom-model-fields/#django.db.models.Field" title="django.db.models.Field"><tt class="xref py py-class docutils literal"><span class="pre">Field</span></tt></a> classes have required elements.
|
||
|
<a class="reference internal" href="../../ref/models/fields/#django.db.models.CharField" title="django.db.models.CharField"><tt class="xref py py-class docutils literal"><span class="pre">CharField</span></tt></a>, for example, requires that you give it a
|
||
|
<tt class="xref py py-attr docutils literal"><span class="pre">max_length</span></tt>. That's used not only in the database
|
||
|
schema, but in validation, as we'll soon see.</p>
|
||
|
<p>Finally, note a relationship is defined, using
|
||
|
<a class="reference internal" href="../../ref/models/fields/#django.db.models.ForeignKey" title="django.db.models.ForeignKey"><tt class="xref py py-class docutils literal"><span class="pre">ForeignKey</span></tt></a>. That tells Django each Choice is related
|
||
|
to a single Poll. Django supports all the common database relationships:
|
||
|
many-to-ones, many-to-manys and one-to-ones.</p>
|
||
|
</div>
|
||
|
<div class="section" id="s-activating-models">
|
||
|
<span id="activating-models"></span><h2>Activating models<a class="headerlink" href="#activating-models" title="Permalink to this headline">¶</a></h2>
|
||
|
<p>That small bit of model code gives Django a lot of information. With it, Django
|
||
|
is able to:</p>
|
||
|
<ul class="simple">
|
||
|
<li>Create a database schema (<tt class="docutils literal"><span class="pre">CREATE</span> <span class="pre">TABLE</span></tt> statements) for this app.</li>
|
||
|
<li>Create a Python database-access API for accessing Poll and Choice objects.</li>
|
||
|
</ul>
|
||
|
<p>But first we need to tell our project that the <tt class="docutils literal"><span class="pre">polls</span></tt> app is installed.</p>
|
||
|
<div class="admonition-philosophy admonition ">
|
||
|
<p class="first admonition-title">Philosophy</p>
|
||
|
<p class="last">Django apps are "pluggable": You can use an app in multiple projects, and
|
||
|
you can distribute apps, because they don't have to be tied to a given
|
||
|
Django installation.</p>
|
||
|
</div>
|
||
|
<p>Edit the <tt class="file docutils literal"><span class="pre">settings.py</span></tt> file again, and change the
|
||
|
<a class="reference internal" href="../../ref/settings/#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a> setting to include the string <tt class="docutils literal"><span class="pre">'polls'</span></tt>. So
|
||
|
it'll look like this:</p>
|
||
|
<div class="highlight-python"><div class="highlight"><pre><span class="n">INSTALLED_APPS</span> <span class="o">=</span> <span class="p">(</span>
|
||
|
<span class="s">'django.contrib.auth'</span><span class="p">,</span>
|
||
|
<span class="s">'django.contrib.contenttypes'</span><span class="p">,</span>
|
||
|
<span class="s">'django.contrib.sessions'</span><span class="p">,</span>
|
||
|
<span class="s">'django.contrib.sites'</span><span class="p">,</span>
|
||
|
<span class="s">'django.contrib.messages'</span><span class="p">,</span>
|
||
|
<span class="s">'django.contrib.staticfiles'</span><span class="p">,</span>
|
||
|
<span class="c"># Uncomment the next line to enable the admin:</span>
|
||
|
<span class="c"># 'django.contrib.admin',</span>
|
||
|
<span class="c"># Uncomment the next line to enable admin documentation:</span>
|
||
|
<span class="c"># 'django.contrib.admindocs',</span>
|
||
|
<span class="s">'polls'</span><span class="p">,</span>
|
||
|
<span class="p">)</span>
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>Now Django knows to include the <tt class="docutils literal"><span class="pre">polls</span></tt> app. Let's run another
|
||
|
command:</p>
|
||
|
<div class="highlight-bash"><div class="highlight"><pre>python manage.py sql polls
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>You should see something similar to the following (the <tt class="docutils literal"><span class="pre">CREATE</span> <span class="pre">TABLE</span></tt> SQL
|
||
|
statements for the polls app):</p>
|
||
|
<div class="highlight-sql"><div class="highlight"><pre><span class="k">BEGIN</span><span class="p">;</span>
|
||
|
<span class="k">CREATE</span> <span class="k">TABLE</span> <span class="ss">"polls_poll"</span> <span class="p">(</span>
|
||
|
<span class="ss">"id"</span> <span class="nb">serial</span> <span class="k">NOT</span> <span class="k">NULL</span> <span class="k">PRIMARY</span> <span class="k">KEY</span><span class="p">,</span>
|
||
|
<span class="ss">"question"</span> <span class="nb">varchar</span><span class="p">(</span><span class="mi">200</span><span class="p">)</span> <span class="k">NOT</span> <span class="k">NULL</span><span class="p">,</span>
|
||
|
<span class="ss">"pub_date"</span> <span class="k">timestamp</span> <span class="k">with</span> <span class="n">time</span> <span class="k">zone</span> <span class="k">NOT</span> <span class="k">NULL</span>
|
||
|
<span class="p">);</span>
|
||
|
<span class="k">CREATE</span> <span class="k">TABLE</span> <span class="ss">"polls_choice"</span> <span class="p">(</span>
|
||
|
<span class="ss">"id"</span> <span class="nb">serial</span> <span class="k">NOT</span> <span class="k">NULL</span> <span class="k">PRIMARY</span> <span class="k">KEY</span><span class="p">,</span>
|
||
|
<span class="ss">"poll_id"</span> <span class="nb">integer</span> <span class="k">NOT</span> <span class="k">NULL</span> <span class="k">REFERENCES</span> <span class="ss">"polls_poll"</span> <span class="p">(</span><span class="ss">"id"</span><span class="p">)</span> <span class="k">DEFERRABLE</span> <span class="k">INITIALLY</span> <span class="k">DEFERRED</span><span class="p">,</span>
|
||
|
<span class="ss">"choice"</span> <span class="nb">varchar</span><span class="p">(</span><span class="mi">200</span><span class="p">)</span> <span class="k">NOT</span> <span class="k">NULL</span><span class="p">,</span>
|
||
|
<span class="ss">"votes"</span> <span class="nb">integer</span> <span class="k">NOT</span> <span class="k">NULL</span>
|
||
|
<span class="p">);</span>
|
||
|
<span class="k">COMMIT</span><span class="p">;</span>
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>Note the following:</p>
|
||
|
<ul class="simple">
|
||
|
<li>The exact output will vary depending on the database you are using.</li>
|
||
|
<li>Table names are automatically generated by combining the name of the app
|
||
|
(<tt class="docutils literal"><span class="pre">polls</span></tt>) and the lowercase name of the model -- <tt class="docutils literal"><span class="pre">poll</span></tt> and
|
||
|
<tt class="docutils literal"><span class="pre">choice</span></tt>. (You can override this behavior.)</li>
|
||
|
<li>Primary keys (IDs) are added automatically. (You can override this, too.)</li>
|
||
|
<li>By convention, Django appends <tt class="docutils literal"><span class="pre">"_id"</span></tt> to the foreign key field name.
|
||
|
(Yes, you can override this, as well.)</li>
|
||
|
<li>The foreign key relationship is made explicit by a <tt class="docutils literal"><span class="pre">REFERENCES</span></tt>
|
||
|
statement.</li>
|
||
|
<li>It's tailored to the database you're using, so database-specific field
|
||
|
types such as <tt class="docutils literal"><span class="pre">auto_increment</span></tt> (MySQL), <tt class="docutils literal"><span class="pre">serial</span></tt> (PostgreSQL), or
|
||
|
<tt class="docutils literal"><span class="pre">integer</span> <span class="pre">primary</span> <span class="pre">key</span></tt> (SQLite) are handled for you automatically. Same
|
||
|
goes for quoting of field names -- e.g., using double quotes or single
|
||
|
quotes. The author of this tutorial runs PostgreSQL, so the example
|
||
|
output is in PostgreSQL syntax.</li>
|
||
|
<li>The <a class="reference internal" href="../../ref/django-admin/#django-admin-sql"><tt class="xref std std-djadmin docutils literal"><span class="pre">sql</span></tt></a> command doesn't actually run the SQL in your database -
|
||
|
it just prints it to the screen so that you can see what SQL Django thinks
|
||
|
is required. If you wanted to, you could copy and paste this SQL into your
|
||
|
database prompt. However, as we will see shortly, Django provides an
|
||
|
easier way of committing the SQL to the database.</li>
|
||
|
</ul>
|
||
|
<p>If you're interested, also run the following commands:</p>
|
||
|
<ul class="simple">
|
||
|
<li><a class="reference internal" href="../../ref/django-admin/#django-admin-validate"><tt class="xref std std-djadmin docutils literal"><span class="pre">python</span> <span class="pre">manage.py</span> <span class="pre">validate</span></tt></a> -- Checks for any errors
|
||
|
in the construction of your models.</li>
|
||
|
<li><a class="reference internal" href="../../ref/django-admin/#django-admin-sqlcustom"><tt class="xref std std-djadmin docutils literal"><span class="pre">python</span> <span class="pre">manage.py</span> <span class="pre">sqlcustom</span> <span class="pre">polls</span></tt></a> -- Outputs any
|
||
|
<a class="reference internal" href="../../howto/initial-data/#initial-sql"><em>custom SQL statements</em></a> (such as table modifications or
|
||
|
constraints) that are defined for the application.</li>
|
||
|
<li><a class="reference internal" href="../../ref/django-admin/#django-admin-sqlclear"><tt class="xref std std-djadmin docutils literal"><span class="pre">python</span> <span class="pre">manage.py</span> <span class="pre">sqlclear</span> <span class="pre">polls</span></tt></a> -- Outputs the
|
||
|
necessary <tt class="docutils literal"><span class="pre">DROP</span> <span class="pre">TABLE</span></tt> statements for this app, according to which
|
||
|
tables already exist in your database (if any).</li>
|
||
|
<li><a class="reference internal" href="../../ref/django-admin/#django-admin-sqlindexes"><tt class="xref std std-djadmin docutils literal"><span class="pre">python</span> <span class="pre">manage.py</span> <span class="pre">sqlindexes</span> <span class="pre">polls</span></tt></a> -- Outputs the
|
||
|
<tt class="docutils literal"><span class="pre">CREATE</span> <span class="pre">INDEX</span></tt> statements for this app.</li>
|
||
|
<li><a class="reference internal" href="../../ref/django-admin/#django-admin-sqlall"><tt class="xref std std-djadmin docutils literal"><span class="pre">python</span> <span class="pre">manage.py</span> <span class="pre">sqlall</span> <span class="pre">polls</span></tt></a> -- A combination of all
|
||
|
the SQL from the <a class="reference internal" href="../../ref/django-admin/#django-admin-sql"><tt class="xref std std-djadmin docutils literal"><span class="pre">sql</span></tt></a>, <a class="reference internal" href="../../ref/django-admin/#django-admin-sqlcustom"><tt class="xref std std-djadmin docutils literal"><span class="pre">sqlcustom</span></tt></a>, and
|
||
|
<a class="reference internal" href="../../ref/django-admin/#django-admin-sqlindexes"><tt class="xref std std-djadmin docutils literal"><span class="pre">sqlindexes</span></tt></a> commands.</li>
|
||
|
</ul>
|
||
|
<p>Looking at the output of those commands can help you understand what's actually
|
||
|
happening under the hood.</p>
|
||
|
<p>Now, run <a class="reference internal" href="../../ref/django-admin/#django-admin-syncdb"><tt class="xref std std-djadmin docutils literal"><span class="pre">syncdb</span></tt></a> again to create those model tables in your database:</p>
|
||
|
<div class="highlight-bash"><div class="highlight"><pre>python manage.py syncdb
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>The <a class="reference internal" href="../../ref/django-admin/#django-admin-syncdb"><tt class="xref std std-djadmin docutils literal"><span class="pre">syncdb</span></tt></a> command runs the SQL from <a class="reference internal" href="../../ref/django-admin/#django-admin-sqlall"><tt class="xref std std-djadmin docutils literal"><span class="pre">sqlall</span></tt></a> on your
|
||
|
database for all apps in <a class="reference internal" href="../../ref/settings/#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a> that don't already exist in
|
||
|
your database. This creates all the tables, initial data and indexes for any
|
||
|
apps you've added to your project since the last time you ran syncdb.
|
||
|
<a class="reference internal" href="../../ref/django-admin/#django-admin-syncdb"><tt class="xref std std-djadmin docutils literal"><span class="pre">syncdb</span></tt></a> can be called as often as you like, and it will only ever
|
||
|
create the tables that don't exist.</p>
|
||
|
<p>Read the <a class="reference internal" href="../../ref/django-admin/"><em>django-admin.py documentation</em></a> for full
|
||
|
information on what the <tt class="docutils literal"><span class="pre">manage.py</span></tt> utility can do.</p>
|
||
|
</div>
|
||
|
<div class="section" id="s-playing-with-the-api">
|
||
|
<span id="playing-with-the-api"></span><h2>Playing with the API<a class="headerlink" href="#playing-with-the-api" title="Permalink to this headline">¶</a></h2>
|
||
|
<p>Now, let's hop into the interactive Python shell and play around with the free
|
||
|
API Django gives you. To invoke the Python shell, use this command:</p>
|
||
|
<div class="highlight-bash"><div class="highlight"><pre>python manage.py shell
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>We're using this instead of simply typing "python", because <tt class="file docutils literal"><span class="pre">manage.py</span></tt>
|
||
|
sets the <tt class="docutils literal"><span class="pre">DJANGO_SETTINGS_MODULE</span></tt> environment variable, which gives Django
|
||
|
the Python import path to your <tt class="file docutils literal"><span class="pre">settings.py</span></tt> file.</p>
|
||
|
<div class="admonition-bypassing-manage-py admonition ">
|
||
|
<p class="first admonition-title">Bypassing manage.py</p>
|
||
|
<p>If you'd rather not use <tt class="file docutils literal"><span class="pre">manage.py</span></tt>, no problem. Just set the
|
||
|
<tt class="docutils literal"><span class="pre">DJANGO_SETTINGS_MODULE</span></tt> environment variable to <tt class="docutils literal"><span class="pre">mysite.settings</span></tt> and
|
||
|
run <tt class="docutils literal"><span class="pre">python</span></tt> from the same directory <tt class="file docutils literal"><span class="pre">manage.py</span></tt> is in (or ensure
|
||
|
that directory is on the Python path, so that <tt class="docutils literal"><span class="pre">import</span> <span class="pre">mysite</span></tt> works).</p>
|
||
|
<p class="last">For more information on all of this, see the <a class="reference internal" href="../../ref/django-admin/"><em>django-admin.py
|
||
|
documentation</em></a>.</p>
|
||
|
</div>
|
||
|
<p>Once you're in the shell, explore the <a class="reference internal" href="../../topics/db/queries/"><em>database API</em></a>:</p>
|
||
|
<div class="highlight-python"><div class="highlight"><pre><span class="gp">>>> </span><span class="kn">from</span> <span class="nn">polls.models</span> <span class="kn">import</span> <span class="n">Poll</span><span class="p">,</span> <span class="n">Choice</span> <span class="c"># Import the model classes we just wrote.</span>
|
||
|
|
||
|
<span class="go"># No polls are in the system yet.</span>
|
||
|
<span class="gp">>>> </span><span class="n">Poll</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">all</span><span class="p">()</span>
|
||
|
<span class="go">[]</span>
|
||
|
|
||
|
<span class="go"># Create a new Poll.</span>
|
||
|
<span class="go"># Support for time zones is enabled in the default settings file, so</span>
|
||
|
<span class="go"># Django expects a datetime with tzinfo for pub_date. Use timezone.now()</span>
|
||
|
<span class="go"># instead of datetime.datetime.now() and it will do the right thing.</span>
|
||
|
<span class="gp">>>> </span><span class="kn">from</span> <span class="nn">django.utils</span> <span class="kn">import</span> <span class="n">timezone</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span> <span class="o">=</span> <span class="n">Poll</span><span class="p">(</span><span class="n">question</span><span class="o">=</span><span class="s">"What's new?"</span><span class="p">,</span> <span class="n">pub_date</span><span class="o">=</span><span class="n">timezone</span><span class="o">.</span><span class="n">now</span><span class="p">())</span>
|
||
|
|
||
|
<span class="go"># Save the object into the database. You have to call save() explicitly.</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span><span class="o">.</span><span class="n">save</span><span class="p">()</span>
|
||
|
|
||
|
<span class="go"># Now it has an ID. Note that this might say "1L" instead of "1", depending</span>
|
||
|
<span class="go"># on which database you're using. That's no biggie; it just means your</span>
|
||
|
<span class="go"># database backend prefers to return integers as Python long integer</span>
|
||
|
<span class="go"># objects.</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span><span class="o">.</span><span class="n">id</span>
|
||
|
<span class="go">1</span>
|
||
|
|
||
|
<span class="go"># Access database columns via Python attributes.</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span><span class="o">.</span><span class="n">question</span>
|
||
|
<span class="go">"What's new?"</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span><span class="o">.</span><span class="n">pub_date</span>
|
||
|
<span class="go">datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<UTC>)</span>
|
||
|
|
||
|
<span class="go"># Change values by changing the attributes, then calling save().</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span><span class="o">.</span><span class="n">question</span> <span class="o">=</span> <span class="s">"What's up?"</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span><span class="o">.</span><span class="n">save</span><span class="p">()</span>
|
||
|
|
||
|
<span class="go"># objects.all() displays all the polls in the database.</span>
|
||
|
<span class="gp">>>> </span><span class="n">Poll</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">all</span><span class="p">()</span>
|
||
|
<span class="go">[<Poll: Poll object>]</span>
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>Wait a minute. <tt class="docutils literal"><span class="pre"><Poll:</span> <span class="pre">Poll</span> <span class="pre">object></span></tt> is, utterly, an unhelpful representation
|
||
|
of this object. Let's fix that by editing the polls model (in the
|
||
|
<tt class="docutils literal"><span class="pre">polls/models.py</span></tt> file) and adding a
|
||
|
<a class="reference internal" href="../../ref/models/instances/#django.db.models.Model.__unicode__" title="django.db.models.Model.__unicode__"><tt class="xref py py-meth docutils literal"><span class="pre">__unicode__()</span></tt></a> method to both <tt class="docutils literal"><span class="pre">Poll</span></tt> and
|
||
|
<tt class="docutils literal"><span class="pre">Choice</span></tt>:</p>
|
||
|
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Poll</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
|
||
|
<span class="c"># ...</span>
|
||
|
<span class="k">def</span> <span class="nf">__unicode__</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
|
||
|
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">question</span>
|
||
|
|
||
|
<span class="k">class</span> <span class="nc">Choice</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
|
||
|
<span class="c"># ...</span>
|
||
|
<span class="k">def</span> <span class="nf">__unicode__</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
|
||
|
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">choice</span>
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>It's important to add <a class="reference internal" href="../../ref/models/instances/#django.db.models.Model.__unicode__" title="django.db.models.Model.__unicode__"><tt class="xref py py-meth docutils literal"><span class="pre">__unicode__()</span></tt></a> methods to
|
||
|
your models, not only for your own sanity when dealing with the interactive
|
||
|
prompt, but also because objects' representations are used throughout Django's
|
||
|
automatically-generated admin.</p>
|
||
|
<div class="admonition-why-meth-django-db-models-model-unicode-and-not-meth-django-db-models-model-str admonition ">
|
||
|
<p class="first admonition-title">Why <a class="reference internal" href="../../ref/models/instances/#django.db.models.Model.__unicode__" title="django.db.models.Model.__unicode__"><tt class="xref py py-meth docutils literal"><span class="pre">__unicode__()</span></tt></a> and not
|
||
|
<a class="reference internal" href="../../ref/models/instances/#django.db.models.Model.__str__" title="django.db.models.Model.__str__"><tt class="xref py py-meth docutils literal"><span class="pre">__str__()</span></tt></a>?</p>
|
||
|
<p>If you're familiar with Python, you might be in the habit of adding
|
||
|
<a class="reference internal" href="../../ref/models/instances/#django.db.models.Model.__str__" title="django.db.models.Model.__str__"><tt class="xref py py-meth docutils literal"><span class="pre">__str__()</span></tt></a> methods to your classes, not
|
||
|
<a class="reference internal" href="../../ref/models/instances/#django.db.models.Model.__unicode__" title="django.db.models.Model.__unicode__"><tt class="xref py py-meth docutils literal"><span class="pre">__unicode__()</span></tt></a> methods. We use
|
||
|
<a class="reference internal" href="../../ref/models/instances/#django.db.models.Model.__unicode__" title="django.db.models.Model.__unicode__"><tt class="xref py py-meth docutils literal"><span class="pre">__unicode__()</span></tt></a> here because Django models deal
|
||
|
with Unicode by default. All data stored in your database is converted to
|
||
|
Unicode when it's returned.</p>
|
||
|
<p>Django models have a default <a class="reference internal" href="../../ref/models/instances/#django.db.models.Model.__str__" title="django.db.models.Model.__str__"><tt class="xref py py-meth docutils literal"><span class="pre">__str__()</span></tt></a> method
|
||
|
that calls <a class="reference internal" href="../../ref/models/instances/#django.db.models.Model.__unicode__" title="django.db.models.Model.__unicode__"><tt class="xref py py-meth docutils literal"><span class="pre">__unicode__()</span></tt></a> and converts the
|
||
|
result to a UTF-8 bytestring. This means that <tt class="docutils literal"><span class="pre">unicode(p)</span></tt> will return a
|
||
|
Unicode string, and <tt class="docutils literal"><span class="pre">str(p)</span></tt> will return a normal string, with characters
|
||
|
encoded as UTF-8.</p>
|
||
|
<p class="last">If all of this is gibberish to you, just remember to add
|
||
|
<a class="reference internal" href="../../ref/models/instances/#django.db.models.Model.__unicode__" title="django.db.models.Model.__unicode__"><tt class="xref py py-meth docutils literal"><span class="pre">__unicode__()</span></tt></a> methods to your models. With any
|
||
|
luck, things should Just Work for you.</p>
|
||
|
</div>
|
||
|
<p>Note these are normal Python methods. Let's add a custom method, just for
|
||
|
demonstration:</p>
|
||
|
<div class="highlight-python"><div class="highlight"><pre><span class="kn">import</span> <span class="nn">datetime</span>
|
||
|
<span class="kn">from</span> <span class="nn">django.utils</span> <span class="kn">import</span> <span class="n">timezone</span>
|
||
|
<span class="c"># ...</span>
|
||
|
<span class="k">class</span> <span class="nc">Poll</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
|
||
|
<span class="c"># ...</span>
|
||
|
<span class="k">def</span> <span class="nf">was_published_recently</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
|
||
|
<span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">pub_date</span> <span class="o">>=</span> <span class="n">timezone</span><span class="o">.</span><span class="n">now</span><span class="p">()</span> <span class="o">-</span> <span class="n">datetime</span><span class="o">.</span><span class="n">timedelta</span><span class="p">(</span><span class="n">days</span><span class="o">=</span><span class="mi">1</span><span class="p">)</span>
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>Note the addition of <tt class="docutils literal"><span class="pre">import</span> <span class="pre">datetime</span></tt> and <tt class="docutils literal"><span class="pre">from</span> <span class="pre">django.utils</span> <span class="pre">import</span>
|
||
|
<span class="pre">timezone</span></tt>, to reference Python's standard <a class="reference external" href="http://docs.python.org/2.7/library/datetime.html#datetime" title="(in Python v2.7)"><tt class="xref py py-mod docutils literal"><span class="pre">datetime</span></tt></a> module and Django's
|
||
|
time-zone-related utilities in <a class="reference internal" href="../../ref/utils/#module-django.utils.timezone" title="django.utils.timezone: Timezone support."><tt class="xref py py-mod docutils literal"><span class="pre">django.utils.timezone</span></tt></a>, respectively. If
|
||
|
you aren't familiar with time zone handling in Python, you can learn more in
|
||
|
the <a class="reference internal" href="../../topics/i18n/timezones/"><em>time zone support docs</em></a>.</p>
|
||
|
<p>Save these changes and start a new Python interactive shell by running
|
||
|
<tt class="docutils literal"><span class="pre">python</span> <span class="pre">manage.py</span> <span class="pre">shell</span></tt> again:</p>
|
||
|
<div class="highlight-python"><div class="highlight"><pre><span class="gp">>>> </span><span class="kn">from</span> <span class="nn">polls.models</span> <span class="kn">import</span> <span class="n">Poll</span><span class="p">,</span> <span class="n">Choice</span>
|
||
|
|
||
|
<span class="go"># Make sure our __unicode__() addition worked.</span>
|
||
|
<span class="gp">>>> </span><span class="n">Poll</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">all</span><span class="p">()</span>
|
||
|
<span class="go">[<Poll: What's up?>]</span>
|
||
|
|
||
|
<span class="go"># Django provides a rich database lookup API that's entirely driven by</span>
|
||
|
<span class="go"># keyword arguments.</span>
|
||
|
<span class="gp">>>> </span><span class="n">Poll</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">filter</span><span class="p">(</span><span class="nb">id</span><span class="o">=</span><span class="mi">1</span><span class="p">)</span>
|
||
|
<span class="go">[<Poll: What's up?>]</span>
|
||
|
<span class="gp">>>> </span><span class="n">Poll</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">filter</span><span class="p">(</span><span class="n">question__startswith</span><span class="o">=</span><span class="s">'What'</span><span class="p">)</span>
|
||
|
<span class="go">[<Poll: What's up?>]</span>
|
||
|
|
||
|
<span class="go"># Get the poll whose year is 2012.</span>
|
||
|
<span class="gp">>>> </span><span class="n">Poll</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="n">pub_date__year</span><span class="o">=</span><span class="mi">2012</span><span class="p">)</span>
|
||
|
<span class="go"><Poll: What's up?></span>
|
||
|
|
||
|
<span class="gp">>>> </span><span class="n">Poll</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="nb">id</span><span class="o">=</span><span class="mi">2</span><span class="p">)</span>
|
||
|
<span class="gt">Traceback (most recent call last):</span>
|
||
|
<span class="o">...</span>
|
||
|
<span class="nc">DoesNotExist: Poll matching query does not exist. Lookup parameters were {'id'</span>: <span class="n-Identifier">2}</span>
|
||
|
|
||
|
<span class="go"># Lookup by a primary key is the most common case, so Django provides a</span>
|
||
|
<span class="go"># shortcut for primary-key exact lookups.</span>
|
||
|
<span class="go"># The following is identical to Poll.objects.get(id=1).</span>
|
||
|
<span class="gp">>>> </span><span class="n">Poll</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="n">pk</span><span class="o">=</span><span class="mi">1</span><span class="p">)</span>
|
||
|
<span class="go"><Poll: What's up?></span>
|
||
|
|
||
|
<span class="go"># Make sure our custom method worked.</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span> <span class="o">=</span> <span class="n">Poll</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="n">pk</span><span class="o">=</span><span class="mi">1</span><span class="p">)</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span><span class="o">.</span><span class="n">was_published_recently</span><span class="p">()</span>
|
||
|
<span class="go">True</span>
|
||
|
|
||
|
<span class="go"># Give the Poll a couple of Choices. The create call constructs a new</span>
|
||
|
<span class="go"># choice object, does the INSERT statement, adds the choice to the set</span>
|
||
|
<span class="go"># of available choices and returns the new Choice object. Django creates</span>
|
||
|
<span class="go"># a set to hold the "other side" of a ForeignKey relation</span>
|
||
|
<span class="go"># (e.g. a poll's choices) which can be accessed via the API.</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span> <span class="o">=</span> <span class="n">Poll</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="n">pk</span><span class="o">=</span><span class="mi">1</span><span class="p">)</span>
|
||
|
|
||
|
<span class="go"># Display any choices from the related object set -- none so far.</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span><span class="o">.</span><span class="n">choice_set</span><span class="o">.</span><span class="n">all</span><span class="p">()</span>
|
||
|
<span class="go">[]</span>
|
||
|
|
||
|
<span class="go"># Create three choices.</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span><span class="o">.</span><span class="n">choice_set</span><span class="o">.</span><span class="n">create</span><span class="p">(</span><span class="n">choice</span><span class="o">=</span><span class="s">'Not much'</span><span class="p">,</span> <span class="n">votes</span><span class="o">=</span><span class="mi">0</span><span class="p">)</span>
|
||
|
<span class="go"><Choice: Not much></span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span><span class="o">.</span><span class="n">choice_set</span><span class="o">.</span><span class="n">create</span><span class="p">(</span><span class="n">choice</span><span class="o">=</span><span class="s">'The sky'</span><span class="p">,</span> <span class="n">votes</span><span class="o">=</span><span class="mi">0</span><span class="p">)</span>
|
||
|
<span class="go"><Choice: The sky></span>
|
||
|
<span class="gp">>>> </span><span class="n">c</span> <span class="o">=</span> <span class="n">p</span><span class="o">.</span><span class="n">choice_set</span><span class="o">.</span><span class="n">create</span><span class="p">(</span><span class="n">choice</span><span class="o">=</span><span class="s">'Just hacking again'</span><span class="p">,</span> <span class="n">votes</span><span class="o">=</span><span class="mi">0</span><span class="p">)</span>
|
||
|
|
||
|
<span class="go"># Choice objects have API access to their related Poll objects.</span>
|
||
|
<span class="gp">>>> </span><span class="n">c</span><span class="o">.</span><span class="n">poll</span>
|
||
|
<span class="go"><Poll: What's up?></span>
|
||
|
|
||
|
<span class="go"># And vice versa: Poll objects get access to Choice objects.</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span><span class="o">.</span><span class="n">choice_set</span><span class="o">.</span><span class="n">all</span><span class="p">()</span>
|
||
|
<span class="go">[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]</span>
|
||
|
<span class="gp">>>> </span><span class="n">p</span><span class="o">.</span><span class="n">choice_set</span><span class="o">.</span><span class="n">count</span><span class="p">()</span>
|
||
|
<span class="go">3</span>
|
||
|
|
||
|
<span class="go"># The API automatically follows relationships as far as you need.</span>
|
||
|
<span class="go"># Use double underscores to separate relationships.</span>
|
||
|
<span class="go"># This works as many levels deep as you want; there's no limit.</span>
|
||
|
<span class="go"># Find all Choices for any poll whose pub_date is in 2012.</span>
|
||
|
<span class="gp">>>> </span><span class="n">Choice</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">filter</span><span class="p">(</span><span class="n">poll__pub_date__year</span><span class="o">=</span><span class="mi">2012</span><span class="p">)</span>
|
||
|
<span class="go">[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]</span>
|
||
|
|
||
|
<span class="go"># Let's delete one of the choices. Use delete() for that.</span>
|
||
|
<span class="gp">>>> </span><span class="n">c</span> <span class="o">=</span> <span class="n">p</span><span class="o">.</span><span class="n">choice_set</span><span class="o">.</span><span class="n">filter</span><span class="p">(</span><span class="n">choice__startswith</span><span class="o">=</span><span class="s">'Just hacking'</span><span class="p">)</span>
|
||
|
<span class="gp">>>> </span><span class="n">c</span><span class="o">.</span><span class="n">delete</span><span class="p">()</span>
|
||
|
</pre></div>
|
||
|
</div>
|
||
|
<p>For more information on model relations, see <a class="reference internal" href="../../ref/models/relations/"><em>Accessing related objects</em></a>. For more on how to use double underscores to perform
|
||
|
field lookups via the API, see <a class="reference internal" href="../../topics/db/queries/#field-lookups-intro"><em>Field lookups</em></a>. For
|
||
|
full details on the database API, see our <a class="reference internal" href="../../topics/db/queries/"><em>Database API reference</em></a>.</p>
|
||
|
<p>When you're comfortable with the API, read <a class="reference internal" href="../tutorial02/"><em>part 2 of this tutorial</em></a> to get Django's automatic admin working.</p>
|
||
|
</div>
|
||
|
</div>
|
||
|
|
||
|
|
||
|
|
||
|
<div id="content-secondary">
|
||
|
<h2 id="comments">Questions/Feedback</h2>
|
||
|
<p>Having trouble? We'd like to help!</p>
|
||
|
<ul>
|
||
|
<li>
|
||
|
Try the <a href="/en/1.4/faq/">FAQ</a>
|
||
|
— it's got answers to many common questions.
|
||
|
</li>
|
||
|
<li>
|
||
|
Search for information in the <a
|
||
|
href="http://groups.google.com/group/django-users/">archives of the
|
||
|
django-users mailing list</a>, or <a
|
||
|
href="http://groups.google.com/group/django-users/">post a question</a>.
|
||
|
</li>
|
||
|
<li>
|
||
|
Ask a question in the <a href="irc://irc.freenode.net/">#django IRC
|
||
|
channel</a>, or search the <a href="http://django-irc-logs.com/">IRC
|
||
|
logs</a> to see if it has been asked before.
|
||
|
</li>
|
||
|
<li>
|
||
|
If you notice errors with this documentation, please <a
|
||
|
href="https://code.djangoproject.com/newticket?component=Documentation">
|
||
|
open a ticket</a> and let us know! Please only use the ticket tracker for
|
||
|
criticisms and improvements on the docs. For tech support, use the
|
||
|
resources above.
|
||
|
</li>
|
||
|
</ul>
|
||
|
</div>
|
||
|
|
||
|
</div>
|
||
|
<!-- END #content-main -->
|
||
|
<div id="content-related" class="sidebar">
|
||
|
|
||
|
|
||
|
<h2>Search</h2>
|
||
|
|
||
|
<form action="/search/" id="sidebar_search" class="search">
|
||
|
<div>
|
||
|
<p>
|
||
|
<input type="search" name="q" id="id_sidebar_search_q" />
|
||
|
</p>
|
||
|
<p>
|
||
|
<label for="id_sidebar_search_release">Version:</label>
|
||
|
<select name="release" id="id_sidebar_search_release">
|
||
|
<option value="2">Django 1.0</option>
|
||
|
<option value="3">Django 1.1</option>
|
||
|
<option value="4">Django 1.2</option>
|
||
|
<option value="5">Django 1.3</option>
|
||
|
<option value="6" selected="selected">Django 1.4</option>
|
||
|
<option value="1">Development trunk</option>
|
||
|
</select>
|
||
|
</p>
|
||
|
<p>
|
||
|
<input type="submit" class="submit" value="Search" />
|
||
|
</p>
|
||
|
</div>
|
||
|
</form>
|
||
|
|
||
|
|
||
|
|
||
|
<h2>Contents</h2>
|
||
|
|
||
|
<ul>
|
||
|
<li><a class="reference internal" href="#">Writing your first Django app, part 1</a><ul>
|
||
|
<li><a class="reference internal" href="#creating-a-project">Creating a project</a><ul>
|
||
|
<li><a class="reference internal" href="#the-development-server">The development server</a></li>
|
||
|
<li><a class="reference internal" href="#database-setup">Database setup</a></li>
|
||
|
</ul>
|
||
|
</li>
|
||
|
<li><a class="reference internal" href="#creating-models">Creating models</a></li>
|
||
|
<li><a class="reference internal" href="#activating-models">Activating models</a></li>
|
||
|
<li><a class="reference internal" href="#playing-with-the-api">Playing with the API</a></li>
|
||
|
</ul>
|
||
|
</li>
|
||
|
</ul>
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
<h2>Browse</h2>
|
||
|
<ul>
|
||
|
|
||
|
|
||
|
<li>Prev: <a href="../install/">Quick install guide</a></li>
|
||
|
|
||
|
|
||
|
<li>Next: <a href="../tutorial02/">Writing your first Django app, part 2</a></li>
|
||
|
|
||
|
<li><a href="/en/1.4/contents/">Table of contents</a></li>
|
||
|
|
||
|
<li><a href="/en/1.4/genindex/">General Index</a></li>
|
||
|
|
||
|
<li><a href="/en/1.4/py-modindex/">Python Module Index</a></li>
|
||
|
|
||
|
|
||
|
</ul>
|
||
|
|
||
|
|
||
|
|
||
|
<h2>You are here:</h2>
|
||
|
<ul>
|
||
|
|
||
|
<li>
|
||
|
<a href="/en/1.4/">Django 1.4 documentation</a>
|
||
|
|
||
|
<ul><li><a href="../">Getting started</a>
|
||
|
|
||
|
<ul><li>Writing your first Django app, part 1</li></ul>
|
||
|
</li></ul>
|
||
|
</li>
|
||
|
|
||
|
</ul>
|
||
|
|
||
|
|
||
|
<h2>Download:</h2>
|
||
|
<p>
|
||
|
|
||
|
Offline (Django 1.4):
|
||
|
<a href="https://www.djangoproject.com/m/docs/django-docs-1.4-en.zip">HTML</a> |
|
||
|
<a href="http://media.readthedocs.org/pdf/django/1.4.X/django.pdf">PDF</a> |
|
||
|
<a href="http://media.readthedocs.org/epub/django/1.4.X/django.epub">ePub</a>
|
||
|
|
||
|
<br>
|
||
|
<span class="quiet">Provided by <a href="http://readthedocs.org/">Read the Docs</a>.
|
||
|
</p>
|
||
|
|
||
|
|
||
|
|
||
|
</div>
|
||
|
<!-- END #content-related -->
|
||
|
|
||
|
</div>
|
||
|
<!-- END #content -->
|
||
|
<div id="footer">
|
||
|
<p>© 2005-2012 <a href="https://www.djangoproject.com/foundation/">Django Software Foundation</a> unless otherwise noted. Django is a registered trademark of the Django Software Foundation.
|
||
|
<a href="http://mediatemple.net/">Linux Web hosting</a> graciously provided by Media Temple.
|
||
|
</p>
|
||
|
</div>
|
||
|
<!-- END #footer -->
|
||
|
</div>
|
||
|
<!-- END #container -->
|
||
|
</body>
|
||
|
</html>
|
||
|
|