第6章：Django站点管理
对于一些特定类型的Web站点，管理界面是基础架构中必不可少的一部分。这是一个基于Web的界面，限制为受信任的站点管理员，使他们能够添加、编辑和删除站点内容。你用来向你的博客发布内容的界面，网站管理员用来审核读者发布的评论的后台，你为客户建立的让他们用来更新网站上的新闻稿的工具——它们都是管理界面的例子。
但是管理界面也有问题：构建它们的过程太乏味了。当你开发面向公众的功能的时候，Web开发是有趣的，但是构建管理界面并不总是如此。你得验证用户，显示和处理表单，验证输入，等等。这是单调乏味的，而且是重复性的劳动。
那么Django解决那些单调、重复的工作的方法是什么呢？它都为你做好了——只要使用几行必不可少的代码。使用Djagno，构建一个管理界面是一个已解决的问题。
本章是关于Django的自动管理界面的。这个特性通过从你的模型读取元数据来提供一个强有力的且生产就绪的界面使得网站管理员可以立即开始使用。这里，我们讨论怎样激活、使用、并定制这个特性。
激活管理界面
我们认为管理界面是Django中最酷的部分——并且大多数的Django使用者也同意—— 但是因为并非每一个人都会在实践中需要它，它是一个可选的部分。这意味着为激活这个特性你需要经过三个步骤：
- 在你的模型中添加管理元数据。
并非所有的模型都可以（或者说应该）被管理用户编辑，所以你应该“标记”应该有一个管理界面的模型。你通过在你的模型中添加一个内部类Admin(与Meta类类似，如果你有一个的话)来做到这一点。所以，为给前一章中我们的Book模型添加一个管理界面，我们使用以下代码：
class Book(models.Model):
title = models.CharField(maxlength=100)
authors = models.ManyToManyField(Author)
publisher = models.ForeignKey(Publisher)
publication_date = models.DateField()
num_pages = models.IntegerField(blank=True, null=True)
def __str__(self):
return self.title
class Admin:
pass
Admin类声明标志着这个模型有一个管理界面。有一些选项你可以放在Admin声明之下，但是现在我们一切都使用默认值来继续，所以我们在哪里放了一个pass来告诉Python Admin类是一个空类。
如果你正是用你自己的代码来跟进这个例子，或许现在在Publisher和Author类中添加Admin声明是一个好主意。
2. 安装管理应用。通过把"django.contrib.admin"添加到你的INSTALLED_APPS设置文件来做到这一点。
3. 如果你正跟进本例子，确保"django.contrib.sessions", "django.contrib.auth", 还有 "django.contrib.contenttypes"没有被注释掉，因为管理应用依赖于它们。也不要注释掉MIDDLEWARE_CLASSES元组中的任意一行并且删除TEMPLATE_CONTEXT_PROCESSOR设置来允许它采用默认值。
4. 运行python manage.py syncdb。这一步骤将安装管理应用使用的额外的数据库表。
注意
当有"django.contrib.auth"在INSTALLED_APPS中，你第一次运行syncdb的时候，你会被询问来创建一个超级用户。如果那个时候你没有这样做，你需要使用django/contrib/auth/bin/create_superuser.py 来创建一个管理用户。否则，你不能登录进入管理界面。
5. 在你的urls.py中添加URL模式。如果你仍然在使用startproject创建的那一个，管理界面的URL模式应该已经存在了，只是被注释掉了。不管怎样，你的URL模式应该看起来是下面的样子：
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^admin/', include('django.contrib.admin.urls')),
)
就是它了。现在运行python manage.py runserver来启动开发服务器。你可以看到以下输出：
Validating models...
0 errors found.
Django version 0.96, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
现在，你可以访问Django给出的URL(在前面的例子中是http://127.0.0.1:8000/admin/)，登录进入，使用它的功能了。
使用管理界面
管理界面是被设计为被非技术用户使用的，因此它应该是很好地自解释的。虽然如此，有关管理界面这个特性还是有几个方面需要注意。
你要看到的第一件事情是一个登录界面，如图6-1所示。
图6-1 Django的登录界面
你可以使用你添加超级用户的时候所使用的用户名和密码。一旦你登录进入，你可以看到你可以管理用户，组，还有权限（稍后讨论更多）。
每一个有Admin声明的对象都在主页中列出了，如图6-2所示。
图6-2 Django管理主界面
添加和更改对象的链接连接到两个我们称之为change lists和edit forms的页面。change lists本质上是系统中对象的索引页面，如图6-3所示。
图6-3 一个典型的change list视图
有一些选项来控制哪些域可以被显示在列表里和现实额外的特性如数据录入时间，搜索域，还有过滤器界面。稍后我们会更详细地讨论这些特性。
编辑表单用来修改已存在的对象和创建新的对象（见图6-4）。在你的模型中定义的每个域都会显示在这里，并且你会注意到不同类型的数据域有不同的小部件（如，date/time域有日历控件，外键使用一个选择框，等等。）。
图6-4 一个典型的编辑窗体
你会注意到管理界面也为你处理输入验证。尝试将一个必选数据域留空或者在时间域中放入一个不正确的时间，当你尝试保存的时候你会看到以下错误，如图6-5所示。
图6-5 编辑窗体正显示错误
当你编辑一个已存在的对象时，你会注意到在窗口上的右上角有一个历史按钮。通过管理界面作出的每个更改都被记录了，你可以通过历史按钮（见图6-6）来检查这些记录。
图6-6 Django对象的历史页面
当你删除一个已存在的对象时，管理界面会询问你来确认删除操作来避免无意的错误。删除也是关联的；删除确认页面显示了所有同时会被删除的所有相关对象（见图6-7）。
图6-7 Django的删除确认页面
用户，组，和权限
一旦你作为超级用户登录进入，你就具有权限来创建，编辑，删除任何对象。但是，管理界面有一个用户权限系统是你可以给予其他用户使得它们具有访问需要的部分的权限。
通过管理界面来编辑用户和权限与任何其他对象相同。管理主页面上到User和Group模型的连接关联到所有你自己定义的对象。
用户对象有你或许会希望的标准的用户名、密码、电子邮件、真实姓名域，还有一组定义了用户被允许在管理界面中做什么的域。首先，有一组三个标志：
- "is active"标志控制此用户是否是激活的。如果此标志是关闭的，此用户无权访问任何需要登录的URL。
- "is staff"标志控制用户是否被允许登录进入管理界面（如，此用户在你的组织中是否被视为一个"职员"）。因为这同一个用户系统可以被用来控制到公共（如，没有管理的）站点（见第12章）的访问，这个标志区分了公共用户和管理员。
- "is superuser"标志给予用户完全的、无限制的权限使得其可以在管理界面中访问每一项数据；通常的限制被抛弃了。
“普通”的管理员——就是说，激活的，非超级用户的职员——根据一组被分配的许可来授予权限。通过管理界面可以被编辑的对象都具有三种许可：创建许可、编辑许可、删除许可。分配给用户的访问权限是被这些许可来来描述的。
注意
编辑用户和许可的权限也是被这个许可系统控制的。如果你给某人编辑用户的权限，它可以有能力编辑自己的权限，或许并不是你所想要的。
你也可以为用户指定组。组仅仅是一组实施到所有本组成员的许可。组对于对大量用户授予同样的权限是很有用的。
定制管理界面
你可以通过多种途径来定制管理界面的外观和行为。在本小节我们涵盖了这些途径中的几种，因为它与我们的Book模型相关；第17章涵盖了定制管理界面的细节。
现在的情况是，我们的书籍的更改列表仅显示了我们在模型中添加的__str__所定义的字符形式。这在书籍数量很少的时候工作得很好，但是如果我们有数百本或者数千本书，那么定位一本书就犹如大海捞针。但是，我们可以很容易地为这个界面添加一些显示、搜索、和过滤功能。按以下方式修改Admin声明：
class Book(models.Model):
title = models.CharField(maxlength=100)
authors = models.ManyToManyField(Author)
publisher = models.ForeignKey(Publisher)
publication_date = models.DateField()
class Admin:
list_display = ('title', 'publisher', 'publication_date')
list_filter = ('publisher', 'publication_date')
ordering = ('-publication_date',)
search_fields = ('title',)
这四行代码显著地改变了我们的列表界面，如图6-8所示。
图6-8 修改过后的更改列表
那些代码的每一行都要求管理界面构建这个界面的一个不同的块：
- list_display选项控制哪些列在更改列表中显示。默认情况下，更改列表只显示包含对象的字符描述的单一的一行。这里，我们修改为显示标题，出版社，和出版日期。
- list_filter选项在列表的右侧创建过滤器侧边栏。我们允许按照日期（允许你只查看过去一周，一个月出版的书籍，等等）和按照出版社过滤。
你可以要求管理界面按照任何域过滤，但是外键、日期、布尔值，还有具有“选择”属性的域工作的最好。显然过滤器需要至少有两个值来从中选择。
- ordering选项控制着对象在管理界面中被显示的顺序。它仅仅是一个用来作为依据排序结果的域的列表；在域的前面加一个减号前缀指示反转给定的顺序。在这个例子中，我们按照出版日期排序，最近出版的在第一位。
- 最后，search_fields选项创建了一个允许进行文本搜索的域。它允许按照标题域搜索（所以你可以敲"Django"来显示所有标题中有"Django"的书）。
使用这些选项（和其他在将在第12章描述的）你可以仅仅使用几行代码就构建一个非常强大的，面向生产环境的界面进行数据编辑。
定制管理界面的外观和风格
很明显，在每个管理页面的顶部都放置一个"Django管理"短语是可笑的。那仅仅是占位符。
不过，那是很容易改变的，使用Django的模板系统。Django的管理站点是用 Django自己增强的，它的界面使用Django自己的模板系统。（Django的模板系统在第4章介绍了。）
我们在第4章已经解释过， TEMPLATE_DIRS设置指定了载入Django模板时需要去检查的一个目录列表。为定制Django的管理模板，只要简单地把相关的管理模板从Django的发布拷贝到你自己的TEMPLATE_DIRS指定的目录。
管理站点通过查找模板admin/base_site.html来确定"Django管理"头。默认情况下，这个模板存在于Django的管理模板目录django/contrib/admin/templates，你可以从你的Python site-packages目录查找它，或者从Django被安装的目录。为定制这个base_site.html模板，拷贝这个模板到你在TEMPLATE_DIRS指定的目录中的一个admin子目录中。例如，如果你的TEMPLATE_DIRS包含"/home/mytemplates"，那么拷贝django/contrib/admin/templates/admin/base_site.html 到 /home/mytemplates/admin/base_site.html。不要忘记那个admin子目录。
然后，只要编辑新的admin/base_site.html文件来使用你自己看着合适的站点名称来替换一般的Django文本。
注意任何Django默认的管理模板都可以被覆盖。为覆盖一个模板，只需做你对base_site.html做的相同的事情：从默认的目录拷贝它到你指定的目录并对拷贝作出修改。
你可能会想，如果TEMPLATE_DIRS默认是空的，Django是怎样找到默认的管理模板的。答案是，默认情况下，Django自动地在每个应用程序包中的templates/子目录中查找模板。查看第10章"编写自定义的模板加载器"获取有关这是如何工作的更多信息。
定制管理主页面
基于同样的原因，你或许想要定制Django的管理主页面的外观和风格。默认情况下，它显示所有可用的应用，根据你的INSTALLED_APPS设置，按照应用名排序。然而，你或许想要改变这个顺序来使你找到想要的应用更容易。毕竟，主页面或许是管理界面最重要的页面，所以它应该是易于使用的。
要定制的模板是admin/index.html。（记住要把admin/index.html像前面的例子一样拷贝到你指定的模板目录。）编辑这个文件，你会看到它包含一个模板标签，名为{% get_admin_app_list as app_list %}。这个标签检索每一个已安装的应用。代替使用这个标签，你可以以任何你认为最好的方式来硬编码到指定对象管理页面的链接。如果硬编码链接不适合你，查看第10章来了解实现你自己的模板标签的详细信息。
Django在这个部分提供了另一条捷径。运行命令python manage.py adminindex
获取包含在管理主页面中的模板代码。这是一个有用的起点。
通常的定制Django管理站点的外观和风格的全部详细信息，查看第17章。
什么时候和为什么要使用管理界面
我们认为Django的管理界面是引人入胜的。事实上，我们称它为Django的"杀手级特性"之一。但是，我们经常被要求提供使用管理界面的"用例"——我们应该什么时候使用它，为什么？在过去的数年里，我们发现了一系列我们认为有帮助的使用管理界面的模式。
显然，管理界面对于编辑数据是非常有用的（想象一下）。如果你有任何类型的数据输入任务，管理界面是不可战胜的。我们猜这本书的绝大多数读者都会有大量数据输入任务。
Django的管理界面在非技术用户需要能够输入数据时特别耀眼；毕竟这是这个特性背后的目标。在Django被第一次开发出来的报纸，一个典型的在线特性的开发——一个有关市政供应的水的质量的报告，有以下内容：
- 负责这个报道的报告人会见了其中一个开发者并介绍了现有可用的数据。
- 开发者根据这些数据设计了模型并开放这个管理界面给报告人。
- 当报告人把数据输入Django的时候，程序员能够将精力集中在开发公共可访问的界面（有趣的部分！）。
换句话说，Django管理界面的存在使得内容生产者和程序员的并行工作变得便利了。
然而，除了这明显的数据输入任务，我们还发现管理界面在其他几种情况也是很有用的：
- 检查数据模型：当我们定义了一个新的模型后第一件事情就是在管理界面中调用它并输入一些测试数据。这通常发生在当我们发现了某些数据模型错误时；模型有一个图形界面会很快显露出问题。
- 管理获取的数据：http://chicagocrime.org这类的站点很少有数据是被实际输入的，因为绝大部分的数据来自一个自动化的源。但是，当发现自动获取的数据有问题时，能够容易地进入和编辑这些数据是很有用的。
接下来是什么？
到目前为止我们创建了一些模型并配置了一个顶级的界面来编辑数据。在下一章，我们会转到Web开发中真实的“最基本的部分”：表单创建和处理。
===================================================================
基于2008年5月11日所见之www.djangobook.com版本翻译。
===================================================================