Django-Verwaltungsschnittstelle

Wie wir schon oft erwähnt haben, ist die Admin-Oberfläche von Django eine der Killerfunktionen des Frameworks, und die meisten Django-Entwickler wissen, dass sie zeitsparend und einfach zu verwenden ist. Aufgrund der Beliebtheit dieser Admin-Schnittstelle ist es für
Django-Entwickler üblich, sie anzupassen und zu erweitern.

In den letzten Abschnitten der Django-Administratorseite werden einige einfache Möglichkeiten zum Anpassen von Teilen der Admin-Oberfläche vorgestellt. Bevor Sie mit diesem Kapitel beginnen, lesen Sie sich bitte die Informationen durch. Darin wird beschrieben, wie Sie die Änderungsliste und
Bearbeitungsformulare der Admin-Oberfläche anpassen und wie Sie die Admin-Oberfläche im Einklang mit der Site gestalten.

Auf der Django-Administratorseite wird auch erläutert, wann und wie die Admin-Oberfläche verwendet wird. Da dieses Material ein guter Ausgangspunkt für den Rest dieses Kapitels ist, machen wir weiter hier drüber:

Offensichtlich ist diese Verwaltungsoberfläche äußerst nützlich für Datenbearbeitungsarbeiten (stellen Sie sich das vor). Wenn es für die Durchführung irgendeiner Dateneingabe verwendet wird, ist diese Verwaltungsschnittstelle wirklich unübertroffen. Wir vermuten, dass den meisten Lesern dieses Buches eine Menge Dateneingabeaufgaben zur Verfügung stehen.

Die Django-Administratoroberfläche richtet sich insbesondere an Benutzer ohne technische Kenntnisse in der Dateneingabe. Aus diesem Grund wurde diese Funktion auch entwickelt. In der Zeitung, in der Django erstmals entwickelt wurde, wurde ein typisches Online-Berichtssystem zur Qualität der kommunalen Wasserversorgung mit den folgenden Anforderungen entwickelt:

§ Der für das Thema zuständige Reporter traf sich mit a Entwickler und übermittelte vorhandene Daten.

§ Der Entwickler entwirft ein Modell rund um die Daten und entwickelt eine Verwaltungsschnittstelle für den Reporter.

§ Während der Reporter Daten in Django eingibt, kann sich der Programmierer auf die Entwicklung der öffentlichen Zugriffsschnittstelle konzentrieren (der lustige Teil!).

Mit anderen Worten: Der Hauptzweck der Django-Verwaltungsoberfläche besteht darin, Inhaltseditoren und Programmierern die gleichzeitige Arbeit zu erleichtern.

Natürlich haben wir festgestellt, dass die Admin-Oberfläche neben den offensichtlichen Dateneingabeaufgaben auch in einer Reihe anderer Situationen nützlich ist.

§ Überprüfen Sie das Datenmodell: Nachdem wir ein neues Datenmodell definiert haben, müssen wir es zunächst in der Verwaltungsoberfläche ausführen und einige hypothetische Daten eingeben. Nachdem ein Fehler in der Datenmodellierung entdeckt wurde, kann die grafische Modelloberfläche normalerweise verwendet werden, um den Kernpunkt schnell zu finden.

§ Verwalten Sie die erhaltenen Daten: Sehr wenige echte Dateneingaben sind mit Websites wie http://chicagocrime.org verknüpft, da die meisten Daten aus automatisch generierten Quellen stammen. Wenn die erfassten Daten jedoch falsch sind und Probleme verursachen, hilft die Möglichkeit, die fehlerhaften Daten leicht zu finden und zu ändern, um das Problem zu lösen.

Ohne oder nur geringfügige Anpassungen kann die Django-Verwaltungsoberfläche die meisten gängigen Situationen bewältigen. Der Kompromiss im Design, der es der Admin-Oberfläche von Django ermöglicht, diese häufige Situation gut zu bewältigen, bedeutet jedoch, dass sie auch mit einigen anderen Bearbeitungsmodellen nicht umgehen kann.

Später werden wir Situationen besprechen, für die die Django-Administratoroberfläche nicht ausgelegt ist, aber lassen Sie uns zunächst einen Moment abschweifen und die Designphilosophie besprechen.

So verwalten Sie

Im Kern ist die Django-Verwaltungsoberfläche nur für ein Verhalten konzipiert:

