Django 管理インターフェース

これまで何度も述べてきたように、Django の管理インターフェイスはフレームワークのキラー機能の 1 つであり、ほとんどの Django 開発者はそれが時間を節約し、使いやすいことを知っています。この管理インターフェイスは人気があるため、
Django 開発者がそれをカスタマイズして拡張したいと考えるのが一般的です。

Django 管理サイトの最後のいくつかのセクションでは、管理インターフェイスの一部をカスタマイズする簡単な方法をいくつか紹介します。この章に入る前に、管理インターフェースの変更リストと編集フォームをカスタマイズする方法、およびサイトと一致する管理インターフェースのスタイルを設定する方法について説明している情報を確認してください。

Django 管理サイトでは、管理インターフェイスをいつどのように使用するかについても説明しています。この資料はこの章の残りの部分の良い出発点となるため、ここで詳しく説明します:

明らかに、データ編集 仕事目的では、この管理インターフェイスは非常に便利です (想像してください)。ある種のデータ入力作業を完了するために使用する場合、この管理インターフェイスは本当に比類のないものです。この本の読者のほとんどは、自由に使えるデータ入力タスクを大量に抱えていると思われます。

Django 管理インターフェイスは、データ入力を使用するための技術的な背景がないユーザーに特別な注意を払っています。これがこの機能の開発目的でもあります。 Django が最初に開発された新聞では、典型的なオンライン市営水道水質報告システムが開発されました。要件は次のとおりです:

§ この主題を担当する記者は、既存のデータを提出するために開発者と会いました。

§ 開発者はそのデータに基づいてモデルを設計し、レポーター用の管理インターフェイスを開発します。

§ レポーターが Django にデータを入力している間、プログラマーはパブリック アクセス インターフェイス (楽しい部分!) の開発に集中できます。

言い換えれば、Django 管理インターフェイスの主な目的は、コンテンツ編集者とプログラマーが同時に作業できるようにすることです。

もちろん、明らかなデータ入力タスク以外にも、管理インターフェイスは他の多くの状況でも役立つことがわかりました。

§ データ モデルを確認する: 新しいデータ モデルを定義した後、最初に行う必要があるのは、管理インターフェイスでそれを実行し、いくつかの仮説データを入力することです。通常、データ モデリングのエラーが発見された後、グラフィカル モデル インターフェイスを使用して核心を迅速に見つけることができます。

§ 取得したデータの管理: ほとんどのデータは自動的に生成されたソースから取得されているため、http://chicagocrime.org のようなサイトに関連付けられている実際のデータ入力はほとんどありません。しかし、取得したデータが間違っていてトラブルが発生した場合、間違ったデータを簡単に見つけて修正できれば問題解決につながります。

Django 管理インターフェイスは、カスタマイズをまったく行わないか、わずかにカスタマイズするだけで、ほとんどの一般的な状況に対処できます。ただし、Django の管理インターフェイスがこの一般的な状況を適切に処理できるようにするための設計上の妥協は、他の一部の編集モデルも同様に処理できないことを意味します。

後で、Django 管理インターフェイスが処理するように設計されていない状況について説明しますが、最初に少し脇に置いて、その設計哲学について説明しましょう。

管理方法

本質的に、Django 管理インターフェイスは 1 つの動作のみを目的として設計されています:

信頼されたユーザーが構造化コンテンツを編集する。

はい、とてもシンプルですが、そのシンプルさはたくさんの仮定に基づいています。 Django の管理インターフェイスの設計哲学全体は、これらの前提に直接基づいているため、後続のセクションで登場する用語の意味を詳しく調べてみましょう。

信頼できるユーザー

管理インターフェイスは、開発者であるあなたが信頼できるユーザーが使用できるように設計されています。これは単に認証された人を意味するのではなく、コンテンツ編集者は正しいことだけを行うと信頼できると Django が想定していることを意味します。

