Interface de gestion Django

Comme nous l'avons mentionné à plusieurs reprises auparavant, l'interface d'administration de Django est l'une des fonctionnalités phares du framework, et la plupart des développeurs Django savent qu'elle permet de gagner du temps et est facile à utiliser. En raison de la popularité de cette interface d'administration, il est courant que les développeurs
Django souhaitent la personnaliser et l'étendre.

Les dernières sections du site d'administration de Django présentent quelques façons simples de personnaliser certaines parties de l'interface d'administration. Avant d'entrer dans ce chapitre, veuillez consulter ces informations ; elles expliquent comment personnaliser la liste de modifications et
modifier les formulaires de l'interface d'administration, et comment styliser l'interface d'administration en cohérence avec le site.

Le site d'administration de Django explique également quand et comment utiliser l'interface d'administration, et puisque ce matériel est un bon point de départ pour le reste de ce chapitre, nous allons y aller dessus ici :

Évidemment, cette interface de gestion est extrêmement utile pour le travail d'édition de données (imaginez ça). Si elle est utilisée pour effectuer une sorte de travail de saisie de données, cette interface de gestion est vraiment inégalée. Nous soupçonnons que la plupart des lecteurs de ce livre disposent d’une tonne de tâches de saisie de données.

L'interface d'administration de Django est particulièrement destinée aux utilisateurs n'ayant aucune formation technique pour utiliser la saisie de données ; c'est également le but pour lequel cette fonctionnalité a été développée. Dans le journal où Django a été développé pour la première fois, un système typique de rapport en ligne sur la qualité de l'approvisionnement en eau municipale a été développé avec les exigences suivantes :

§ Le journaliste responsable du sujet a rencontré un développeur et soumis les données existantes.

§ Le développeur conçoit un modèle autour des données et développe une interface de gestion pour le reporter.

§ Pendant que le journaliste saisit les données dans Django, le programmeur peut se concentrer sur le développement de l'interface d'accès public (la partie amusante !).

En d'autres termes, l'objectif principal de l'interface de gestion de Django est de permettre aux éditeurs de contenu et aux programmeurs de travailler en même temps.

Bien sûr, outre les tâches évidentes de saisie de données, nous avons trouvé que l'interface d'administration était utile dans un certain nombre d'autres situations.

§ Vérifier le modèle de données : Après avoir défini un nouveau modèle de données, la première chose que nous devons faire est de l'exécuter dans l'interface de gestion et de saisir des données hypothétiques. Habituellement, après la découverte d’une erreur dans la modélisation des données, l’interface du modèle graphique peut être utilisée pour trouver rapidement le point crucial.

§ Gérer les données obtenues : Très peu d'entrées de données réelles sont associées à des sites comme http://chicagocrime.org car la plupart des données proviennent d'une source générée automatiquement. Cependant, lorsque les données obtenues sont erronées et causent des problèmes, être capable de trouver et de modifier facilement les données erronées aidera à résoudre le problème.

Avec pas ou peu de personnalisation, l'interface de gestion de Django peut gérer les situations les plus courantes. Cependant, le compromis même dans la conception qui fait que l'interface d'administration de Django gère si bien cette situation courante signifie qu'elle ne peut pas également gérer certains autres modèles d'édition.

Plus tard, nous discuterons des situations pour lesquelles l'interface d'administration de Django n'est pas conçue, mais faisons d'abord une parenthèse un instant et discutons de sa philosophie de conception.

Comment gérer

À la base, l'interface de gestion de Django est conçue pour un seul comportement :

Les utilisateurs de confiance modifient le contenu structuré.

Oui, c'est très simple, mais cette simplicité repose sur tout un tas d'hypothèses. Toute la philosophie de conception de l'interface d'administration de Django découle directement de ces hypothèses, examinons donc la signification des termes qui apparaissent dans ces sections suivantes.

Utilisateurs de confiance

L'interface d'administration est conçue pour être utilisée par des personnes en qui vous, le développeur, avez confiance. Cela ne signifie pas seulement des personnes authentifiées ; cela signifie que Django suppose que l’on peut faire confiance aux éditeurs de contenu pour faire ce qu’il faut.

En retour, cela signifie que si vous faites confiance aux utilisateurs, ils n'ont pas besoin de demander l'autorisation pour modifier le contenu, et personne n'a besoin de donner l'autorisation pour leurs actions d'édition. . Une autre implication est que, bien que le système d'authentification soit puissant, au moment d'écrire ces lignes, il ne prend pas en charge les restrictions d'accès au niveau des objets. Si vous autorisez quelqu'un à modifier ses propres actualités, vous devez être sûr que l'utilisateur ne modifiera pas les actualités d'autres personnes sans autorisation.

Modifier

L'objectif principal de l'interface d'administration de Django est de permettre aux utilisateurs de modifier des données. Cela est évident à première vue, mais devient un peu insaisissable et inhabituel à y regarder de plus près.

Par exemple, même si l'interface d'administration est idéale pour inspecter les données (comme nous venons de le dire), ce n'est pas pour cela qu'elle a été conçue. Comme nous en avons parlé dans Django Sessions, Users et Registrations, il lui manque des autorisations d'affichage. Django suppose que si quelqu'un dans l'interface d'administration peut voir quelque chose, il peut également le modifier.