Vertrauenswürdige Benutzer bearbeiten strukturierte Inhalte.

Ja, es ist sehr einfach, aber diese Einfachheit basiert auf einer ganzen Reihe von Annahmen. Die gesamte Designphilosophie der Admin-Oberfläche von Django ergibt sich direkt aus diesen Annahmen. Schauen wir uns also die Bedeutung der Begriffe an, die in den folgenden Abschnitten vorkommen.

Vertrauenswürdige Benutzer

Die Admin-Oberfläche ist für die Verwendung durch Personen konzipiert, denen Sie als Entwickler vertrauen. Damit sind nicht nur authentifizierte Personen gemeint; es bedeutet auch, dass Django davon ausgeht, dass man sich darauf verlassen kann, dass Inhaltsredakteure nur das Richtige tun.

Das bedeutet wiederum, dass Benutzer, denen Sie vertrauen, Inhalte bearbeiten können, ohne um Erlaubnis zu fragen, und dass niemand eine Erlaubnis für ihre Bearbeitungsaktionen erteilen muss. Eine weitere Implikation ist, dass das Authentifizierungssystem zum jetzigen Zeitpunkt zwar leistungsstark ist, aber keine Zugriffsbeschränkungen auf Objektebene unterstützt. Wenn Sie jemandem erlauben, seine eigenen Nachrichtenbeiträge zu bearbeiten, müssen Sie sicher sein, dass der Benutzer die Beiträge anderer Personen nicht ohne Erlaubnis bearbeitet.

Bearbeiten

Der Hauptzweck der Django-Administratoroberfläche besteht darin, Benutzern das Bearbeiten von Daten zu ermöglichen. Das ist auf den ersten Blick offensichtlich, wird bei näherer Betrachtung jedoch etwas schwer fassbar und ungewöhnlich.

Zum Beispiel eignet sich die Admin-Oberfläche zwar hervorragend zum Überprüfen von Daten (wie gerade besprochen), aber dafür ist sie nicht konzipiert. Wie wir in Django-Sitzungen, Benutzer und Registrierungen besprochen haben, fehlen ihm Ansichtsberechtigungen. Django geht davon aus, dass jemand, der in der Admin-Oberfläche etwas sehen kann, es auch bearbeiten kann.

Es gibt noch einen weiteren wichtigen Punkt, und zwar das Fehlen eines Remote-Anruf-Workflows. Wenn eine bestimmte Aufgabe aus einer Abfolge von Schritten besteht, gibt es keinen Mechanismus, der sicherstellt, dass diese Schritte in einer bestimmten Reihenfolge ausgeführt werden. Die Django-Administratoroberfläche konzentriert sich auf die Bearbeitung und kümmert sich nicht um die Aktivitäten im Zusammenhang mit Änderungen. Diese Vermeidung von Arbeitsabläufen ergibt sich auch aus dem Prinzip des Vertrauens: Die Verwaltungsoberfläche wurde mit der Idee entworfen, dass Arbeitsabläufe eine menschliche Sache sind und nicht in Code implementiert werden müssen.

Abschließend ist noch die fehlende Aggregation in der Admin-Oberfläche zu beachten. Das heißt, die Anzeige von Summen und Durchschnittswerten wird nicht unterstützt. Auch hier dient die Admin-Oberfläche nur der Bearbeitung – alles andere wird von Ihnen erwartet, indem Sie Ansichten definieren.

Strukturierter Inhalt

In Zusammenarbeit mit anderen Teilen von Django erwartet die Verwaltungsoberfläche, dass Sie strukturierte Daten verwenden . Daher wird nur die Bearbeitung von Daten unterstützt, die in Django-Modellen gespeichert sind. Für andere Daten, z. B. Daten im Dateisystem, müssen Sie die zu bearbeitende Ansicht anpassen.

Hören Sie hier auf

Natürlich ist die Admin-Oberfläche von Django nicht dazu gedacht, alles für alle zu bieten Stattdessen konzentrieren wir uns auf eine Sache und vollenden sie bis zur Perfektion.

