對于某一類網站，?_管理界面_?是基礎設施中非常重要的一部分。 這是以網頁和有限的可信任管理者為基礎的界面，它可以讓你添加，編輯和刪除網站內容。 一些常見的例子： 你可以用這個界面發布博客，后臺的網站管理者用它來潤色讀者提交的內容，你的客戶用你給他們建立的界面工具更新新聞并發布在網站上，這些都是使用管理界面的例子。 但是管理界面有一問題： 創建它太繁瑣。 當你開發對公眾的功能時，網頁開發是有趣的，但是創建管理界面通常是千篇一律的。 你必須認證用戶，顯示并管理表格，驗證輸入的有效性諸如此類。 這很繁瑣而且是重復勞動。 Django 在對這些繁瑣和重復的工作進行了哪些改進？ 它用不能再少的代碼為你做了所有的一切。 Django 中創建管理界面已經不是問題。 這一章是關于 Django 的自動管理界面。 這個特性是這樣起作用的： 它讀取你模式中的元數據，然后提供給你一個強大而且可以使用的界面，網站管理者可以用它立即工作。 請注意我們建議你讀這章，即使你不打算用admin。因為我們將介紹一些概念，這些概念可以應用到Django的所有方面，而不僅僅是admin ## django.contrib 包 Django自動管理工具是django.contrib的一部分。django.contrib是一套龐大的功能集，它是Django基本代碼的組成部分，Django框架就是由眾多包含附加組件(add-on)的基本代碼構成的。 你可以把django.contrib看作是可選的Python標準庫或普遍模式的實際實現。 它們與Django捆綁在一起，這樣你在開發中就不用“重復發明輪子”了。 管理工具是本書講述django.contrib的第一個部分。從技術層面上講，它被稱作django.contrib.admin。django.contrib中其它可用的特性，如用戶鑒別系統(django.contrib.auth)、支持匿名會話(django.contrib.sessioins)以及用戶評注系統(django.contrib.comments)。這些，我們將在第十六章詳細討論。在成為一個Django專家以前，你將會知道更多django.contrib的特性。 目前，你只需要知道Django自帶很多優秀的附加組件，它們都存在于django.contrib包里。 ## 激活管理界面 Django管理站點完全是可選擇的，因為僅僅某些特殊類型的站點才需要這些功能。 這意味著你需要在你的項目中花費幾個步驟去激活它。 第一步，對你的settings文件做如下這些改變： 1. 將'django.contrib.admin'加入setting的INSTALLED_APPS配置中 （INSTALLED_APPS中的配置順序是沒有關系的, 但是我們喜歡保持一定順序以方便人來閱讀） 1. 保證INSTALLED_APPS中包含'django.contrib.auth'，'django.contrib.contenttypes'和'django.contrib.sessions'，Django的管理工具需要這3個包。 (如果你跟隨本文制作mysite項目的話，那么請注意我們在第五章的時候把這三項INSTALLED_APPS條目注釋了。現在，請把注釋取消。) 1. 確保MIDDLEWARE_CLASSES?包含'django.middleware.common.CommonMiddleware'、'django.contrib.sessions.middleware.SessionMiddleware'和'django.contrib.auth.middleware.AuthenticationMiddleware'?。(再次提醒，如果有跟著做mysite的話，請把在第五章做的注釋取消。) 運行?python?manage.py?syncdb?。這一步將生成管理界面使用的額外數據庫表。 當你把'django.contrib.auth'加進INSTALLED_APPS后，第一次運行syncdb命令時, 系統會請你創建一個超級用戶。 如果你不這么作，你需要運行python?manage.py?createsuperuser來另外創建一個admin的用戶帳號，否則你將不能登入admin (提醒一句: 只有當INSTALLED_APPS包含'django.contrib.auth'時，python?manage.py?createsuperuser這個命令才可用.) 第三，將admin訪問配置在URLconf(記住，在urls.py中). 默認情況下，命令django-admin.py?startproject生成的文件urls.py是將Django admin的路徑注釋掉的，你所要做的就是取消注釋。 請注意，以下內容是必須確保存在的： ~~~ # Include these import statements... from django.contrib import admin admin.autodiscover() # And include this URLpattern... urlpatterns = patterns('', # ... (r'^admin/', include(admin.site.urls)), # ... ) ~~~ 當這一切都配置好后，現在你將發現Django管理工具可以運行了。 啟動開發服務器(如前：`` python manage.py runserver`` )，然后在瀏覽器中訪問： ~~~ http://127.0.0.1:8000/admin/ ~~~ ## 使用管理工具。 管理界面的設計是針對非技術人員的，所以它應該是自我解釋的。 盡管如此，這里簡單介紹一下它的基本特性。 你看到的第一件事是如圖6-1所示的登錄屏幕。  圖 6-1\. Django的登錄截圖 你要使用你原來設置的超級用戶的用戶名和密碼。 如果無法登錄，請運行`` python manage.py createsuperuser`` ，確保你已經創建了一個超級用戶。 一旦登錄了，你將看到管理頁面。 這個頁面列出了管理工具中可編輯的所有數據類型。 現在，由于我們還沒有創建任何模塊，所以這個列表只有寥寥數條類目： 它僅有兩個默認的管理-編輯模塊：用戶組(Groups)和用戶(Users)。  圖 6-2。 Django admin的首頁 在Django管理頁面中，每一種數據類型都有一個*change list* 和*edit form* 。前者顯示數據庫中所有的可用對象；后者可讓你添加、更改和刪除數據庫中的某條記錄。 其它語言 如果你的母語不是英語，而你不想用它來配置你的瀏覽器，你可以做一個快速更改來觀察Django管理工具是否被翻譯成你想要的語言。 僅需添加`` ‘django.middleware.locale.LocaleMiddleware’`` 到`` MIDDLEWARE_CLASSES`` 設置中，并確保它在’django.contrib.sessions.middleware.SessionMiddleware’*之后* 。 （見上） 完成后，請刷新頁面。 如果你設置的語言可用，一系列的鏈接文字將被顯示成這種語言。這些文字包括頁面頂端的Change password和Log out，頁面中部的Groups和Users。 Django自帶了多種語言的翻譯。 關于Django更多的國際化特性，請參見第十九章。 點擊Uers行中的Change鏈接，引導用戶更改列表。  圖 6-3\. 典型的改變列表視圖 （見上） 這個頁面顯示了數據庫中所有的用戶。你可以將它看作是一個漂亮的網頁版查詢：`` SELECT * FROM auth_user;`` 如果你一直跟著作練習，并且只添加了一個用戶，你會在這個頁面中看到一個用戶。但是如果你添加了多個用戶，你會發現頁面中還有過濾器、排序和查詢框。 過濾器在右邊；排序功能可通過點擊列頭查看；查詢框在頁面頂部，它允許你通過用戶名查詢。 點擊其中一個用戶名，你會看見關于這個用戶的編輯窗口。  圖 6-4\. 典型的編輯表格 （見上） 這個頁面允許你修改用戶的屬性，如姓名和權限。 （如果要更改用戶密碼，你必須點擊密碼字段下的change password form，而不是直接更改字段值中的哈西碼。）另外需要注意的是，不同類型的字段會用不同的窗口控件顯示。例如，日期/時間型用日歷控件，布爾型用復選框，字符型用簡單文本框顯示。 你可以通過點擊編輯頁面下方的刪除按鈕來刪除一條記錄。 你會見到一個確認頁面。有時候，它會顯示有哪些關聯的對象將會一并被刪除。 （例如，如果你要刪除一個出版社，它下面所有的圖書也將被刪除。） 你可以通過點擊管理主頁面中某個對象的Add來添加一條新記錄。 一個空白記錄的頁面將被打開，等待你填充。 你還能看到管理界面也控制著你輸入的有效性。 你可以試試不填必需的欄目或者在時間欄里填錯誤的時間，你會發現當你要保存時會出現錯誤信息，如圖6-5所示。  圖6-5\. 編輯表格顯示錯誤信息 （見上） 當你編輯已有的對像時，你在窗口的右上角可以看到一個歷史按鈕。 通過管理界面做的每一個改變都留有記錄，你可以按歷史鍵來檢查這個記錄（見圖6-6）。  圖6-6\. Django 對像歷史頁面 （見上） ## 將你的Models加入到Admin管理中 有一個關鍵步驟我們還沒做。 讓我們將自己的模塊加入管理工具中，這樣我們就能夠通過這個漂亮的界面添加、修改和刪除數據庫中的對象了。 我們將繼續第五章中的`` book`` 例子。在其中，我們定義了三個模塊：Publisher?、?Author?和?Book?。 在`` books`` 目錄下(`` mysite/books`` )，創建一個文件：`` admin.py`` ，然后輸入以下代碼： ~~~ from django.contrib import admin from mysite.books.models import Publisher, Author, Book admin.site.register(Publisher) admin.site.register(Author) admin.site.register(Book) ~~~ 這些代碼通知管理工具為這些模塊逐一提供界面。 完成后，打開頁面 ``?http://127.0.0.1:8000/admin/`` ，你會看到一個Books區域，其中包含Authors、Books和Publishers。? （你可能需要先停止，然后再啟動服務(`` runserver`` )，才能使其生效。） 現在你擁有一個功能完整的管理界面來管理這三個模塊了。 很簡單吧！ 花點時間添加和修改記錄，以填充數據庫。 如果你跟著第五章的例子一起創建Publisher對象的話（并且沒有刪除），你會在列表中看到那些記錄。 這里需要提到的一個特性是，管理工具處理外鍵和多對多關系（這兩種關系可以在`` Book`` 模塊中找到）的方法。 作為提醒，這里有個`` Book`` 模塊的例子： ~~~ class Book(models.Model): title = models.CharField(max_length=100) authors = models.ManyToManyField(Author) publisher = models.ForeignKey(Publisher) publication_date = models.DateField() def __unicode__(self): return self.title ~~~ 在Add book頁面中（``?http://127.0.0.1:8000/admin/books/book/add/`` ），`` 外鍵`` publisher用一個選擇框顯示，`` 多對多`` 字段author用一個多選框顯示。 點擊兩個字段后面的綠色加號，可以讓你添加相關的記錄。 舉個例子，如果你點擊Publisher后面的加號，你將會得到一個彈出窗口來添加一個publisher。 當你在那個窗口中成功創建了一個publisher后，Add book表單會自動把它更新到字段上去 花巧. ## Admin是如何工作的 在幕后，管理工具是如何工作的呢？ 其實很簡單。 當服務啟動時，Django從`` url.py`` 引導URLconf，然后執行`` admin.autodiscover()`` 語句。 這個函數遍歷INSTALLED_APPS配置，并且尋找相關的?admin.py文件。 如果在指定的app目錄下找到admin.py，它就執行其中的代碼。 在`` books`` 應用程序目錄下的`` admin.py`` 文件中，每次調用`` admin.site.register()`` 都將那個模塊注冊到管理工具中。 管理工具只為那些明確注冊了的模塊顯示一個編輯/修改的界面。 應用程序`` django.contrib.auth`` 包含自身的`` admin.py`` ，所以Users和Groups能在管理工具中自動顯示。 其它的django.contrib應用程序，如django.contrib.redirects，其它從網上下在的第三方Django應用程序一樣，都會自行添加到管理工具。 綜上所述，管理工具其實就是一個Django應用程序，包含自己的模塊、模板、視圖和URLpatterns。 你要像添加自己的視圖一樣，把它添加到URLconf里面。 你可以在Django基本代碼中的django/contrib/admin?目錄下，檢查它的模板、視圖和URLpatterns，但你不要嘗試直接修改其中的任何代碼，因為里面有很多地方可以讓你自定義管理工具的工作方式。 （如果你確實想瀏覽Django管理工具的代碼，請謹記它在讀取關于模塊的元數據過程中做了些不簡單的工作，因此最好花些時間閱讀和理解那些代碼。） ## 設置字段可選 在擺弄了一會之后，你或許會發現管理工具有個限制：編輯表單需要你填寫每一個字段，然而在有些情況下，你想要某些字段是可選的。 舉個例子，我們想要Author模塊中的email字段成為可選，即允許不填。 在現實世界中，你可能沒有為每個作者登記郵箱地址。 為了指定email字段為可選，你只要編輯Book模塊（回想第五章，它在mysite/books/models.py文件里），在email字段上加上blank=True。代碼如下： ~~~ class Author(models.Model): first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=40) email = models.EmailField(blank=True ) ~~~ 這些代碼告訴Django，作者的郵箱地址允許輸入一個空值。 所有字段都默認blank=False，這使得它們不允許輸入空值。 這里會發生一些有趣的事情。 直到現在，除了__unicode__()方法，我們的模塊充當數據庫中表定義的角色，即本質上是用Python的語法來寫CREATE?TABLE語句。 在添加blank=True過程中，我們已經開始在簡單的定義數據表上擴展我們的模塊了。 現在，我們的模塊類開始成為一個富含Author對象屬性和行為的集合了。?email不但展現為一個數據庫中的VARCHAR類型的字段，它還是頁面中可選的字段，就像在管理工具中看到的那樣。 當你添加blank=True以后，刷新頁面Add author edit form (http://127.0.0.1:8000/admin/books/author/add/?)，將會發現Email的標簽不再是粗體了。 這意味它不是一個必填字段。 現在你可以添加一個作者而不必輸入郵箱地址，即使你為這個字段提交了一個空值，也再不會得到那刺眼的紅色信息“This field is required”。 ### 設置日期型和數字型字段可選 雖然blank=True同樣適用于日期型和數字型字段，但是這里需要詳細講解一些背景知識。 SQL有指定空值的獨特方式，它把空值叫做NULL。NULL可以表示為未知的、非法的、或其它程序指定的含義。 在SQL中，?NULL的值不同于空字符串，就像Python中None不同于空字符串（""）一樣。這意味著某個字符型字段（如VARCHAR）的值不可能同時包含NULL和空字符串。 這會引起不必要的歧義或疑惑。 為什么這條記錄有個NULL，而那條記錄卻有個空字符串？ 它們之間有區別，還是數據輸入不一致？ 還有： 我怎樣才能得到全部擁有空值的記錄，應該按NULL和空字符串查找么？還是僅按字符串查找？ 為了消除歧義，Django生成CREATE?TABLE語句自動為每個字段顯式加上NOT?NULL。 這里有個第五章中生成Author模塊的例子： ~~~ CREATE TABLE "books_author" ( "id" serial NOT NULL PRIMARY KEY, "first_name" varchar(30) NOT NULL, "last_name" varchar(40) NOT NULL, "email" varchar(75) NOT NULL ) ; ~~~ 在大多數情況下，這種默認的行為對你的應用程序來說是最佳的，因為它可以使你不再因數據一致性而頭痛。 而且它可以和Django的其它部分工作得很好。如在管理工具中，如果你留空一個字符型字段，它會為此插入一個空字符串（而*不是*NULL）。 但是，其它數據類型有例外：日期型、時間型和數字型字段不接受空字符串。 如果你嘗試將一個空字符串插入日期型或整數型字段，你可能會得到數據庫返回的錯誤，這取決于那個數據庫的類型。 （PostgreSQL比較嚴禁，會拋出一個異常；MySQL可能會也可能不會接受，這取決于你使用的版本和運氣了。）在這種情況下，NULL是唯一指定空值的方法。 在Django模塊中，你可以通過添加null=True來指定一個字段允許為NULL。 因此，這說起來有點復雜： 如果你想允許一個日期型（DateField、TimeField、DateTimeField）或數字型（IntegerField、DecimalField、FloatField）字段為空，你需要使用null=True?*和*?blank=True。 為了舉例說明，讓我們把Book模塊修改成允許?publication_date為空。修改后的代碼如下： ~~~ class Book(models.Model): title = models.CharField(max_length=100) authors = models.ManyToManyField(Author) publisher = models.ForeignKey(Publisher) publication_date = models.DateField(blank=True, null=True ) ~~~ 添加null=True比添加blank=True復雜。因為null=True改變了數據的語義，即改變了CREATE?TABLE語句，把publication_date字段上的NOT?NULL刪除了。 要完成這些改動，我們還需要更新數據庫。 出于某種原因，Django不會嘗試自動更新數據庫結構。所以你必須執行ALTER?TABLE語句將模塊的改動更新至數據庫。 像先前那樣，你可以使用manage.py?dbshell進入數據庫服務環境。 以下是在這個特殊情況下如何刪除NOT?NULL: ~~~ ALTER TABLE books_book ALTER COLUMN publication_date DROP NOT NULL; ~~~ （注意：以下SQL語法是PostgreSQL特有的。） 我們將在第十章詳細講述數據庫結構更改。 現在讓我們回到管理工具，添加book的編輯頁面允許輸入一個空的publication date。 ## 自定義字段標簽 在編輯頁面中，每個字段的標簽都是從模塊的字段名稱生成的。 規則很簡單： 用空格替換下劃線；首字母大寫。例如：Book模塊中publication_date的標簽是Publication date。 然而，字段名稱并不總是貼切的。有些情況下，你可能想自定義一個標簽。 你只需在模塊中指定verbose_name。 舉個例子，說明如何將Author.email的標簽改為e-mail，中間有個橫線。 ~~~ class Author(models.Model): first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=40) email = models.EmailField(blank=True, verbose_name='e-mail' ) ~~~ 修改后重啟服務器，你會在author編輯頁面中看到這個新標簽。 請注意，你不必把verbose_name的首字母大寫，除非是連續大寫（如："USA?state"）。Django會自動適時將首字母大寫，并且在其它不需要大寫的地方使用verbose_name的精確值。 最后還需注意的是，為了使語法簡潔，你可以把它當作固定位置的參數傳遞。 這個例子與上面那個的效果相同。 ~~~ class Author(models.Model): first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=40) email = models.EmailField('e-mail', blank=True) ~~~ 但這不適用于ManyToManyField?和ForeignKey字段，因為它們第一個參數必須是模塊類。 那種情形，必須顯式使用verbose_name這個參數名稱。 ## 自定義ModelAdmi類 迄今為止，我們做的blank=True、null=True和verbose_name修改其實是模塊級別，而不是管理級別的。 也就是說，這些修改實質上是構成模塊的一部分，并且正好被管理工具使用，而不是專門針對管理工具的。 除了這些，Django還提供了大量選項讓你針對特別的模塊自定義管理工具。 這些選項都在_ModelAdmin classes_里面，這些類包含了管理工具中針對特別模塊的配置。 ### 自定義列表 讓我們更深一步：自定義Author模塊的列表中的顯示字段。 列表默認地顯示查詢結果中對象的__unicode__()。 在第五章中，我們定義Author對象的__unicode__()方法，用以同時顯示作者的姓和名。 ~~~ class Author(models.Model): first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=40) email = models.EmailField(blank=True, verbose_name='e-mail') def __unicode__(self): return u'%s %s' % (self.first_name, self.last_name) ~~~ 結果正如圖6-7所示，列表中顯示的是每個作者的姓名。  圖 6-7\. 作者列表 我們可以在這基礎上改進，添加其它字段，從而改變列表的顯示。 這個頁面應該提供便利，比如說：在這個列表中可以看到作者的郵箱地址。如果能按照姓氏或名字來排序，那就更好了。 為了達到這個目的，我們將為Author模塊定義一個ModelAdmin類。 這個類是自定義管理工具的關鍵，其中最基本的一件事情是允許你指定列表中的字段。 打開admin.py并修改： ~~~ from django.contrib import admin from mysite.books.models import Publisher, Author, Book class AuthorAdmin(admin.ModelAdmin): list_display = ('first_name', 'last_name', 'email') admin.site.register(Publisher) admin.site.register(Author, AuthorAdmin) admin.site.register(Book) ~~~ 解釋一下代碼： > 我們新建了一個類AuthorAdmin，它是從django.contrib.admin.ModelAdmin派生出來的子類，保存著一個類的自定義配置，以供管理工具使用。 我們只自定義了一項：list_display， 它是一個字段名稱的元組，用于列表顯示。 當然，這些字段名稱必須是模塊中有的。 > > 我們修改了admin.site.register()調用，在Author后面添加了AuthorAdmin。你可以這樣理解： 用AuthorAdmin選項注冊Author模塊。 > > admin.site.register()函數接受一個ModelAdmin子類作為第二個參數。 如果你忽略第二個參數，Django將使用默認的選項。Publisher和Book的注冊就屬于這種情況。 弄好了這個東東，再刷新author列表頁面，你會看到列表中有三列：姓氏、名字和郵箱地址。 另外，點擊每個列的列頭可以對那列進行排序。 （參見圖 6-8）  圖 6-8\. 修改后的author列表頁面 接下來，讓我們添加一個快速查詢欄。 向AuthorAdmin追加search_fields，如： ~~~ class AuthorAdmin(admin.ModelAdmin): list_display = ('first_name', 'last_name', 'email') search_fields = ('first_name', 'last_name') ~~~ 刷新瀏覽器，你會在頁面頂端看到一個查詢欄。 （見圖6-9.）我們剛才所作的修改列表頁面，添加了一個根據姓名查詢的查詢框。 正如用戶所希望的那樣，它是大小寫敏感，并且對兩個字段檢索的查詢框。如果查詢"bar"，那么名字中含有Barney和姓氏中含有Hobarson的作者記錄將被檢索出來。  圖 6-9\. 含search_fields的author列表頁面 接下來，讓我們為Book列表頁添加一些過濾器。 ~~~ from django.contrib import admin from mysite.books.models import Publisher, Author, Book class AuthorAdmin(admin.ModelAdmin): list_display = ('first_name', 'last_name', 'email') search_fields = ('first_name', 'last_name') class BookAdmin(admin.ModelAdmin): list_display = ('title', 'publisher', 'publication_date') list_filter = ('publication_date',) admin.site.register(Publisher) admin.site.register(Author, AuthorAdmin) admin.site.register(Book, BookAdmin) ~~~ 由于我們要處理一系列選項，因此我們創建了一個單獨的ModelAdmin類：BookAdmin。首先，我們定義一個list_display，以使得頁面好看些。 然后，我們用list_filter這個字段元組創建過濾器，它位于列表頁面的右邊。 Django為日期型字段提供了快捷過濾方式，它包含：今天、過往七天、當月和今年。這些是開發人員經常用到的。 圖 6-10顯示了修改后的頁面。  圖 6-10\. 含過濾器的book列表頁面 `` 過濾器`` 同樣適用于其它類型的字段，而不單是`` 日期型`` （請在`` 布爾型`` 和`` 外鍵`` 字段上試試）。當有兩個以上值時，過濾器就會顯示。 另外一種過濾日期的方式是使用date_hierarchy選項，如： ~~~ class BookAdmin(admin.ModelAdmin): list_display = ('title', 'publisher', 'publication_date') list_filter = ('publication_date',) date_hierarchy = 'publication_date' ~~~ 修改好后，頁面中的列表頂端會有一個逐層深入的導航條，效果如圖 6-11\. 它從可用的年份開始，然后逐層細分到月乃至日。  圖 6-11\. 含date_hierarchy的book列表頁面 請注意，date_hierarchy接受的是*字符串* ，而不是元組。因為只能對一個日期型字段進行層次劃分。 最后，讓我們改變默認的排序方式，按publication date降序排列。 列表頁面默認按照模塊class?Meta（詳見第五章）中的ordering所指的列排序。但目前沒有指定ordering值，所以當前排序是沒有定義的。 ~~~ class BookAdmin(admin.ModelAdmin): list_display = ('title', 'publisher', 'publication_date') list_filter = ('publication_date',) date_hierarchy = 'publication_date' ordering = ('-publication_date',) ~~~ 這個ordering選項基本像模塊中class?Meta的ordering那樣工作，除了它只用列表中的第一個字段名。 如果要實現降序，僅需在傳入的列表或元組的字段前加上一個減號(-)。 刷新book列表頁面觀看實際效果。 注意Publication date列頭現在有一個小箭頭顯示排序。 （見圖 6-12.）  圖 6-12 含排序的book列表頁面 我們已經學習了主要的選項。 通過使用它們，你可以僅需幾行代碼就能創建一個功能強大、隨時上線的數據編輯界面。 ### 自定義編輯表單 正如自定義列表那樣，編輯表單多方面也能自定義。 首先，我們先自定義字段順序。 默認地，表單中的字段順序是與模塊中定義是一致的。 我們可以通過使用ModelAdmin子類中的fields選項來改變它： ~~~ class BookAdmin(admin.ModelAdmin): list_display = ('title', 'publisher', 'publication_date') list_filter = ('publication_date',) date_hierarchy = 'publication_date' ordering = ('-publication_date',) fields = ('title', 'authors', 'publisher', 'publication_date') ~~~ 完成之后，編輯表單將按照指定的順序顯示各字段。 它看起來自然多了——作者排在書名之后。 字段順序當然是與數據條目錄入順序有關， 每個表單都不一樣。 通過fields這個選項，你可以排除一些不想被其他人編輯的fields 只要不選上不想被編輯的field(s)即可。 當你的admi用戶只是被信任可以更改你的某一部分數據時，或者，你的數據被一些外部的程序自動處理而改變了了，你就可以用這個功能。 例如，在book數據庫中，我們可以隱藏publication_date，以防止它被編輯。 ~~~ class BookAdmin(admin.ModelAdmin): list_display = ('title', 'publisher', 'publication_date') list_filter = ('publication_date',) date_hierarchy = 'publication_date' ordering = ('-publication_date',) fields = ('title', 'authors', 'publisher') ~~~ 這樣，在編輯頁面就無法對publication date進行改動。 如果你是一個編輯，不希望作者推遲出版日期的話，這個功能就很有用。 （當然，這純粹是一個假設的例子。） 當一個用戶用這個不包含完整信息的表單添加一本新書時，Django會簡單地將publication_date設置為None，以確保這個字段滿足null=True的條件。 另一個常用的編輯頁面自定義是針對多對多字段的。 真如我們在book編輯頁面看到的那樣，`` 多對多字段`` 被展現成多選框。雖然多選框在邏輯上是最適合的HTML控件，但它卻不那么好用。 如果你想選擇多項，你必須還要按下Ctrl鍵（蘋果機是command鍵）。 雖然管理工具因此添加了注釋（help_text），但是當它有幾百個選項時，它依然顯得笨拙。 更好的辦法是使用filter_horizontal。讓我們把它添加到BookAdmin中，然后看看它的效果。 ~~~ class BookAdmin(admin.ModelAdmin): list_display = ('title', 'publisher', 'publication_date') list_filter = ('publication_date',) date_hierarchy = 'publication_date' ordering = ('-publication_date',) filter_horizontal = ('authors',) ~~~ （如果你一著跟著做練習，請注意移除fields選項，以使得編輯頁面包含所有字段。） 刷新book編輯頁面，你會看到Author區中有一個精巧的JavaScript過濾器，它允許你檢索選項，然后將選中的authors從Available框移到Chosen框，還可以移回來。  圖 6-13\. 含filter_horizontal的book編輯頁面 我們強烈建議針對那些擁有十個以上選項的`` 多對多字段`` 使用filter_horizontal。 這比多選框好用多了。 你可以在多個字段上使用filter_horizontal，只需在這個元組中指定每個字段的名字。 ModelAdmin類還支持filter_vertical選項。 它像filter_horizontal那樣工作，除了控件都是垂直排列，而不是水平排列的。 至于使用哪個，只是個人喜好問題。 filter_horizontal和filter_vertical選項只能用在多對多字段?上, 而不能用于?ForeignKey字段。 默認地，管理工具使用`` 下拉框`` 來展現`` 外鍵`` 字段。但是，正如`` 多對多字段`` 那樣，有時候你不想忍受因裝載并顯示這些選項而產生的大量開銷。 例如，我們的book數據庫膨脹到擁有數千條publishers的記錄，以致于book的添加頁面裝載時間較久，因為它必須把每一個publishe都裝載并顯示在`` 下拉框`` 中。 解決這個問題的辦法是使用`` raw_id_fields`` 選項。它是一個包含外鍵字段名稱的元組，它包含的字段將被展現成`` 文本框`` ，而不再是`` 下拉框`` 。見圖 6-14。 ~~~ class BookAdmin(admin.ModelAdmin): list_display = ('title', 'publisher', 'publication_date') list_filter = ('publication_date',) date_hierarchy = 'publication_date' ordering = ('-publication_date',) filter_horizontal = ('authors',) raw_id_fields = ('publisher',) ~~~  圖 6-14\. 含raw_id_fields的book編輯頁面 在這個輸入框中，你輸入什么呢？ publisher的數據庫ID號。 考慮到人們通常不會記住這些數據庫ID，管理工具提供了一個放大鏡圖標方便你輸入。點擊那個圖標將會彈出一個窗口，在那里你可以選擇想要添加的publishe。 ## 用戶、用戶組和權限 因為你是用超級用戶登錄的，你可以創建，編輯和刪除任何對像。 然而，不同的環境要求有不同的權限，系統不允許所有人都是超級用戶。 管理工具有一個用戶權限系統，通過它你可以根據用戶的需要來指定他們的權限，從而達到部分訪問系統的目的。 用戶帳號應該是通用的、獨立于管理界面以外仍可以使用。但我們現在把它看作是管理界面的一部分。 在第十四章，我們將講述如何把用戶帳號與你的網站（不僅僅是管理工具）集成在一起。 你通過管理界面編輯用戶及其許可就像你編輯別的對象一樣。 我們在本章的前面，瀏覽用戶和用戶組區域的時候已經見過這些了。 如你所想，用戶對象有標準的用戶名、密碼、郵箱地址和真實姓名，同時它還有關于使用管理界面的權限定義。 首先，這有一組三個布爾型標記： * 活動標志，它用來控制用戶是否已經激活。 如果一個用戶帳號的這個標記是關閉狀態，而用戶又嘗試用它登錄時，即使密碼正確，他也無法登錄系統。 * 成員標志，它用來控制這個用戶是否可以登錄管理界面（即：這個用戶是不是你們組織里的成員） 由于用戶系統可以被用于控制公眾頁面（即：非管理頁面）的訪問權限（詳見第十四章），這個標志可用來區分公眾用戶和管理用戶。 * 超級用戶標志，它賦予用戶在管理界面中添加、修改和刪除任何項目的權限。 如果一個用戶帳號有這個標志，那么所有權限設置（即使沒有）都會被忽略。 普通的活躍，非超級用戶的管理用戶可以根據一套設定好的許可進入。 管理界面中每種可編輯的對象（如：books、authors、publishers）都有三種權限：?_創建_?許可，?_編輯_?許可和?_刪除_?許可。 給一個用戶授權許可也就表明該用戶可以進行許可描述的操作。 當你創建一個用戶時，它沒有任何權限，該有什么權限是由你決定的。 例如，你可以給一個用戶添加和修改publishers的權限，而不給他刪除的權限。 請注意，這些權限是定義在模塊級別上，而不是對象級別上的。據個例子，你可以讓小強修改任何圖書，但是不能讓他僅修改由機械工業出版社出版的圖書。 后面這種基于對象級別的權限設置比較復雜，并且超出了本書的覆蓋范圍，但你可以在Django documentation中尋找答案。 注釋 權限管理系統也控制編輯用戶和權限。 如果你給某人編輯用戶的權限，他可以編輯自己的權限，這種能力可能不是你希望的。 賦予一個用戶修改用戶的權限，本質上說就是把他變成一個超級用戶。 你也可以給組中分配用戶。 一個?_組_?簡化了給組中所有成員應用一套許可的動作。 組在給大量用戶特定權限的時候很有用。 ## 何時、為什么使用管理界面？何時又不使用呢？ 經過這一章的學習，你應該對Django管理工具有所認識。 但是我們需要表明一個觀點：*什么時候* 、*為什么* 用，以及什么時候又*不* 用。 Django的管理界面對非技術用戶要輸入他們的數據時特別有用；事實上這個特性就是專門為這個 實現的。 在Django最開始開發的新聞報道的行業應用中，有一個典型的在線自來水的水質專題報道 應用，它的實現流程是這樣的： * 負責這個報道的記者和要處理數據的開發者碰頭，提供一些數據給開發者。 * 開發者圍繞這些數據設計模型然后配置一個管理界面給記者。 * 記者檢查管理界面，盡早指出缺少或多余的字段。 開發者來回地修改模塊。 * 當模塊認可后，記者就開始用管理界面輸入數據。 同時，程序員可以專注于開發公眾訪問視圖和模板（有趣的部分）。 換句話說，Django的管理界面為內容輸入人員和編程人員都提供了便利的工具。 當然，除了數據輸入方面，我們發現管理界面在下面這些情景中也是很有用的： * *檢查模塊* ：當你定義好了若干個模塊，在管理頁面中把他們調出來然后輸入一些虛假的數據，這是相當有用的。 有時候，它能顯示數據建模的錯誤或者模塊中其它問題。 * *管理既得數據* ：如果你的應用程序依賴外部數據（來自用戶輸入或網絡爬蟲），管理界面提供了一個便捷的途徑，讓你檢查和編輯那些數據。 你可以把它看作是一個功能不那么強大，但是很方便的數據庫命令行工具。 * *臨時的數據管理程序* ：你可以用管理工具建立自己的輕量級數據管理程序，比如說開銷記錄。 如果你正在根據自己的，而不是公眾的需要開發些什么，那么管理界面可以帶給你很大的幫助。 從這個意義上講，你可以把它看作是一個增強的關系型電子表格。 最后一點要澄清的是： 管理界面不是終結者。 過往許多年間，我們看到它被拆分、修改成若干個功能模塊，而這些功能不是它所支持的。 它不應成為一個*公眾* 數據訪問接口，也不應允許對你的數據進行復雜的排序和查詢。 正如本章開頭所說，它僅提供給可信任的管理員。 請記住這一點，它是有效使用管理界面的鑰匙。 ## 下一章 到現在，我們已經創建了一些模塊，并且為編輯數據配置了一個優秀的界面。 下一章，我們將轉入到網站開發中最重要的部分： 表單的創建和處理。