Django 관리 인터페이스

이전에 여러 번 언급했듯이 Django의 관리 인터페이스는 프레임워크의 핵심 기능 중 하나이며 대부분의 Django 개발자는 이것이 시간을 절약하고 사용하기 쉽다는 것을 알고 있습니다. 이 관리 인터페이스의 인기로 인해
Django 개발자는 이를 사용자 정의하고 확장하고 싶어하는 것이 일반적입니다.

Django 관리 사이트의 마지막 몇 섹션에서는 관리 인터페이스의 일부를 사용자 정의하는 몇 가지 간단한 방법을 소개합니다. 이 장에 들어가기 전에 해당 정보를 검토하십시오. 관리 인터페이스의 변경 목록 및
편집 양식을 사용자 정의하는 방법과 사이트에 맞게 관리 인터페이스의 스타일을 지정하는 방법이 설명되어 있습니다.

Django 관리 사이트에서는 관리 인터페이스를 사용하는 시기와 방법도 논의하며, 이 자료는 이 장의 나머지 부분에 대한 좋은 시작점이기 때문에 다음 단계로 넘어갈 것입니다. 여기:

분명히 이 관리 인터페이스는 데이터 편집 작업에 매우 유용합니다(상상해 보세요). 일종의 데이터 입력 작업을 완료하는 데 사용된다면 이 관리 인터페이스는 정말 타의 추종을 불허합니다. 우리는 이 책을 읽는 대부분의 독자들이 처리할 수 있는 데이터 입력 작업이 엄청나다고 생각합니다.

Django 관리 인터페이스는 특히 데이터 입력을 사용할 기술적 배경이 없는 사용자에게 초점을 맞췄습니다. 이는 또한 이 기능이 개발된 목적이기도 합니다. Django가 처음 개발된 신문에서는 다음과 같은 요구 사항을 바탕으로 전형적인 온라인 지자체 상수도 품질 보고 시스템이 개발되었습니다.

§ 해당 주제를 담당한 기자는 개발자가 기존 데이터를 제출했습니다.

§ 개발자는 데이터를 중심으로 모델을 설계하고 기자를 위한 관리 인터페이스를 개발합니다.

§ 기자가 Django에 데이터를 입력하는 동안 프로그래머는 공개 액세스 인터페이스 개발에 집중할 수 있습니다(재미있는 부분!).

즉, Django 관리 인터페이스의 주요 목적은 콘텐츠 편집자와 프로그래머가 동시에 작업할 수 있도록 하는 것입니다.

물론, 명백한 데이터 입력 작업 외에도 관리 인터페이스가 여러 다른 상황에서 유용하다는 것을 알았습니다.

§ 데이터 모델 확인: 새 데이터 모델을 정의한 후 가장 먼저 해야 할 일은 관리 인터페이스에서 이를 실행하고 일부 가상 데이터를 입력하는 것입니다. 일반적으로 데이터 모델링의 오류가 발견된 후 그래픽 모델 인터페이스를 사용하여 핵심을 빠르게 찾을 수 있습니다.

§ 획득한 데이터 관리: 대부분의 데이터가 자동으로 생성된 소스에서 나오므로 http://chicagocrime.org와 같은 사이트와 관련된 실제 데이터 입력은 거의 없습니다. 그러나 획득한 데이터가 잘못되어 문제가 발생할 경우, 잘못된 데이터를 쉽게 찾아 수정할 수 있으면 문제 해결에 도움이 됩니다.

맞춤 설정이 없거나 약간만 있어도 Django 관리 인터페이스는 가장 일반적인 상황을 처리할 수 있습니다. 그러나 Django의 관리 인터페이스가 이러한 일반적인 상황을 잘 처리할 수 있도록 하는 디자인의 타협은 다른 편집 모델도 처리할 수 없다는 것을 의미합니다.

