第6章介紹了Django的admin界面，現在是回過頭來仔細看看這個的時候了
我們前面講的幾次admin是Django的"殺手級特性"，并且大多數Django開發(fā)人員很快愛上了它節(jié)省時間的所有特性
這樣自然而然的大部分Django開發(fā)人員開始尋找自定義或者擴展admin的方法
第6章最后幾部分講到了一些定制admin界面某一部分的簡單方法，重新閱讀一下那些資料是個好主意
它講述了一些定制admin的更改列表，編輯表單以及l(fā)ogo等等的簡單方法
第6章也討論了何時和為什么你想使用admin界面，這些資料跳躍到了其他章節(jié)，我們這里重新介紹一下:
顯然，admin對編輯數據非常有用(fancy that)，如果你有一些錄入數據的任務，則admin不可能被其它東西打敗
我們料想大多數本書的讀者都將有很多數據錄入的任務
Django的admin在非技術用戶需要錄入數據時特別閃耀，這是這個特性的最初起源
盡管如此，我們發(fā)現除了顯而易見的數據錄入任務，admin也在下面一些情況下有用:
1，檢查數據模型，我們定義了一個新模型后第一件事就是在admin里調用它并輸入一些模擬數據，這對我們發(fā)現數據
模型的錯誤并有一個圖形界面來顯示這些錯誤很有幫助
2，管理必須的數據，對于chicagocrime.org來說很少有數據錄入的任務，因為它的數據都來自于一個自動的數據源
盡管如此，當自動獲取數據的模塊出問題時，通過admin可以輕松的編輯數據，這是很有用的
Django的admin不需要或者需要很少配置就可以處理這些常見的情況，但是，處理這些常見的情況如此的好意味著
Django的admin在處理其它情形時不一定很好
我們后面將談到Django的admin不適合做的一些事情，但是現在我們先離題來看看它的一些哲學:

admin的禪宗
作為它的核心，Django的admin設計用來為如下的一個單獨的活動:
受信任的用戶編輯結構化的內容
是的，很簡單，但是這簡單的一行隱藏著很多內容，Django的admin的整個哲學都基于此
讓我們深入了解這個句子的子內容:
"受信任的用戶"
admin設計來被你(開發(fā)者)信任的人用，這不僅僅表示那些被授權的用戶，它表示Django假設你的內容編輯者可以
被信任來做正確的事情，這意味著編輯內容沒有批準的過程，如果你信任你的用戶，沒有人需要對編輯的批準
這也表明了權限系統(tǒng)不支持基于一個對象的限制訪問
如果你信任某人來編輯他自己的故事，你也將信任他不會在沒有權限的情況下編輯別人的故事
"編輯"
Django的admin的首要目的是讓人們編輯內容，這最初看起來很顯而易見，但是也存在一些細小而強大的影響
例如，盡管admin對重新視查數據很有用，但是它不是設計來干這個的，注意缺少"can view"權限(參考第12章)
Django假設如果用戶被允許在admin里查看內容，他們也被允許編輯它
另外一個很值得注意的地方是admin缺少一些例如"工作流"的東西，如果一些任務需要幾步來完成，admin不支持
特別的順序來做這件事情，admin關注于編輯，而不是圍繞編輯的其它活動
對于工作流的缺乏支持也起源于信任的原則，admin的哲學是，工作流屬于個人問題，而不應該用代碼實現
最后，注意admin缺乏統(tǒng)計的支持，它不支持顯示總數，平均數等等
再一次說明，admin是用來編輯的，它期望你寫自定義的視圖來完成其它的任務
"結構化的內容"
因為Django其它部分的關系，admin希望你與結構化的數據工作，這樣，admin僅僅支持編輯用Django模型存儲的數據
對于其它形式的數據，你則需要自定義視圖
總結
現在應該很清楚了，Django的admin不是給任何用戶來做任何事情的，而是牢牢的關注一點并且把這一點做的非常好
當我們需要擴展Django的admin時，同一哲學的大部分內容存在與此(注意擴展性無處不在)
因為自定義的Django視圖可以做任何事情，而且它們可以可視化的集成到admin(參看下面內容)，內建的定制admin的
機會在一定程序上被設計所限制

定制admin模板
我們下面將看到，你有幾種工具來定制內建的admin模板，但是對于其它任務，例如需要自定義工作流或者細粒度權限
你將需要閱讀本章末尾講到的定制admin視圖
現在我們來看看快速定制admin的外觀和行為，第6章講到了一些常見的任務，如更改logo樣式和提供自定義admin表單
就這點來說，我們通常需要更改一個特殊項的一些模板
admin的每一個視圖，如更改列表，編輯表單，刪除確認頁面，歷史視圖等都有一個分配的模板
而這個模板可以通過幾種方式來覆蓋
首先，你可以全局覆蓋模板，admin視圖使用標準模板載入機制來尋找模板，所以如果你在你的模板目錄里創(chuàng)建模板
Django將載入并使用這些模板而不是使用Django綁定的默認admin模板
這些全局模板如下:
視圖                基本模板名
更改列表            admin/change_list.html
增加/編輯表單       admin/change_form.html
刪除確認            admin/delete_confirmation.html
對象歷史            admin/object_history.html
盡管如此，大多數情況下你只想更改一個單獨的對象或者app的模板而不是全局的模板
這樣的話，每個admin視圖首先尋找模型和app專有的模板，這些視圖按下面的順序尋找模板:
admin/<app_lable>/<object_name>/<template>.html
admin/<app_lable>/<template>.html
admin/<template>.html
例如，在bookstore app的Book模型的增加/編輯表單的視圖(第6章的例子)按下面的順序尋找模板:
admin/bookstore/book/change_form.html
admin/bookstore/change_form.html
admin/change_form.html