これは、ユーザーを信頼する場合、ユーザーは許可を求めずにコンテンツを編集でき、編集アクションに対して誰も許可を与える必要がないことを意味します。もう 1 つの意味は、この認証システムは強力ですが、この記事の執筆時点ではオブジェクト レベルでのアクセス制限をサポートしていないということです。誰かが自分のニュース記事を編集することを許可する場合は、そのユーザーが許可なく他の人の記事を編集しないことを確信する必要があります。

編集

Django 管理インターフェイスの主な目的は、ユーザーがデータを編集できるようにすることです。これは一見すると明らかですが、よく見てみると少しとらえどころがなく、珍しいものになります。

たとえば、管理インターフェースは (先ほど説明したように) データを検査するのに非常に便利ですが、これは本来の設計意図ではありません。 Django のセッション、ユーザー、登録で説明したように、表示権限がありません。 Django は、管理インターフェイスのユーザーが何かを表示できる場合、そのユーザーはそれを編集することもできると想定しています。

もう 1 つ注意すべき重要な点があります。それは、リモート通話ワークフローが欠如していることです。特定のタスクが一連のステップで構成されている場合、それらのステップが特定の順序で完了することを保証するメカニズムはありません。 Django 管理インターフェイスは編集に重点を置いており、変更に関連するアクティビティについては考慮しません。このワークフローの回避は、信頼の原則からも生じています。つまり、管理インターフェイスは、ワークフローは人間が行うものであり、コードで実装する必要はないという考えに基づいて設計されています。

最後に、管理インターフェイスに集約がないことに注意してください。つまり、合計や平均などの表示はサポートされていません。繰り返しますが、管理インターフェイスは編集専用です。他のすべての操作はビューを定義することで行うことが期待されます。

構造化コンテンツ

Django の他の部分の協力により、管理インターフェイスでは構造化データを使用することが期待されます。したがって、Django モデルに保存されているデータの編集のみがサポートされており、ファイル システム内のデータなどの他のデータについては、編集するビューをカスタマイズする必要があります。

ここでやめましょう

今確かなことは、Django の管理インターフェイスはすべての人にとって普遍的なツールであることを意図したものではなく、1 つのことに集中して完璧に仕上げることを選択したということです。

Django の管理インターフェイスを拡張するときは、同じ設計コンセプトに従う必要があります。 (スケーラビリティは私たちの目標ではないことに注意してください)。カスタム Django ビューを使用してすべてを実行でき、管理インターフェイス (次の章で説明) に視覚的に簡単に統合できるため、管理インターフェイスをカスタマイズする組み込みの機会は意図的に少し制限されています。

管理インターフェイスは複雑ですが、それは常に単なるアプリケーションであることを覚えておくことが重要です。十分な時間があれば、Django 開発者は管理インターフェイスで実行できることをすべて実行できます。したがって、将来的には、この新しいインターフェイスには異なる前提条件があり、まったく異なる方法で動作する管理インターフェイスが登場することを期待する必要があります。

最後に、この記事の執筆時点では、Django 開発者は、より柔軟なカスタマイズを提供する新しい管理インターフェイスの開発に取り組んでいます。あなたがこれを読んでいる頃には、これらの新機能が実際の Django リリースに組み込まれているかもしれません。
Django コミュニティの誰かに問い合わせて、newforms-admin バックボーン コードが統合されているかどうかを確認してください。

カスタマイズされた管理者テンプレート

Django には、組み込みの管理者テンプレートをカスタマイズするためのツールがいくつか用意されており、簡単に紹介します。他のタスク (ワークフロー制御やより詳細な権限管理など) については、この章の「カスタム管理ビューの作成」セクションを読む必要があります。

それでは、管理者管理インターフェイスの外観を簡単にカスタマイズする方法を見てみましょう。 Django 管理サイトでは、ロゴの変更 (青を嫌うトゲトゲした髪の上司のため) やカスタム フォームの提供など、最も一般的なタスクのいくつかをカバーしています。

さらなる目標には、テンプレート内のいくつかの特別な項目の変更が含まれることがよくあります。変更リスト、編集フォーム、削除確認ページ、履歴ビューなどの各管理ビューには、さまざまな方法でオーバーライドできる関連付けられたテンプレートがあります。