나중에 Django 관리 인터페이스가 처리하도록 설계되지 않은 상황에 대해 논의하겠지만, 먼저 잠시 벗어나 Django의 설계 철학에 대해 논의해 보겠습니다.

관리 방법

기본적으로 Django 관리 인터페이스는 단 하나의 동작만을 위해 설계되었습니다:

신뢰할 수 있는 사용자는 구조화된 콘텐츠를 편집합니다.

네, 아주 간단합니다. 하지만 그 단순함은 수많은 가정에 기초하고 있습니다. Django 관리 인터페이스의 전체 디자인 철학은 이러한 가정에서 직접적으로 따르므로 다음 섹션에 나타나는 용어의 의미를 자세히 살펴보겠습니다.

신뢰할 수 있는 사용자

관리자 인터페이스는 귀하, 즉 개발자가 신뢰하는 사람들이 사용하도록 설계되었습니다. 이는 단순히 인증된 사람을 의미하는 것이 아니라 Django가 콘텐츠 편집자가 올바른 일만 수행할 수 있다고 가정한다는 의미입니다.

즉, 사용자를 신뢰하면 사용자는 콘텐츠 편집 권한을 요청할 필요가 없으며 누구도 편집 작업에 권한을 부여할 필요가 없습니다. . 또 다른 의미는 인증 시스템이 강력하기는 하지만 이 글을 쓰는 시점에서는 개체 수준 기반의 액세스 제한을 지원하지 않는다는 것입니다. 누군가가 자신의 뉴스 기사를 편집하도록 허용하는 경우 해당 사용자가 허가 없이 다른 사람의 기사를 편집하지 않을 것임을 확신해야 합니다.

편집

Django 관리 인터페이스의 주요 목적은 사용자가 데이터를 편집할 수 있도록 하는 것입니다. 이는 언뜻 보면 분명하지만 자세히 살펴보면 약간 이해하기 어렵고 특이해집니다.

예를 들어 관리 인터페이스는 (방금 논의한 것처럼) 데이터를 검사하는 데 적합하지만 원래 그런 용도로 설계된 것은 아닙니다. Django 세션, 사용자 및 등록에서 설명한 것처럼 보기 권한이 없습니다. Django는 관리 인터페이스의 누군가가 무언가를 볼 수 있으면 편집도 할 수 있다고 가정합니다.

한 가지 더 중요한 점은 원격 통화 워크플로가 부족하다는 것입니다. 특정 작업이 일련의 단계로 구성된 경우 해당 단계가 특정 순서로 완료되도록 보장하는 메커니즘이 없습니다. Django 관리 인터페이스는 편집에 중점을 두고 수정과 관련된 활동에는 신경 쓰지 않습니다. 이러한 워크플로 회피는 신뢰의 원칙에서도 비롯됩니다. 즉, 관리 인터페이스는 워크플로가 인간의 것이며 코드로 구현될 필요가 없다는 생각으로 설계되었습니다.

마지막으로 주목할 점은 관리 인터페이스에 집계 기능이 없다는 것입니다. 즉, 합계, 평균 등의 표시는 지원되지 않습니다. 다시 말하지만 관리 인터페이스는 편집 전용입니다. 다른 모든 작업은 보기 정의를 통해 수행해야 합니다.

구조화된 콘텐츠

Django의 다른 부분과 협력하여 관리 인터페이스에서는 구조화된 데이터를 사용할 것으로 기대합니다. . 따라서 파일 시스템의 데이터와 같은 다른 데이터에 대해서는 Django 모델에 저장된 데이터 편집만 지원하므로 편집하려면 보기를 사용자 정의해야 합니다.

여기서 중지하세요

확실히 Django의 관리 인터페이스는 모든 사람에게 모든 것을 제공하도록 의도되지 않았습니다. .도구 대신에 우리는 한 가지에 집중하여 완벽하게 완성하는 것을 선택합니다.

