通译之第十八章：自定义Django的admin界面

 The Django Book：第18章 自定义Django的admin界面

第6章引见了Django的admin界面，现在是回过头来仔细见见这个的时分了
我们前头讲的几回admin是Django的"刺客级特征"，而且绝大多数Django开发人员很快爱上了它节省时间的全部特点
这么定然的多数Django开发人员开始寻觅自定义也许扩张admin的步骤
第6章最后几一部分讲到了一些定做admin界面某部分的容易步骤，从新翻阅一下子那些文件是个好主意
它叙说了一些定做admin的改动列表，编者表单以及logo之类的容易步骤
第6章也议论了几时和为何你想应用admin界面，这些文件腾跃到了其余章节，我们这边从新引见一下子:
明显，admin对编者数据十分有用(fancy that)，如若你有一些录入数据的任务，则admin不可能被其它货色挫败
我们预想绝大多数此书的读者都将有很半数以上据录入的任务
Django的admin在非技术用户亟需录入数据时不一般闪烁，这是这个特征的最初来源
尽管这样，我们发现除去明摆着的数据录入任务，admin也鄙人面一些情况下有用:
一，稽查数据模型，我们定义了一个新模型后第一件事乃是在admin里调用它并输入一些模拟数据，这对我们发现数据
模型的差错并有一个图形界面来展示这些错处很有相助
二，治理务必的数据，至于chicagocrime.org来说很少有底据录入的任务，由于它的数据都来自于一个自动的数据源
尽管这样，应自动获取数据的模块出毛病时，经过admin可以轻巧的编者数据，这是很有用的
Django的admin不需要可能亟需很少配备就可以处置这些常见的状况，但是，处置这些常见的状况如斯的善意味着
Django的admin在处置其它情状时未见得良好
我们后边将提到Django的admin不适合做的一些事儿，但是现时我们先离题来见见它的一些哲学:

admin的禅宗
作为它的核心，Django的admin设计用于为如次的一个独自的活动:
受信赖的用户编者构造化的内容
是的，很简单，但是这容易的一起隐藏着很多内容，Django的admin的整个哲学都基于此
让我们深入懂得这个句子的子内容:
"受信赖的用户"
admin设计来被你(开发者)信赖的人用，这不单示意那些被受权的用户，它示意Django假想你的内容编写者可以
被信赖来作准确的事儿，这意味编者内容没批准的历程，如若你信赖你的用户，没有人亟需对编者的批准
这也表了然权限系统不支持基于一个对象的限制访问
如若你信赖某人来编者他自个儿的故事，你也将信赖他不会在没权限的情况下编者他人的故事
"编者"
Django的admin的首纲目的是让众人编者内容，这最初看上去很明摆着，但是也存在一些微小而强大的影响
比如，诚然admin对从新视查数据很有用，但是它不是设计来作这个的，注意缺少"can view"权限(参照第12章)
Django假定如其用户被容许在admin里查看内容，他们也被容许编者它
此外一个很值得注意的地方是admin缺少一些比如"工作流"的货色，如若一些任务急需几步来完成，admin不支持
不一般的顺序来作这件事儿，admin关切于编者，而不是盘绕编者的其它活动
关于工作流的匮缺支持也起源于信赖的准则，admin的哲学是，工作流属于个人问题，而不应该用代码兑现
最后，注意admin匮缺统计的支持，它不支持展示总和，平均数之类
再一次说明，admin是用以编者的，它期待你写自定义的视图来完成其它的任务
"构造化的内容"
由于Django其它一部分的关系，admin希望你与构造化的数据工作，这么，admin单单支持编者用Django模型储存的数据
至于其它方式的数据，你则亟需自定义视图
小结
现时应当很明白了，Django的admin不是给任何用户来干任何事情的，而是紧紧的关切1点而且把这一点干的非常好
当我们急需扩充Django的admin时，同一哲学的大多数内容存在与此(注意扩展性无所不在)
由于自定义的Django视图可以做任何事情，并且它们可以可视化的集成到admin(参见下边内容)，内建的定做admin的
机遇在一定程序上被设计所限制