まず、テンプレートをグローバルにオーバーライドできます。管理ビューは、標準のテンプレート読み込みメカニズムを使用してテンプレートを検索します。したがって、テンプレート ディレクトリに新しいテンプレートを作成すると、Django はそれを自動的に読み込みます。グローバル テンプレートを表 17-1 に示します。局 表 17-1. グローバル管理テンプレート

基本テンプレート名を表示

変更リスト admin/Change_list.html

フォームの追加/編集 Admin/Change_Form.html

削除 CONFIRMIN/Delete_confirmation.html

オブジェクト履歴/ object_history.html

ほとんどの場合、グローバル設定を変更するのではなく、個々のオブジェクトまたはアプリケーションを変更したいだけかもしれません。したがって、すべての管理ビューは常に最初にモデルまたはアプリケーションに関連するテンプレートを探します。これらのビューがテンプレートを検索する順序は次のとおりです:

§ admin/<app_label>/<object_name>/<template>.html
§ admin/<app_label>/<template>.html
§ admin/<template>.html

たとえば、書籍アプリケーションでは、Book モジュールの追加/編集フォームのビューは次の順序でテンプレートを検索します:

§ admin/books/book/change_form.html
§ admin/books/change_form.html
§ admin/change_form.html

Customモデル テンプレート

ほとんどの場合、最初のテンプレートを使用して、特定のモデルのテンプレートを作成します。通常、最良のアプローチは、基本テンプレートを拡張し、基本テンプレートで定義されているブロックに情報を追加することです。

たとえば、その本のページの上部にヘルプ テキストを追加したいとします。おそらく、図 17-1 に示すような形式になります。

図 17-1. カスタム管理編集フォーム

这做起来非常容易：只要建立一个admin/bookstore/book/change_form.html模板，并输入下面的代码：

{% extends "admin/change_form.html" %}
{% block form_top %}
<p>Insert meaningful help message here...</p>
{% endblock %}

所有这些模板都定义了一些可以被覆盖的块。对于大多数的应用程序来说，代码就是最好的文档，所以我们鼓励你能够详细阅读admin的模板来获得最新的信息（它们在django/contrib/admin/templates/）。

自定义JavaScript

这些自定义模型模板的常见用途包括，给admin页面增加自定义的javascript代码来实现一些特殊的视图物件或者是客户端行为。

幸运的是，这可以更简单。每一个admin模板都定义了{% block extrahead %}，你可以在元素中加入新的内容。例如你想要增加jQuery(http://jquery.com/)到你的admin历史中，可以这样做：

{% extends "admin/object_history.html" %}
{% block extrahead %}
<script src="http://media.example.com/javascript/jquery.js" type="text/javascript"></script>
<script type="text/javascript">
// code to actually use jQuery here...
</script>
{% endblock %}

备注

我们并不知道你为什么需要把jQuery放入到历史页中，但是这个例子可以被用到任何的模板中。

你可以使用这种技巧，加入任何的javascript代码。

创建自定义管理视图

现在，想要往Django的admin管理接口添加自定义行为的人，可能开始觉得有点奇怪了。我们这里所讲的都是如何改变admin管理接口的外观。他们都在喊：如何才能改变admin管理接口的内部工作机制。

首先要提的一点是，这并不神奇。admin管理接口并没有做任何特殊的事情，它只不过是和其他一些视图一样，简单地处理数据而已。

确实，这里有相当多的代码;它必须处理各种各样的操作，字段类型和设置来展示模型的行为.当你注意到ADMIN界面只是一系列视图(Views)的集合，增加自定义的管理视图就变得容易理解了。

作为举例，让我们为Django管理站点中的图书申请增加一个出版商报告的视图。建立一个admin视图用于显示被出版商分好类的书的列表，一个你要建立的自定义admin报告试图的极典型的例子。

首先，在我们的URLconf中连接一个视图。插入下面这行：

(r'^admin/books/report/$', 'mysite.books.admin_views.report'),
在将这行加入这个admin视图之前，原本的URLconf应该是这样：
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^admin/bookstore/report/$', 'bookstore.admin_views.report'),
(r'^admin/', include('django.contrib.admin.urls')),
)

