Django 1.6 文档：20121114版，初学者与进阶指南

需积分: 10 96 浏览量更新于2024-07-27 收藏 6.56MB PDF 举报

"Django官方文档，20121114发布，涵盖了Django 1.4阿尔法，1.5贝塔，1.6开发版本，包含1000+页的内容，由Django Software Foundation于2012年11月14日发布。" 这篇文档是Django框架的官方指南，旨在帮助开发者全面了解和掌握Django的使用。Django是一个强大的Python Web框架，它提供了许多开箱即用的功能，如ORM（对象关系映射）、模板系统、表单处理以及内置的管理界面等。在文档中，"Getting help"章节提供了多种寻求帮助的途径，包括查看常见问题（FAQ）、搜索详细索引、参与邮件列表讨论、在IRC频道提问以及通过Django的票务追踪系统报告bug。 "First steps"章节是初学者入门的向导，无论你是对Django还是编程新手，都可以从这里开始。它包括了从零开始的概述、安装步骤，以及一系列的教程，如分步骤的教程和如何编写可复用的应用程序。 "The model layer"章节是关于Django模型层的深入讲解，模型层是Django的核心之一，用于定义和操作Web应用的数据。这部分内容涵盖了模型的语法、字段类型、元选项，以及如何执行查询和使用QuerySet方法。模型实例部分则介绍了如何使用实例方法来操作数据。除此之外，文档还可能涵盖其他关键主题，如视图（views）——负责处理请求和生成响应的组件，URL调度器（URL routing）——用于将URL映射到特定视图，模板系统——用于生成HTML和其他静态内容，以及表单（forms）——处理用户输入和验证数据的工具。对于Django的开发者来说，这份文档不仅是学习Django基础知识的宝典，也是解决实际问题、深入理解框架内部机制的重要参考。随着版本的迭代，Django的功能不断完善，这份2012年的文档虽然可能不包含最新的特性，但对于理解早期版本的Django以及Web开发的基本概念仍然具有极高的价值。

Django Documentation, Release 1.6.dev20121114104630

From the command line, cd into a directory where you’d like to store your code, then run the following command:

django-admin.py startproject mysite

This will create a mysite directory in your current directory. If it didn’t work, see Troubleshooting.

Script name may differ in distribution packages

If you installed Django using a Linux distribution’s package manager (e.g. apt-get or yum) django-admin.py

may have been renamed to django-admin. You may continue through this documentation by omitting .py from

each command.

Mac OS X permissions

If you’re using Mac OS X, you may see the message “permission denied” when you try to run django-admin.py

startproject. This is because, on Unix-based systems like OS X, a ﬁle must be marked as “executable” before it

can be run as a program. To do this, open Terminal.app and navigate (using the cd command) to the directory where

django-admin.py is installed, then run the command sudo chmod +x django-admin.py.

Note: You’ll need to avoid naming projects after built-in Python or Django components. In particular, this means

you should avoid using names like django (which will conﬂict with Django itself) or test (which conﬂicts with a

built-in Python package).

Where should this code live?

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 /var/www). 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.

Put your code in some directory outside of the document root, such as /home/mycode.

Let’s look at what startproject created:

mysite/

manage.py

mysite/

__init__.py

settings.py

urls.py

wsgi.py

Doesn’t match what you see?

The default project layout recently changed. If you’re seeing a “ﬂat” layout (with no inner mysite/ 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.

These ﬁles are:

• The outer mysite/ directory is just a container for your project. Its name doesn’t matter to Django; you can

rename it to anything you like.

12 Chapter 2. Getting started

Django Documentation, Release 1.6.dev20121114104630

• manage.py: A command-line utility that lets you interact with this Django project in various ways. You can

read all the details about manage.py in django-admin.py and manage.py.

• The inner mysite/ 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. import mysite.settings).

• mysite/__init__.py: An empty ﬁle that tells Python that this directory should be considered a Python

