Django 1.4 官方文档精要

需积分: 3 182 浏览量更新于2024-07-26 收藏 6.34MB PDF 举报

"这是一本关于Django框架的书籍，主要针对Django 1.4版本。本书由Django Software Foundation出版，日期为2012年12月3日。书中涵盖了关于Django的全面知识，旨在帮助读者了解并掌握这个强大的Web开发框架。" 在Django 1.4的文档中，主要章节包括以下几个方面： 1.1 获取帮助：如果你在使用Django过程中遇到问题，有多种途径可以获得帮助： - 首先可以查阅FAQ（常见问题解答），它包含了大量常见问题的答案。 - 如果需要特定信息，可以使用通用索引、模块索引或详细的目录来查找。 - 通过邮件列表的归档搜索相关信息，或者直接在django-users邮件列表上提问。 - 在#django IRC频道中询问问题，或者查看之前的聊天记录，看是否已经有人问过相同的问题。 - 如果发现是Django本身的bug，可以在Django的票务追踪系统中报告。 1.2 开始学习：对于初学者，文档提供了以下引导： - 从零开始：概述和安装步骤，帮助你快速搭建Django环境。 - 教程：分为四部分的逐步指导，涵盖Django的基础知识。 1.3 模型层：这一部分详细讲解了Django的模型，包括： - 模型语法：定义数据库表结构的Python类。 - 字段类型：各种数据类型的定义，如字符串、整数等。 - Meta选项：用于控制模型行为的元数据。 - QuerySet：执行数据库查询的方法和参考。 - 模型实例：实例方法以及如何访问关联对象。 - 高级特性：管理器、原生SQL、事务处理、聚合、自定义字段及多数据库支持。 - 其他：支持的数据库、兼容遗留数据库、提供初始数据以及优化数据库访问。 1.4 模板层：主要面向设计师，介绍如何使用Django的模板语言进行页面设计和渲染，包括模板语法、过滤器、标签和继承等概念。 1.5 视图层：这一部分涉及视图函数或类，它们处理HTTP请求，并返回HTTP响应。涵盖了URL配置、视图的编写和装饰器的使用等内容。 1.6 URL调度： Django的URLconf系统允许你将URL映射到视图，提供灵活的URL设计。 1.7 表单和验证： Django的表单系统使得创建用户输入的处理和验证变得简单。 1.8 中间件：中间件是插入到Django请求/响应处理流程中的组件，可以实现全局的功能，如日志记录、会话管理等。 1.9 扩展和高级主题：包括如何创建自定义管理命令、缓存机制、国际化和本地化、测试框架、静态文件处理、部署策略等。通过这本书，读者不仅可以学习到Django的基本用法，还能深入理解其核心机制，从而更好地利用Django开发高效、可维护的Web应用。

Django Documentation, Release 1.4.2

This will create a mysite directory in your current directory.

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

django-admin.py should be on your system path if you installed Django via python setup.py. If it’s not

on your path, you can ﬁnd it in site-packages/django/bin, where site-packages is a directory

within your Python installation. Consider symlinking to django-admin.py from some place on your path, such as

/usr/local/bin.

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

• 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.4.2

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 as part of Python 2.5 and later, 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.4.2

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: polls and choices. 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.4.2

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 = 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

剩余1181页未读，继续阅读

llix19880203

粉丝: 0
资源: 1

Django 1.4 官方文档精要

中文版django book

The Django Book.pdf

The Django Book英文版

Django Book

Django book

Djangobook

Django书The Django Book

DjangoBook2.0

django book 2.0

Django book中文

最新资源