Bei der Erweiterung der Verwaltungsoberfläche von Django müssen Sie sich an dieselbe Designphilosophie halten. (Beachten Sie, dass Skalierbarkeit nicht unser Ziel ist). Da alles mit benutzerdefinierten Django-Ansichten erledigt werden kann und diese einfach visuell in die Admin-Oberfläche integriert werden können (im nächsten Kapitel beschrieben), sind die integrierten Möglichkeiten zur Anpassung der Admin-Oberfläche absichtlich etwas eingeschränkt.

Es ist wichtig zu bedenken, dass es sich trotz der Komplexität der Verwaltungsoberfläche immer nur um eine Anwendung handelt. Wenn genügend Zeit zur Verfügung steht, kann jeder Django-Entwickler alles tun, was die Admin-Oberfläche kann. Daher müssen wir hoffen, dass in Zukunft eine völlig andere Admin-Oberfläche erscheint. Diese neue Schnittstelle basiert auf anderen Annahmen und funktioniert auf völlig andere Weise.

Abschließend sei darauf hingewiesen, dass die Django-Entwickler zum Zeitpunkt des Schreibens dieses Artikels an einer neuen Verwaltungsoberfläche arbeiten, die mehr Anpassungsflexibilität bieten soll. Wenn Sie dies lesen, haben diese neuen Funktionen möglicherweise bereits Eingang in echte Django-Releases gefunden. Sie können sich bei jemandem aus der
Django-Community erkundigen, ob der newforms-admin-Backbone-Code integriert wurde.

Benutzerdefinierte Admin-Vorlagen

Django bietet einige Tools zum Anpassen der integrierten Admin-Management-Vorlagen, die wir Ihnen vorstellen werden Beschreiben wir es kurz. Für andere Aufgaben (z. B. Workflow-Steuerung oder detailliertere Berechtigungsverwaltung) müssen Sie den Abschnitt „Erstellen einer benutzerdefinierten Admin-Ansicht“ in diesem Kapitel lesen.

Lassen Sie uns nun einen Blick darauf werfen, wie Sie das Erscheinungsbild der Admin-Verwaltungsoberfläche schnell anpassen können. Die Django-Administratorseite deckt einige der häufigsten Aufgaben ab: das Ändern des Logos (für die Chefs mit stacheligen Haaren, die die Farbe Blau hassen) oder die Bereitstellung eines benutzerdefinierten Formulars.

Weitere Ziele umfassen häufig die Änderung einiger besonderer Elemente in der Vorlage. Jede Admin-Ansicht, einschließlich der Änderungsliste, des Bearbeitungsformulars, der Löschbestätigungsseite und der Verlaufsansicht, verfügt über eine zugehörige Vorlage, die auf verschiedene Arten überschrieben werden kann.

Zuerst können Sie die Vorlage global überschreiben. Die Admin-Ansicht verwendet den Standardmechanismus zum Laden von Vorlagen, um Vorlagen zu finden. Wenn Sie also eine neue Vorlage im Vorlagenverzeichnis erstellen, lädt Django diese automatisch. Globale Vorlagen sind in Tabelle 17-1 aufgeführt.

Tabelle 17-1. Globale Verwaltungsvorlage

Ansicht                                                                                                                                                          admin/change_list.html

Formular hinzufügen/bearbeiten                                                      admin/ change_form.html                                              einzelnes Objekt oder Anwendung, anstatt globale Einstellungen zu ändern. Daher sucht jede Admin-Ansicht immer zuerst nach Vorlagen, die sich auf das Modell oder die Anwendung beziehen. Die Reihenfolge, in der diese Ansichten nach Vorlagen suchen, ist wie folgt:

In der Bücheranwendung sucht die Ansicht des Formulars „Hinzufügen/Bearbeiten“ des Buchmoduls beispielsweise in der folgenden Reihenfolge nach Vorlagen :

Benutzerdefinierte Modellvorlagen

Meistens möchten Sie die erste Vorlage verwenden Erstellen Sie eine Vorlage für ein bestimmtes Modell. Normalerweise besteht der beste Ansatz darin, die Basisvorlage zu erweitern und Informationen zu den in der Basisvorlage definierten Blöcken hinzuzufügen.

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

Zum Beispiel möchten wir oben auf dieser Buchseite einen Hilfetext hinzufügen. Wahrscheinlich so etwas wie das in Abbildung 17-1 gezeigte Formular.

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

Ein benutzerdefiniertes Verwaltungsbearbeitungsformular.

这做起来非常容易：只要建立一个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）！