package. (Read more about packages in the ofﬁcial Python docs if you’re a Python beginner.)

• mysite/settings.py: Settings/conﬁguration for this Django project. Django settings will tell you all

about how settings work.

• mysite/urls.py: The URL declarations for this Django project; a “table of contents” of your Django-

powered site. You can read more about URLs in URL dispatcher.

• mysite/wsgi.py: An entry-point for WSGI-compatible webservers to serve your project. See How to

deploy with WSGI for more details.

The development server

Let’s verify this worked. Change into the outer mysite directory, if you haven’t already, and run the command

python manage.py runserver. You’ll see the following output on the command line:

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.

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 conﬁguring a production server – such as

Apache – until you’re ready for production.

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.)

Now that the server’s running, visit http://127.0.0.1:8000/ with your Web browser. You’ll see a “Welcome to Django”

page, in pleasant, light-blue pastel. It worked!

Changing the port

By default, the runserver command starts the development server on the internal IP at port 8000.

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:

python manage.py runserver 8080

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:

python manage.py runserver 0.0.0.0:8000

Full docs for the development server can be found in the runserver reference.

2.3. Writing your ﬁrst Django app, part 1 13

Django Documentation, Release 1.6.dev20121114104630

Database setup

Now, edit mysite/settings.py. It’s a normal Python module with module-level variables representing Django

settings. Change the following keys in the DATABASES ’default’ item to match your database connection settings.

• ENGINE – Either ’django.db.backends.postgresql_psycopg2’,

’django.db.backends.mysql’, ’django.db.backends.sqlite3’ or

’django.db.backends.oracle’. Other backends are also available.

• NAME – The name of your database. If you’re using SQLite, the database will be a ﬁle on your computer; in

that case, NAME should be the full absolute path, including ﬁlename, of that ﬁle. If the ﬁle doesn’t exist, it will

automatically be created when you synchronize the database for the ﬁrst time (see below).

When specifying the path, always use forward slashes, even on Windows (e.g.

C:/homes/user/mysite/sqlite3.db).

• USER – Your database username (not used for SQLite).

• PASSWORD – Your database password (not used for SQLite).

• HOST – 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).

If you’re new to databases, we recommend simply using SQLite by setting ENGINE to

’django.db.backends.sqlite3’ and NAME 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.

Note: If you’re using PostgreSQL or MySQL, make sure you’ve created a database by this point. Do that with

“CREATE DATABASE database_name;” within your database’s interactive prompt.

If you’re using SQLite, you don’t need to create anything beforehand - the database ﬁle will be created automatically

when it is needed.

While you’re editing settings.py, set TIME_ZONE to your time zone. The default value is the Central time zone

in the U.S. (Chicago).

Also, note the INSTALLED_APPS setting toward the bottom of the ﬁle. That holds the names of all Django appli-

cations 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.

By default, INSTALLED_APPS contains the following apps, all of which come with Django:

• django.contrib.auth – An authentication system.

• django.contrib.contenttypes – A framework for content types.

• django.contrib.sessions – A session framework.

• django.contrib.sites – A framework for managing multiple sites with one Django installation.

• django.contrib.messages – A messaging framework.

• django.contrib.staticfiles – A framework for managing static ﬁles.

These applications are included by default as a convenience for the common case.

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:

python manage.py syncdb

14 Chapter 2. Getting started

Django Documentation, Release 1.6.dev20121114104630

The syncdb command looks at the INSTALLED_APPS setting and creates any necessary database tables according

to the database settings in your settings.py ﬁle. 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.

If you’re interested, run the command-line client for your database and type \dt (PostgreSQL), SHOW TABLES;

(MySQL), or .schema (SQLite) to display the tables Django created.

For the minimalists

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 INSTALLED_APPS

before running syncdb. The syncdb command will only create tables for apps in INSTALLED_APPS.

2.3.2 Creating models

Now that your environment – a “project” – is set up, you’re set to start doing work.