定做admin模板
我们下部将看到，你有几种工具来定做内建的admin模板，但是关于其它任务，比如亟需自定义工作流或许细粒度权限
你将急需阅览本章末了讲到的定做admin视图
现下我们来见见高速定做admin的外观和举动，第6章讲到了一些常见的任务，如改动logo式样和提供自定义admin表单
便这点来说，我们正常急需改动一个非一般项的一些模板
admin的每一个视图，如更动列表，编者表单，剔除确认页面，历史视图等都有一个分配的模板
而这个模板可以经过几种模式来覆盖
第一，你可以大局覆盖模板，admin视图运用基准模板载入机制来找寻模板，之所以如若你在你的模板索引里创设模板
Django将载入并施用这些模板而不是施用Django绑定的默许admin模板
这些大局模板如次:
视图 根本模板名
改动列表 admin/change_list.html
增多/编者表单 admin/change_form.html
剔除确认 admin/delete_confirmation.html
对象历史 admin/object_history.html
尽管这样，大部分情况下你只想更动一个独自的对象也许app的模板而不是大局的模板
这么的话，每个admin视图第一寻觅模型和app专有的模板，这些视图按下边的顺序找寻模板:
admin///.html
admin//.html
admin/.html
比如，在bookstore app的Book模型的增多/编者表单的视图(第6章的事例)按下部的顺序寻觅模板:
admin/bookstore/book/change_form.html
admin/bookstore/change_form.html
admin/change_form.html

定做模型模板
半数以上情况下，你想运用上头第一个模板来创办模型专有的模板
通常情况下透过扩张根本模板并在内中的块定义中增添信息会将这个任务完成的最好
比如我们想在book页面上端平添一些相助内容，或者像底下这么:
[img][/img]
这很简单作到，创设一个叫admin/bookstore/book/change_form.html的模板而且安插下头的代码:

Java代码
1.{% extends "admin/change_form.html" %}
2.
3.{% block form_top %}
4.

Insert meaningful help message here..

5.{% endblock %}
{% extends "admin/change_form.html" %}

{% block form_top %}

Insert meaningful help message here..

{% endblock %}

全部的这些模板都定义了一些块来让你覆盖，关于半数以上程序，代码便是最好的文档，之所以我们勉励你浏览admin模板
(在django/contrib/admin/templates/里头)来失去最新的信息

定做JavaScript
运用这个自定义的模型模板最常见的用处乃是增添自定义的JavaScript到admin页面，可能是兑现一些非一般的小窗口构件
或者是客户端举动
幸运的是，这再简略不过了，每个admin模板定义了一个{% block extrahead %}，你可以把运用它来把其它的内容增添
到head元素里去，比如你想在你的一个admin历史页面引出jQuery:

Java代码
1.{% extends "admin/object_history.html" %}
2.
3.{% block extrahead %}
4.
{% endblock %}

我不知道为啥你在对象历史页面急需jQuery，但是这个事例适用于admin的任何模板
你可以运用这个技术来引出任何许它你或许需要的JavaScript小窗口构件

定做admin视图
到目前为止那些想平添自定义举动到Django的admin中的人人也许开始疑惑了，他们会喊，"你所叙说的都是对于怎的改变
admin的外观，但是我怎的改变admin的工作方式呢?"
好了，别喊了，这边乃是答案
急需了解的第一件事便是它1点也不神奇，admin干的任何事都不非一般，它只是一些像其它视图同样处置数据的视图而已
这些视图在django.contrib.admin.views，当然这里有很多代码，它务必处置全部的选项，域门类和影响模型举动的设立
一样的，当你意识到admin只是一些视图时，平添自定义的admin视图就变得更简略了解
让我们平添一个"publisher report"视图到我们第6章的book app中，我们将构建一个admin视图来展示透过publisher
分组的books列表，这是一个十分典型你也许想构建的自定义admin"report"的例证
第一我们在URLconf里头包装一个视图，我们急需把这行代码安插到admin视图的引出行事前

Java代码
1.(r'^admin/bookstore/report/$', 'bookstore.admin_views.report'),
(r'^admin/bookstore/report/$', 'bookstore.admin_views.report'),

完整的URL配备或许像下头这么:

Java代码
一.from django.conf.urls.defaults import *
2.
三.urlpatterns = patterns('',
4. (r'^admin/bookstore/report/$', 'bookstore.admin_views.report'),
5. (r'^admin/', include('django.contrib.admin.urls')),
6.)
from django.conf.urls.defaults import *

urlpatterns = patterns('',
(r'^admin/bookstore/report/$', 'bookstore.admin_views.report'),
(r'^admin/', include('django.contrib.admin.urls')),
)