为什么要将定制试图置于管理内容之前呢？回想一下，Django是按照顺序处理 URL
匹配式的。管理内容几乎匹配内容点之后所有的东西，因此如果我们把这几行的顺序颠倒一下， Django将会为该匹配式找到一个车内建管理视图，并将试图在books应用程序中为Report模型再入更新列表，而这却是不存在的。

现在我们开始写视图。为了简单起见，我们只把所有书籍加载到上下文中，让模板用{% regroup %}标签来处理分组操作。创建books/admin_views.py文件并写入以下内容：

from mysite.books.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
def report(request):
return render_to_response(
"admin/books/report.html",
{'book_list' : Book.objects.all()},
RequestContext(request, {}),
)
report = staff_member_required(report)

因为我们但分组操作留给了模板，该视图非常简单。然而，有几段微妙的细节值得我们搞清楚。

我们使用了django.contrib.admin.views.decorators中的staff_member_required修饰器。该修饰器与Django会话、用户和注册中讨论的login_required类似，但它还检查所指定的用户是否标记为内部人员，以决定是否允许他访问管理界面。

该修饰器保护所有内容的管理视图，并使得视图的身份验证逻辑匹配管理界面的其它部分。

我们在admin/之下解析了一个模板。尽管并非严格要求如此操作，将所有管理模板分组放在admin目录中是个好的做法。我们也将应用程序所有的模板放置在名叫books的目录中，这也是最佳实践。

我们将RequestContext用作render_to_response的第三个参数（``context_instance``）。这就确保了模板可访问当前用户的信息。

参看Django输出非HTML内容了解更多关于RequestContext的信息。

最后,
我们为这个视图做一个模板。我们将扩展内置管理模板,以使该视图明确地成为管理界面的一部分.

{% extends "admin/base_site.html" %}
{% block title %}List of books by publisher{% endblock %}
{% block content %}
<div id="content-main">
<h1>List of books by publisher:</h1>
{% regroup book_list|dictsort:"publisher.name" by publisher as books_by_publisher %}
{% for publisher in books_by_publisher %}
<h3>{{ publisher.grouper }}</h3>
<ul>
{% for book in publisher.list|dictsort:"title" %}
<li>{{ book }}</li>
{% endfor %}
</ul>
{% endfor %}
</div>
{% endblock %}

通过扩展admin/base_site.html,我们没费丝毫气力就得到了 Django管理界面的外观。图
17-2 我展示了像这样的一个最终结果。

图 17-2.一个自定义按出版商归类的图书管理视图

使用该技术，你可以向管理界面中添加任何你梦想中的东西。需要记住的是这些被叫做定制管理视图实际不过是普通的 Django视图，你可以使用在本书其它部分所学到的技术制作出符合自己需要的复杂管理界面。

下面用自定义admin视图的一些概念总结一下本章。

覆盖内置视图

有时缺省的管理视图无法完成某项工作。你可以轻松地换上自己的定制视图；只需要用自己的 URL遮蔽内建的管理视图。也就是说，如果在 URLConf中你的视图出现在缺省管理视图之前，你的视图将取代缺省视图被调用。

举例来说，我们可以用一个让用户简单输入 ISBN的窗体来取代内建的书籍创建视图。然后，我们可以从http://isbn.nu/查询该书的信息，并自动地创建对象。

这样的视图的代码留给读者作为一个练习,重要的部分是这个 URLconf代码片断:

(r'^admin/bookstore/book/add/$', 'mysite.books.admin_views.add_by_isbn'),

如果这个代码片段在 URLConf中出现于管理 URL
之前，add_by_isbn视图将完全取代标准的管理视图。

按照这种方式，我们可以替换删除确认页、编辑页面或者管理界面的其它任何部分

以上就是Django 管理界面的内容，更多相关内容请关注PHP中文网（www.php.cn）！