Django 管理インターフェース
- 黄舟オリジナル
- 2017-01-17 13:58:521373ブラウズ
これまで何度も述べてきたように、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
オブジェクト履歴/ 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 %}，你可以在93f0f5c25f18dab9d176bd4f6de5d30e元素中加入新的内容。例如你想要增加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）！