Il y a une autre chose importante à noter, c'est le manque de flux de travail d'appel à distance. Si une tâche particulière consiste en une séquence d’étapes, il n’existe aucun mécanisme permettant de garantir que ces étapes sont exécutées dans un ordre particulier. L'interface d'administration de Django se concentre sur l'édition et ne se soucie pas des activités entourant les modifications. Cet évitement du workflow découle également du principe de confiance : l'interface de gestion est conçue avec l'idée que le workflow est une chose humaine et n'a pas besoin d'être implémenté dans le code.

Enfin, quelque chose à noter est le manque d'agrégation dans l'interface d'administration. Autrement dit, l'affichage d'éléments tels que les totaux et les moyennes n'est pas pris en charge. Encore une fois, l'interface d'administration est uniquement destinée à l'édition - elle attend de vous que vous fassiez tout le reste en définissant des vues.

Contenu structuré

Avec la coopération d'autres parties de Django, l'interface de gestion attend de vous que vous utilisiez des données structurées . Par conséquent, il ne prend en charge que l'édition des données stockées dans les modèles Django ; pour les autres données, telles que les données du système de fichiers, vous devez personnaliser la vue à modifier.

Arrêtez ça ici

Maintenant, c'est sûr, l'interface d'administration de Django n'est pas destinée à être tout pour tout le monde . outils ; nous choisissons plutôt de nous concentrer sur une chose et de la compléter à la perfection.

Lorsque vous développez l'interface de gestion de Django, vous devez adhérer au même concept de conception. (Notez que l'évolutivité n'est pas notre objectif). Parce que tout peut être fait avec des vues Django personnalisées, et parce qu'elles peuvent être facilement intégrées visuellement dans l'interface d'administration (décrites dans le chapitre suivant), les opportunités intégrées pour personnaliser l'interface d'administration sont intentionnellement un peu limitées.

Il est important de rappeler que malgré la complexité de l'interface de gestion, il ne s'agit toujours que d'une application. Avec suffisamment de temps, n'importe quel développeur Django peut faire tout ce que l'interface d'administration peut faire. Par conséquent, nous devons espérer qu’une interface d’administration complètement différente apparaîtra à l’avenir. Cette nouvelle interface repose sur un ensemble d’hypothèses différent et fonctionne d’une manière complètement différente.

Enfin, il convient de souligner qu'au moment de la rédaction de cet article, les développeurs de Django travaillent sur une nouvelle interface de gestion, qui offrira plus de flexibilité de personnalisation. Au moment où vous lirez ceci, ces nouvelles fonctionnalités auront peut-être fait leur chemin dans de véritables versions de Django. Vous pouvez vérifier auprès de quelqu'un de la communauté
Django si le code du backbone newforms-admin a été intégré.

Modèles d'administration personnalisés

Django fournit des outils pour personnaliser les modèles de gestion d'administration intégrés, que nous allons décrivons-le brièvement. Présentons-le. Pour d'autres tâches (telles que le contrôle du flux de travail ou une gestion plus fine des autorisations), vous devez lire la section Création d'une vue d'administration personnalisée de ce chapitre.

Voyons maintenant comment personnaliser rapidement l'apparence de l'interface de gestion de l'administrateur. Le site d'administration de Django couvre certaines des tâches les plus courantes : changer le logo (pour les patrons aux cheveux hérissés qui détestent la couleur bleue) ou fournir un formulaire personnalisé.

D'autres objectifs incluent souvent la modification de certains éléments spéciaux dans le modèle. Chaque vue d'administration, y compris la liste de modifications, le formulaire de modification, la page de confirmation de suppression et la vue historique, possède un modèle associé qui peut être remplacé de différentes manières.

Tout d'abord, vous pouvez remplacer le modèle globalement. La vue administrateur utilise le mécanisme de chargement de modèles standard pour rechercher des modèles. Ainsi, si vous créez un nouveau modèle dans le répertoire des modèles, Django le chargera automatiquement. Les modèles globaux sont répertoriés dans le Tableau 17-1.

Tableau 17-1. Modèle de gestion globale

Afficher                                                                  

Ajouter/modifier un formulaire                                                   admin/ change_form.html                                                          

La plupart des le temps, vous souhaiterez peut-être simplement modifier un objet ou une application individuelle, plutôt que de modifier les paramètres globaux. Par conséquent, chaque vue d'administration recherche toujours d'abord les modèles liés au modèle ou à l'application. L'ordre dans lequel ces vues recherchent les modèles est le suivant :

Par exemple, dans l'application livres, la vue du formulaire d'ajout/modification du module Livre recherchera les modèles dans l'ordre suivant :

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

Modèles de modèles personnalisés

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

La plupart du temps, vous souhaitez utiliser le premier modèle pour créer un modèle pour un modèle spécifique. Habituellement, la meilleure approche consiste à étendre le modèle de base et à ajouter des informations aux blocs définis dans le modèle de base.

Par exemple, nous souhaitons ajouter un texte d'aide en haut de la page de ce livre. Probablement quelque chose qui ressemble au formulaire illustré à la figure 17-1.

Figure 17-1. Un formulaire d'édition de gestion personnalisé.

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