Django의 관리 인터페이스를 확장할 때 동일한 디자인 컨셉을 고수해야 합니다. (확장성은 우리의 목표가 아닙니다.) 모든 것은 사용자 정의 Django 뷰로 수행될 수 있고 관리 인터페이스에 시각적으로 쉽게 통합될 수 있기 때문에(다음 장에서 설명) 관리 인터페이스를 사용자 정의할 수 있는 기본 제공 기회는 의도적으로 약간 제한됩니다.

관리 인터페이스의 복잡성에도 불구하고 항상 애플리케이션일 뿐이라는 점을 기억하는 것이 중요합니다. 시간이 충분하다면 모든 Django 개발자는 관리 인터페이스에서 할 수 있는 모든 작업을 수행할 수 있습니다. 따라서 우리는 완전히 다른 관리 인터페이스가 미래에 나타나기를 희망해야 합니다. 이 새로운 인터페이스는 다른 가정을 갖고 완전히 다른 방식으로 작동합니다.

마지막으로 이 글을 쓰는 시점에 Django 개발자들은 더 많은 사용자 정의 유연성을 제공할 새로운 관리 인터페이스를 개발 중이라는 점을 지적해야 합니다. 당신이 이 글을 읽을 때쯤에는 이러한 새로운 기능이 실제 Django 릴리스에 적용되었을 수도 있습니다. newforms-admin 백본 코드가 통합되었는지 알아보려면
Django 커뮤니티의 누군가에게 문의하세요.

사용자 정의된 관리 템플릿

Django는 내장된 관리자 관리 템플릿을 사용자 정의하기 위한 몇 가지 도구를 제공합니다. 간략히 소개하겠습니다. 다른 작업(예: 작업 흐름 제어 또는 보다 세분화된 권한 관리)의 경우 이 장의 사용자 정의 관리 보기 만들기 섹션을 읽어야 합니다.

이제 관리자 관리 인터페이스의 모양을 빠르게 사용자 정의하는 방법을 살펴보겠습니다. Django 관리 사이트는 가장 일반적인 작업 중 일부를 다루고 있습니다: 로고 변경(파란색을 싫어하는 뾰족한 머리의 상사를 위한) 또는 사용자 정의 양식 제공.

추가 목표에는 종종 템플릿의 일부 특수 항목을 변경하는 것이 포함됩니다. 수정 목록, 편집 양식, 삭제 확인 페이지, 기록 보기를 포함한 각 관리 보기에는 다양한 방법으로 재정의할 수 있는 관련 템플릿이 있습니다.

먼저 템플릿을 전역적으로 재정의할 수 있습니다. 관리 보기는 표준 템플릿 로딩 메커니즘을 사용하여 템플릿을 찾습니다. 따라서 template 디렉토리에 새 템플릿을 생성하면 Django가 자동으로 이를 로드합니다. 전역 템플릿은 표 17-1에 나열되어 있습니다.

표 17-1. 글로벌 관리 템플릿

보기 > 🎜>

양식 추가/수정                                                   관리자/ change_form.html                                          

대부분의 경우 개별 객체나 애플리케이션을 수정하려면 전역 설정을 수정하는 대신. 따라서 모든 관리 보기는 항상 먼저 모델이나 애플리케이션과 관련된 템플릿을 찾습니다. 이러한 보기가 템플릿을 찾는 순서는 다음과 같습니다.

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

예를 들어 도서 애플리케이션에서 도서 모듈의 추가/수정 양식 보기는 다음 순서로 템플릿을 찾습니다.

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

사용자 정의 모델 템플릿

대부분의 경우 첫 번째 템플릿을 사용하여 특정 모델에 대한 템플릿을 생성하려고 합니다. 모델. 일반적으로 가장 좋은 방법은 기본 템플릿을 확장하고 기본 템플릿에 정의된 블록에 정보를 추가하는 것입니다.

예를 들어 해당 책 페이지 상단에 도움말 텍스트를 추가하고 싶습니다. 아마도 그림 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）！