定制模型模板
大多數情況下，你想使用上面第一個模板來創(chuàng)建模型專有的模板
通常情況下通過擴展基本模板并在其中的塊定義中添加信息會將這個任務完成的最好
例如我們想在book頁面頂端添加一些幫助內容，可能像下面這樣:
[img][/img]
這很容易做到，創(chuàng)建一個叫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
使用這個自定義的模型模板最常見的用途就是添加自定義的JavaScript到admin頁面，可能是實現一些特殊的小窗口部件
或者是客戶端行為
幸運的是，這再簡單不過了，每個admin模板定義了一個{% block extrahead %}，你可以把使用它來把其它的內容添加
到head元素里去，例如你想在你的一個admin歷史頁面引入jQuery:

{% 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，但是這個例子適用于admin的任何模板
你可以使用這個技術來引入任何其它你可能需要的JavaScript小窗口部件

定制admin視圖
到目前為止那些想添加自定義行為到Django的admin中的人們可能開始困惑了，他們會喊，"你所講述的都是關于怎樣改變
admin的外觀，但是我怎樣改變admin的工作方式呢?"
好了，別喊了，這里就是答案
需要理解的第一件事就是它一點也不神奇，admin做的任何事都不特殊，它只是一些像其它視圖一樣處理數據的視圖罷了
這些視圖在django.contrib.admin.views，當然這里有很多代碼，它必須處理所有的選項，域類型和影響模型行為的設置
同樣的，當你意識到admin只是一些視圖時，添加自定義的admin視圖就變得更容易理解
讓我們添加一個"publisher report"視圖到我們第6章的book app中，我們將構建一個admin視圖來顯示通過publisher
分組的books列表，這是一個非常典型你可能想構建的自定義admin"report"的例子
首先我們在URLconf里面包裝一個視圖，我們需要把這行代碼插入到admin視圖的引入行之前

(r'^admin/bookstore/report/$', 'bookstore.admin_views.report'),

完整的URL配置可能像下面這樣:

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    (r'^admin/bookstore/report/$', 'bookstore.admin_views.report'),
    (r'^admin/', include('django.contrib.admin.urls')),
)

為什么把自定義視圖放在admin引入之前?回想一下Django處理URL模式的順序，因為admin的引入URL匹配幾乎所有的東西
如果我們把上面的兩行URL配置代碼調換順序，Django將會查找一個內建的視圖來匹配這個URL，這將不能工作
在這種特殊情況下，Django將試圖載入bookstore app的Report模型的更改列表，這是不存在的
現在讓我們來寫我們的視圖，為了簡單起見，我們只是載入所有的books在context里并讓模板使用{% regroup %}標簽處理
分組，用下面的代碼創(chuàng)建一個bookstore/admin_views.py文件:

from bookstore.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

@staff_member_required
def report(request):
    return render_to_response(
        "admin/bookstore/report.html",
        {'book_list' : Book.objects.all()},
        RequestContext(request, {}),
    )

因為我們把分組留給模板來做，這個視圖非常簡單，盡管如此，這里有一些細小的東西值得解釋:
1，我們使用django.contrib.admin.views.decorators的staff_member_required裝飾器，它類似于第12章討論的
login_required裝飾器，但是這個還檢查給定的用戶是否標記為"staff"成員來決定是否允許訪問admin
這個裝飾器保護所有內建的admin視圖，讓你的視圖的認證邏輯和admin的其它部分匹配
2，我們渲染在admin/下面的模板，雖然這沒有嚴格的要求，但是保持你所有的admin模板分組在一個admin目錄下
被認為是最佳實踐，我們把模板放在我們的app后面叫bookstore的目錄下也是最佳實踐
3，我們使用RequestContext作為第3個參數(context_instance)傳遞給render_to_response
這保證了關于當前用戶的信息可以在模板里得到，參看第10章得到更多關于RequestContext的信息
最后我們將為這個視圖創(chuàng)建一個模板，我們繼承內建的admin模板來使這個視圖視覺上看起來是admin的一部分:

{% 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的admin的外觀，它看起來像這樣:
[img][/img]

今天你需要在哪里使用admin?
你可以使用這個技術來向admin添加任何你想到的東西，記住所謂的"定制admin視圖"事實上只是普通的Django視圖
你可以使用你在本書其它部分所學的所有技術來構建任意復雜的admin視圖
我們將以一些自定義admin視圖的一些好注意結束本章內容

覆蓋內建的視圖
默認的admin視圖不包含這些，你可以很輕松的在admin的任何地方跳轉到你的自定義視圖，只需讓你的URL覆蓋掉內建的那些
例如，我們可以用一個簡單的讓用戶輸入ISBN的表單替代內建的book創(chuàng)建視圖，然后我們就可以從http://isbn.nu/來查詢
book信息和自動創(chuàng)建對象
這個視圖的代碼留給讀者做練習，最重要的部分是下面的URL配置:

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

如果這段代碼在你的URL配置中放在admin的URL前面的話，add_by_isbn視圖將完全替代標準的admin視圖
我們可以遵循類似的動作來替代刪除確認頁面，編輯頁面或者admin的任何其它部分

安徽新華電腦學校專業(yè)職業(yè)規(guī)劃師為你提供更多幫助【在線咨詢】