为何把自定义视图放在admin引来事先?回顾一下子Django处置URL方式的顺序，由于admin的引出URL婚配差一点全部的货色
如若我们把上头的两行URL配备代码退换顺序，Django将会查寻一个内建的视图来婚配这个URL，这将不能工作
在这种特殊情况下，Django将意欲载入bookstore app的Report模型的改动列表，这是不存在的
现时让我们来写我们的视图，为了容易起见，我们只是载入全部的books在context里并让模板施用{% regroup %}标签处置
分组，用下部的代码创造一个bookstore/admin_views.py资料:

Java代码
一.from bookstore.models import Book
二.from django.template import RequestContext
三.from django.shortcuts import render_to_response
四.from django.contrib.admin.views.decorators import staff_member_required
5.
6.@staff_member_required
七.def report(request):
8. return render_to_response(
9. "admin/bookstore/report.html",
10. {'book_list' : Book.objects.all()},
11. RequestContext(request, {}),
12. )
from bookstore.models import Book
from django.template import RequestContext
from django.shortcuts import render_to_response
from django.contrib.admin.views.decorators import staff_member_required

@staff_member_required
def report(request):
return render_to_response(
"admin/bookstore/report.html",
{'book_list' : Book.objects.all()},
RequestContext(request, {}),
)

由于我们把分组留给模板来干，这个视图十分简略，尽管这样，这里有一些微小的货色值得解释:
一，我们运用django.contrib.admin.views.decorators的staff_member_required装点器，它类似于第12章议论的
login_required装点器，但是这个还稽查给定的用户是不是标记为"staff"成员来决议是不是容许访问admin
这个装点器保护全部内建的admin视图，让你的视图的认证逻辑和admin的其它一部分婚配
二，我们点染在admin/底下的模板，尽管这没严厉的要求，但是护持你全部的admin模板分组在一个admin索引下
被认为是绝佳实践，我们把模板放在我们的app后边叫bookstore的索引下也是绝佳实践
三，我们运用RequestContext作为第3个参数(context_instance)传接给render_to_response
这责任书了对于目前用户的信息可以在模板里失去，参阅第10章失去更多至于RequestContext的信息
最后我们将为这个视图创办一个模板，我们承继内建的admin模板来使这个视图视觉上看上去是admin的部分:

Java代码
1.{% extends "admin/base_site.html" %}
2.
3.{% block title %}List of books by publisher{% endblock %}
4.
5.{% block content %}
6.

7. List of books by publisher:
8. {% regroup book_list|dictsort:"publisher.name" by publisher as books_by_publisher %}
9. {% for publisher in books_by_publisher %}
10. {{ publisher.grouper }}
11.

• 
  12. {% for book in publisher.list|dictsort:"title" %}
  13.
• {{ book }}
  14. {% endfor %}
  15.

16. {% endfor %}
17.

18.{% endblock %}
{% extends "admin/base_site.html" %}

{% block title %}List of books by publisher{% endblock %}

{% block content %}

List of books by publisher:
{% regroup book_list|dictsort:"publisher.name" by publisher as books_by_publisher %}
{% for publisher in books_by_publisher %}
{{ publisher.grouper }}

• 
  {% for book in publisher.list|dictsort:"title" %}
  
• {{ book }}
  {% endfor %}

{% endfor %}

{% endblock %}

经过沿袭admin/base_site.html我们"免费"失去Django的admin的外观，它看上去像这么:
[img][/img]

今日你急需在哪儿运用admin?
你可以运用这个技术来向admin平添任何你想到的货色，记寓所谓的"定做admin视图"实际上只是普普通通的Django视图
你可以应用你在此书其它一部分所学的全部技术来构建随意复杂的admin视图
我们将以一些自定义admin视图的一些好注意完了本章内容

覆盖内建的视图
默许的admin视图不包孕这些，你可以很轻便的在admin的任何地方跳转到你的自定义视图，只需让你的URL覆盖掉内建的那些
比如，我们可以用一个容易的让用户输入ISBN的表单顶替内建的book创办视图，其后我们就可以从http://isbn.nu/来查询
book信息和自动创设对象
这个视图的代码留给读者做习题，最主要的一部分是底下的URL配备:

Java代码
1.(r'^admin/bookstore/book/add/$', 'bookstore.admin_views.add_by_isbn'),
(r'^admin/bookstore/book/add/$', 'bookstore.admin_views.add_by_isbn'),

如其这段代码在你的URL配备中放在admin的URL前边的话，add_by_isbn视图将完全代替基准的admin视图
我们可以遵从相仿的动作来代替剔除确认页面，编者页面也许admin的任何等它一部分
本文来源：
我的异常网
Java Exception