Each application you write in Django consists of a Python package, somewhere on your Python path, 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.

Projects vs. apps

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 conﬁguration and apps for a

particular Web site. A project can contain multiple apps. An app can be in multiple projects.

Your apps can live anywhere on your Python path. In this tutorial, we’ll create our poll app right next to your

manage.py ﬁle so that it can be imported as its own top-level module, rather than a submodule of mysite.

To create your app, make sure you’re in the same directory as manage.py and type this command:

python manage.py startapp polls

That’ll create a directory polls, which is laid out like this:

polls/

__init__.py

models.py

tests.py

views.py

This directory structure will house the poll application.

The ﬁrst step in writing a database Web app in Django is to deﬁne your models – essentially, your database layout,

with additional metadata.

Philosophy

A model is the single, deﬁnitive source of data about your data. It contains the essential ﬁelds and behaviors of the data

you’re storing. Django follows the DRY Principle. The goal is to deﬁne your data model in one place and automatically

derive things from it.

In our simple poll app, we’ll create two models: Poll and Choice. A Poll has a question and a publication date.

A Choice has two ﬁelds: the text of the choice and a vote tally. Each Choice is associated with a Poll.

2.3. Writing your ﬁrst Django app, part 1 15

Django Documentation, Release 1.6.dev20121114104630

These concepts are represented by simple Python classes. Edit the polls/models.py ﬁle so it looks like this:

from django.db import models

class Poll(models.Model):

question = models.CharField(max_length=200)

pub_date = models.DateTimeField(’date published’)

class Choice(models.Model):

poll = models.ForeignKey(Poll)

choice_text = models.CharField(max_length=200)

votes = models.IntegerField()

The code is straightforward. Each model is represented by a class that subclasses django.db.models.Model.

Each model has a number of class variables, each of which represents a database ﬁeld in the model.

Each ﬁeld is represented by an instance of a Field class – e.g., CharField for character ﬁelds and

DateTimeField for datetimes. This tells Django what type of data each ﬁeld holds.

The name of each Field instance (e.g. question or pub_date ) is the ﬁeld’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.

You can use an optional ﬁrst positional argument to a Field to designate a human-readable name. That’s used in a

couple of introspective parts of Django, and it doubles as documentation. If this ﬁeld isn’t provided, Django will use

the machine-readable name. In this example, we’ve only deﬁned a human-readable name for Poll.pub_date. For

all other ﬁelds in this model, the ﬁeld’s machine-readable name will sufﬁce as its human-readable name.

Some Field classes have required elements. CharField, for example, requires that you give it a max_length.

That’s used not only in the database schema, but in validation, as we’ll soon see.

Finally, note a relationship is deﬁned, using ForeignKey. 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.

2.3.3 Activating models

That small bit of model code gives Django a lot of information. With it, Django is able to:

• Create a database schema (CREATE TABLE statements) for this app.

• Create a Python database-access API for accessing Poll and Choice objects.

But ﬁrst we need to tell our project that the polls app is installed.

Philosophy

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.

Edit the settings.py ﬁle again, and change the INSTALLED_APPS setting to include the string ’polls’. So

it’ll look like this:

INSTALLED_APPS = (

’django.contrib.auth’,

’django.contrib.contenttypes’,

’django.contrib.sessions’,

’django.contrib.sites’,

’django.contrib.messages’,

’django.contrib.staticfiles’,

# Uncomment the next line to enable the admin:

16 Chapter 2. Getting started

剩余1213页未读，继续阅读

进击的愤怒

粉丝: 20
资源: 23

Django 1.6 文档：20121114版，初学者与进阶指南

Django1.6 官方文档

Django官方文档.pdf

Django2.0.1官方文档

django 2.0 官方文档

django 1.7文档

Django 1.5 官方文档精要

Django 1.4 官方文档概览

Django 1.6 官方文档详解

Django 2.1 官方文档速览

Django 1.5.3 官方文档中文版

最新资源