Django速成：構建一個Blog

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE Django速成：構建一個Blog

      Django自稱是“最適合開發有限期的完美Web框架”。所以現在我們來挑戰一下，看看到底能在多短的時間裡用Django完成一個簡單的blog。（關於追求完美的部分我們稍後再細說。）

注意

本章假設你已經安裝了Django。如果還沒有的話，請參見附錄B。

本章所有工作都是在你選擇的shell（bash、tcsh、zsh和Cygwin等）下以命令列方式完成。所以，首先開啟終端，鍵入cd命令進入你PYTHONPATH環境變數所指向的目錄。在Linux、Mac OS X、FreeBSD等類UNIX的系統上，你可以用echo $PYTHONPATH命令來檢視其內容。在Win32的命令列視窗裡，則可以輸入echo %PYTHONPATH%。你可以在第1章裡讀到更多關於路徑和安裝的內容。

我們建議你在閱讀的同時實際動手構建這個blog。如果做不到（例如不在電腦旁邊，或者沒這個耐性）的話，簡單讀一下本章也是好的。特別是如果你有其他現代Web框架開發的經驗就更好了，因為很多基本的概念都是相似的。

如果你確實打算在電腦上實際操作，同時遇到和你在這裡看到的結果不同的情況時，請停下來重新檢驗剛才的步驟，然後複查之前的兩到三步。看看是不是有哪些看上去不重要的地方，或是哪些不能理解的步驟被遺漏掉了。如果還是沒發現哪裡不對，那就刪掉整個專案重新來過。作者在學習Django時就用過這個辦法；這樣比無助地盯著錯誤資訊看上幾個小時要有效率，而且重複那些會導致錯誤的步驟還能幫你加深印象！

2.1   建立專案

組織Django程式碼最簡單的方式是使用Django的“專案”（project）：一個包含了組成單個網站的所有檔案的目錄。Django提供了一個叫django-admin.py的命令來幫助建立這樣專案的目錄。在UNIX上，它的預設安裝路徑為/usr/bin；在Win32上，它的位置是Python安裝目錄下的Scripts資料夾，比如C:\Python25\Scripts。無論是哪一個平臺，你都要保證django-admin.py在PATH環境變數裡以保證它可以從命令列執行。

為blog專案建立一個專案目錄的django-admin.py命令是：

在Windows上，你需要先開啟一個DOS命令視窗。可以透過【開始→程式→附件→命令提示符】來啟動這個視窗。另外，你會看到C:\WINDOWS\system32這樣的提示符，而不是$符號。

現在我們來看看這個命令為你建立的目錄裡有點什麼內容。在UNIX上它看起來是這樣的：

如果你是在Win32平臺上進行開發，那麼開啟資源管理器視窗你可以看到圖2.1這樣的資料夾，這裡我們所建立的目錄是C:\py\django，專案的內容將會存放在這裡。

圖2.1   Win32上的mysite資料夾

注意

如果你精通Python的話，你一定知道__init__.py會把這個專案目錄變成一個Python的包（package）—相關Python模組的一個集合。這讓我們可以用Python的“點記號”（dot-notation）來指定專案中的某個部分，比如mysite.urls。（你可以閱讀第1章，以獲取更多關於包的內容。）

除了__init__.py，startproject命令還建立了以下三個檔案：

?manage.py檔案是一個同這個Django專案一起工作的工具。你可以從它在目錄列表中的許可權裡看到它是可以執行的。我們馬上就會用到它。

?settings.py檔案包含了專案的預設設定。包括資料庫資訊、除錯標誌以及其他一些重要的變數。你專案裡安裝的任何應用都可以訪問這個檔案。稍後在本章進行過程中我們會展示其更多的作用。

?urls.py檔案在Django裡叫URLconf，它是一個將URL模式對映到你應用程式上的配置檔案。URLconf是Django裡非常強大的一個特性。

注意

startproject命令建立的所有檔案都是Python的原始碼檔案。這裡沒有XML、.ini檔案，或是任何時髦的配置語法。Django追求的是儘可能地保持“純Python”這一理念。這讓你在擁有諸多靈活性的同時無需在框架裡引入任何複雜性。例如，如果你想讓你的settings檔案從其他檔案匯入設定，或是計算一個值而避免硬編碼的話都可以暢行無阻—因為它就是Python而已。

2.2   執行開發伺服器

到這裡，你還沒有構建完blog應用，不過Django為你提供了一些可以就地使用的方便。其中最好用的就是Django的內建Web伺服器了。這個伺服器不是用來部署公共站點，而是用來做快速開發的。其優點在於：

?不需要安裝Apache、Lighttpd，或是其他任何實際生產所需的Web伺服器軟體—如果你在一臺新的伺服器或是沒有伺服器環境的開發機上，或是就想實驗一下的話，那就非常方便了。

?它會自動檢測到你對Python原始碼的修改並且重新載入那些模組。相比每次修改程式碼後都要手動地重啟Web伺服器可是大大地節約了不少時間，這對絕大多數Python的Web伺服器設定來說都是很有必要的。

?它知道如何為admin應用程式尋找並顯示靜態的媒體檔案，所以你就可以直接使用它。

執行開發伺服器（或“dev”）簡單到只需要一個命令就行了。這裡我們要用到專案裡的manage.py工具，這是一個簡單的包裹指令碼，能直接告訴django-admin.py去讀入專案特定的settings檔案。啟動dev的命令如下：

在Win32平臺你應該能看到類似如下的輸出，只是要退出時要按下的快捷鍵是Ctrl+Break而不是Ctrl+C。

在瀏覽器裡輸入這個連結，你會看到Django的“It worked!”頁面，如圖2.2所示。

 

同時，如果你檢視終端的話，你會看到dev伺服器記錄下了你的GET請求。

log從左到右有4個部分：時間戳、請求、HTTP狀態碼，以及位元組數。（你看到的位元組數或許會有所不同。）這裡狀態碼404（“Not Found”）是因為還沒有為專案定義任何URL。而“It worked!”頁面只是Django委婉地告訴你這一點的方式。

提示

如果伺服器不工作的話，請重新檢查每一個步驟。不要怕麻煩！有時候直接刪掉整個專案，然後重新開始可能反而比勞心勞力地檢查每一個檔案，每一行程式碼要來的簡單。

如果你成功啟動伺服器後，我們就可以來設定你的第一個Django應用了。

2.3   建立Blog應用

有了專案以後，就可以在它下面建立應用（按Django的說法是“app”）了。我們再次使用manage.py來建立這個blog app。

這樣就完成專案的建立了。現在我們在專案的目錄下有了一個blog目錄。這是它的內容，首先是UNIX下的，接著是Windows資源管理器裡的截圖（圖2.3）。

圖2.3   Win32上的mysite\blog資料夾

和專案一樣，app也是一個包。現在models.py和views.py裡還沒有真正的程式碼，它們只是先佔住位子而已。實際上對我們這個簡單的blog來說，我們根本用不著views.py檔案。

要告訴Django這個app是專案裡的一部分，你需要去編輯settings.py檔案（也稱之為“配置檔案”）。開啟配置檔案並在檔案尾部找到INSTALLED_APPS元組。把你的app以模組的形式新增到元組裡，就像這樣（注意結尾的逗號）：

Django用INSTALLED_APPS來決定系統裡不同部分的配置，包括自動化的admin應用以及測試框架。

2.4   設計你的Model

現在我們來到了這個基於Django的blog應用的核心部分：models.py檔案。這是我們定義blog資料結構的地方。根據DRY原則，Django會盡量利用你提供給應用程式的model資訊。我們先來建立一個基本的model，看看Django用這個資訊為我們做了點什麼。

用你最習慣的編輯器（如果它能支援Python模式就最好）開啟models.py檔案。你會看到這樣的佔位文字：

刪掉註釋，加入下列程式碼：

這是一個完整的model，代表了一個有3個變數的“BlogPost”物件。（嚴格說來應該有4個，Django會預設為每個model自動加上一個自增的、唯一的id變數。）

這個新建的BlogPost類是django.db.models.Model的一個子類。這是Django為資料model準備的標準基類，它是Django強大的物件關係對映（ORM）系統的核心。此外，每一個變數都和普通的類屬性一樣被定義為一個特定變數類（field class）的例項。這些變數類也是在django.db.models裡定義，它們的種類非常多，從BooleanField到XMLField應有盡有，可不止這裡看到的區區三個。

2.5   設定資料庫

如果你沒有安裝執行資料庫伺服器的話，我們推薦使用SQLite，這是最快最簡單的辦法。它的速度很快，被廣泛接受，並且將它的資料庫作為一個檔案存放在檔案系統上。訪問控制就是簡單的檔案許可權。更多關於在Django裡使用資料庫的資訊請參閱附錄B。

如果你安裝了資料庫伺服器（PostgreSQL、MySQL、Oracle和MSSQL），並且希望用它們而非SQLite的話，你需要用相應的資料庫管理工具為Django專案建立一個新的資料庫。在這裡我們把資料庫取名為“djangodb”，不過你可以選用任何喜歡的名字。

當你有了一個（空的）資料庫以後，接下來只需要告訴Django如何使用它即可。這就需要用到專案的settings.py檔案。

使用資料庫伺服器

很多人都選用PostgreSQL或MySQL這樣的關聯式資料庫和Django配合使用。這裡有6個相關的設定（雖然你可能只要兩個就夠了）：DATABASE_ENGINE、DATABASE_NAME、DATABASE_HOST、DATABASE_PORT、DATABASE_USER和DATABASE_PASSWORD。它們的作用從名字上就能看的出來。你只需在相應的位置填入正確的值就可以了。例如，為MySQL的設定看上去是這樣的：

注意

我們沒有指定DATABASE_PORT是因為只有當你的資料庫伺服器執行在非標準的埠上時才需要那麼做。比如，MySQL伺服器的預設埠為3306。除非你修改了這個設定，否則根本不用指定DATABASE_PORT。

要知道建立新資料庫和（資料庫伺服器要求的）資料庫使用者的細節，請參閱附錄B。

使用SQLite

SQLite非常適合測試，甚至可以部署在沒有大量併發寫入的情況下。因為SQLite使用本地檔案系統作為儲存介質並且用原生的檔案系統許可權來做訪問控制，像主機、埠、使用者或密碼這種資訊一律統統不需要。因此Django只要知道以下的兩個設定就能使用你的SQLite資料庫了。

注意

當SQLite配合Apache這樣真正的Web伺服器一起使用時，你需要確認擁有Web伺服器程式的賬號也擁有對資料庫檔案以及包含資料庫檔案目錄的寫許可權。在我們這裡用dev伺服器做開發的情況下，這通常不是一個問題，因為執行dev伺服器的使用者（你）同時也擁有專案的檔案和目錄。

SQLite在Win32平臺上也是非常受歡迎的選擇之一，因為它是隨同Python一同免費釋出的。假設我們已經為專案（和應用程式）建立了C:\py\django目錄，現在再來建立一個db目錄。

如果你不太熟悉Python的話，你會注意到這個例子和前一個例子的不同之處，之前我們在sqlite3上用的是雙引號，而在Win32的版本里，我們用的是單引號。這個和平臺是沒有關係的—Python沒有字元型別，所以單引號和雙引號都是被等同對待。只要保證你用同樣的引號引用字串就可以了！

你還應該注意到了資料夾名字前的小寫“r”。如果你沒有讀過第一章，那麼你應該知道它的意思是這個物件是一個raw字串，或者說它把字串裡所有字元都逐字保留下來，不對任何特殊字元組合做轉義。例如，\n通常代表一個新行，但是在raw字串裡，它（字面上）代表了兩個字元：一個反斜槓和一個小寫n。所以raw字串的作用（特別是對這裡的DOS檔案路徑來說）就是告訴Python不要轉義任何特殊字元（如果有的話）。

建立表

現在你可以告訴Django用你提供的連線資訊去連線資料庫並且設定應用程式所需的表。命令很簡單：

在Django設定資料庫的過程中你會看到類似這樣的輸出：

當你執行syncdb命令時，Django會查詢INSTALLED_APPS裡的每一個models.py檔案，併為找到的每一個model都建立一張資料庫表。（在稍後我們碰到華麗的多對多關係時會有例外，但是對這個例子來說是正確的。如果你用的是SQLite，你還可以看到django.db資料庫會在你指定的位置上被建立出來。）

INSTALLED_APPS裡的其他預設條目也都擁有model。manage.py syncdb的輸出就確認了這一點，你可以看到Django為每個app都建立了一個或多個表。

但這還不是syncdb命令輸出的全部。你還會被問到一些和django.contrib.auth app有關的問題。

現在你在auth系統裡建立了一個超級使用者（就是你自己）。這在等一會我們加入Django的自動admin應用時就會變得很方便。

最後，這一過程還包裹了一些和特性fixture有關的程式碼，在第4章裡我們在討論這個。這讓你在一個新建立的應用裡預先載入資料。我們在這裡沒有用到這個特性，所以Django會跳過它。

到此資料庫的初始化就完成了，下次你再對這個專案執行syncdb命令（只要你新增了應用或是model時就要執行）時，就不會再看到那麼多輸出了，因為它不需要再次設定表或者提示你建立超級使用者了。

2.6   設定自動admin應用

自動化的後臺應用程式admin稱得上是Django“皇冠上的明珠”。任何對為Web應用建立簡單的“CRUD”（Create，Read，Update，Delete）介面感到厭倦的人來說，這絕對是喜從天降。我們會在第11.1節裡深入討論admin。現在我們只要拿來直接用就好了。

由於這不是Django的必要元件，你必須在settings.py檔案裡指定你要使用它—就和指定blog app一樣。開啟settings.py並在INSTALLED_APPS元組裡的'django.contrib.auth'下面新增這樣一行。

每次往專案裡新增新的應用後，你都要執行一下syncdb命令確保它所需的表已經在資料庫裡建立了。在這裡可以看到在INSTALLED_APPS裡新增admin app並執行syncdb命令會往我們的資料庫里加入一個新的表：

設定完app以後，我們需要為它指定一個URL這樣才能訪問它。你應該已經注意到了在自動生成的urls.py中的這樣兩行程式碼。

刪掉第二行開頭的#號（也可以同時刪掉第一行）並儲存檔案。這樣你就告訴Django去載入預設的admin站點，這是被用於contrib admin應用程式的一個特殊物件。

最後，你的應用程式需要告訴Django要在admin視窗裡顯示哪一個model以供編輯。要做到這一點很簡單，只要定義之前提到的預設admin站點，並向其註冊BlogPost model就行了。開啟mysite/blog/models.py檔案，確認匯入了admin應用，然後在最後加上一行註冊model的程式碼。

這裡admin的簡單使用只不過是冰山一角，它還可以透過為給定model建立一個特殊的Admin類來指定許多不同和admin有關的選項，然後向那個類註冊model。這個我們稍後再說，在後面的章節裡你還會看到admin的高階使用，特別是本書第三部分和第四部分。

2.7   試用admin

到這裡我們已經在Django裡設定了admin app並向其註冊了model，現在是時候試一試它了。再次執行manage.py runserver命令，隨後在瀏覽器裡輸入。（你的dev伺服器可能不是這個地址，沒關係，只要在後面加上admin/就可以了。）你應該會看到一個登入視窗，如圖2.4所示。

輸入你之前建立的“超級使用者”名字和密碼。登入後，你就可以看到admin的主頁了，如圖2.5所示。

圖2.4   admin登入頁面

圖2.5   admin主頁

本書稍後會解釋這個介面，現在只需確認你的應用程式Blog和截圖裡一樣出現在螢幕上。如果沒有的話，請重新檢查之前的步驟。

提示

三個最常見的“我的app沒有顯示在admin裡”的原因是：

1）忘記向admin.site.register註冊你的model類；

2）models.py裡有錯誤；以及

3）忘記在settings.py中的INSTALLED_ APPS裡新增app。

有沒有內容的blog麼？點選Blog Posts右側的Add按鈕。Admin會顯示一個表單讓你新增新的帖子，如圖2.6所示。

圖2.6   透過admin新增新內容

給你的帖子取一個名字然後往裡填一點內容。至於時間戳，你可以點選Today和Now的快捷連結來獲取當前的日期和時間。你還可以點選日曆或時鐘標誌來方便地選擇時間。

完成之後，點選Save按鈕儲存。你會收到一條確認訊息（“The blog post 'BlogPost object' was added successfully.”）和一個列出你所有blog帖子的列表—目前只有一篇而已，如圖2.7所示。

為什麼帖子有“BlogPost object”這麼難看的名字？Django的設計是希望能靈活地處理任意型別的內容，所以它不會去猜測對於給定的內容什麼變數才是最合適的。在第三部分的例子裡，你會看到如何為你物件的預設標籤指定一個特定變數，或是特別定製的字串。

現在點選右上角的“Add Blog Post +”按鈕新增另一篇不同內容的帖子。當你回到列表檢視裡，你會看見頁面上加入了另一個BlogPost。如果你重新整理頁面或是離開應用程式再回來的話，輸出不會有任何變化—你一定不會喜歡看見所有條目都被標為“BlogPost object”，如圖2.8所示。你不是第一個這麼想的人，“總有辦法讓它看起來順眼一點吧。”

圖2.7   成功地儲存你的第一篇blog

圖2.8   不太有用的小節頁面

不過我們不需要等到那個時候來清理admin檢視裡的這些列表顯示。之前我們透過很少的配置就啟用了admin工具，即向admin app註冊我們的model。現在只要額外的兩行程式碼以及對註冊呼叫的一些修改，我們就可以讓列表看起來更漂亮更有用。更新你的mysite/blog/models. py檔案，新增一個BlogPostAdmin類，並將它加到註冊程式碼那一行裡，於是現在models.py看起來是這樣的：

開發伺服器會注意到你的修改並自動重新載入model檔案。如果你去看一下命令列shell，就能看到這些效果。

重新整理一下頁面，現在你就可以看到一個更有意義的頁面了，它是根據你新增到BlogPostAdmin類裡list_display變數來生成輸出的，如圖2.9所示。

圖2.9   這樣就好多了

試著點一下Title和Timestamp列的標題—每一個都影響了你的條目是如何排序的。例如，點一下Title會按照升序排列標題，再點一下則變成降序排列。

Admin還有很多有用的特性只需一到兩行程式碼就可以啟用：搜尋、自定義排序、過濾等。就像我們多次提到的，在本書第三和第四部分裡會更詳細地展示這些內容。

2.8   建立Blog的公共部分

完成我們應用的資料庫部分和admin部分後，現在來看看面向公眾的頁面部分。從Django的角度來說，一個頁面具有三個典型的元件：

?一個模板（template），模板負責將傳遞進來的資訊顯示出來（用一種類似Python字典的物件Context）。

?一個檢視（view）函式，它負責獲取要顯示的資訊，通常都是從資料庫裡取得。

?一個URL模式，它用來把收到的請求和你的檢視函式匹配，有時也會向檢視傳遞一些引數。

建立模板

Django的模板語言相當簡單，我們直接來看程式碼。這是一個簡單的顯示單個blog帖子的模板：

它就是一個HTML（雖然Django模板可以用於任何形式的輸出）加上一些大括號裡的特殊模板標籤。這些是變數標籤（variable tag），用於顯示傳遞給模板的資料。在變數標籤裡，你可以用Python風格的dotted-notation（點記號）來訪問傳遞給模板的物件的屬性。例如，這裡假設你傳遞了一個叫“post”的BlogPost物件。這三行模板程式碼分別從BlogPost物件的title、timestamp和body變數裡獲取了相應的值。

現在我們稍微改進一下這個模板，透過Django的for模板標籤讓它能顯示多篇blog帖子。

原來的3行沒有動，我們只是簡單地增加了一個叫做for的塊標籤（block tag），用它將模板渲染到序列中的每個元素上。其語法和Python的迴圈語法是一致的。注意和變數標籤不同，塊標籤是包含在{% ... %}裡的。

把這5行模板程式碼儲存到檔案archive.html裡，然後把檔案放到你的blog app目錄裡的templates目錄下。這個檔案的路徑即為：

模板本身的名字是隨意取的（叫它foo.html也沒問題），但是templates目錄的名字則是強制的。Django在預設情況下會在搜尋模板時逐個檢視你安裝的應用程式下的每一個templates目錄。

建立一個檢視函式

現在我們來編寫一個從資料庫讀取所有blog帖子的檢視函式，並用我們的模板將它們顯示出來。開啟blog/views.py檔案並輸入：

先略過import那幾行（它們載入了我們需要的函式和類），我們來逐行解釋一下這個檢視函式。

第5行：每個Django檢視函式都將django.http.HttpRequest物件作為它的第一個引數。它還可以透過URLconf接受其他引數，你將來會大量用到這個特性。

第6行：當我們把BlogPost類作為django.db.model.Model的一個子類時，我們就獲得了Django物件關係對映的全部力量。這一行只是使用ORM（物件關係對映，詳見第3章和第4章）的一件簡單例子，獲取資料庫裡所有BlogPost物件。

第7行：這裡我們只需告訴Django模板的名字就能建立模板物件t。因為我們把它儲存在app下的templates目錄裡，Django無需更多指示就能找到它。

第8行：Django模板渲染的資料是由一個字典類的物件context提供的，這裡的context c只有一對鍵和值。

第9行：每個Django檢視函式都會返回一個django.http.HttpResponse物件。最簡單的就是給其建構函式傳遞一個字串。這裡模板的render方法返回的正是一個字串。

建立一個URL模式

我們的頁面還差一步就可以工作了—和任何網頁一樣，它還需要一個URL。

當然我們可以直接在mysite/urls.py裡建立所需的URL模式，但是那樣做只會在專案和app之間製造混亂的耦合。Blog app還可以用在別的地方，所以最好是它能為自己的URL負責。這需要兩個簡單的步驟。

第一步和啟用admin很相似。在mysite/urls.py裡有一行被註釋的示例幾乎就是我們需要的程式碼。把它改成這樣：

這會捕捉任何以blog/開始的請求，並把它們傳遞給一個你馬上要新建的URLconf。

第二步是在blog應用程式包裡定義URL。建立一個包含如下內容的新檔案，mysite/blog/ urls.py：

它看起來和基本的URLconf很像。其中的關鍵是第5行，注意URL請求裡和根URLconf匹配的blog/已經被去掉了—這樣blog應用程式就變得可以重用了，它不用關心自己是被掛接到blog/下，或是news/下，還是what/i/had/for/lunch/下。第5行裡的正規表示式可以匹配任何URL，比如/blog/。

檢視函式archive是在模式元組第二部分裡提供的。（注意我們傳遞的不是函式的名字，而是一個first-class的函式物件。當然用字串也行，你在後面會看到。）

現在來看看效果吧！開發伺服器還在執行中麼？如果沒有，執行manage.py runserver來啟動它，然後在瀏覽器裡輸入http://127.0.0.1:8000/blog/。你可以看到一個簡單樸素的頁面，顯示了所有你輸入的blog帖子，有標題、釋出時間和帖子本身。

 

2.9   最後的潤色

你有好幾種方式來繼續改進這個基本的blog引擎。我們來討論幾個關鍵的概念，把這個專案弄得再漂亮一點。

模板的精確定位

毫不誇張地說，我們的模板實在是太平庸了。畢竟這是一本關於Web程式設計而不是Web設計的書，美術方面的東西你就自己處理吧，但是模板繼承是模板系統裡另一個能讓你減少工作量的特性，特別是當你的頁面風格快速成長的時候。

我們這個模板現在是自給自足的。但是如果我們的站點有一個blog、一個相簿和一個連結頁面，並且我們希望所有這些都能基於同一個基礎風格的話該怎麼辦？經驗告訴我們要是用複製貼上的辦法做出三個幾乎完全一樣的模板肯定是不行的。在Django里正確的做法是建立一個基礎模板，然後在這之上擴充套件出其他特定模板來。在mysite/blog/templates目錄裡，建立一個叫做base.html的模板，其內容如下：

     雖然不是完全符合XHTML Strict標準，不過差不多就行了。這裡要注意的細節是{% block ... %}標籤。它定義了一個子模板可以修改的命名塊（named block）。修改archive.html模板，讓它引用新的基礎模板和它的“content”塊，就能在blog app裡使用它了。

這裡的{% extends ... %}標籤告訴Django去查詢一個叫base.html的標籤，並將這個模板裡命名塊的所有內容填入到那個模板裡相應的塊裡去。現在你應該可以看到類似圖2.10的頁面了（當然了，你的blog內容比我這個應該更加精彩）。

圖2.10   稍微帶點風格的blog

按日期排序

你應該已經注意到blog的帖子不是按照傳統的時間倒序排列的。告訴Django這麼做非常簡單。實際上，有好幾種做法可供選擇。我們可以在model里加入一個預設的順序，或者在檢視程式碼裡的BlogPost.objects().all()上新增排序功能。在這裡修改model會比較好，因為基本上帖子都是按時間倒序排列的。如果在model裡設定我們想要的排序方式，Django裡任何訪問資料的部分都會採用這個排序結果。

設定model預設排序的方法是給它定一個Meta巢狀類，然後設定ordering屬性。

現在看一下blog的首頁（/blog/）。最新的帖子應該出現在頁面最上方了。字串“-timestamp”能簡潔地通知Django，“對‘timestamp’變數按照降序排列”。（如果省略“-”的話則是按升序排列。）

注意

千萬不要忘了小括號裡結尾的那個逗號！它代表這是一個單元素的元組，而不是一個帶小括號的字串。Django在這裡要的是一個元組，你可以排序任意數目的變數。如果你在逗號後面加上'title'，並且你有兩個相同釋出時間的帖子“A”和“B”的話，“A”就會出現在前面。

透過模板過濾器格式化時間戳

雖然時間戳很好用，但是它的ISO8601格式卻有點怪異。我們現在用Django模板系統裡另一個很酷的特性：過濾器（filter）來把它弄得人性化一點。

由於這是一個表示層的（presentation）細節而非資料結構或是商業邏輯的細節，最適合它的位置應該是模板。開啟archive.html檔案並修改“post.timestamp”一行。

只需像這樣用一個豎槓，或“管道”符號接在變數名後面（大括號內部）就能把過濾器應用於變數之上了。重新整理blog首頁。現在你可以看到日期的顯示更加友好了（“July 7”）。

如果date過濾器的預設風格你也不喜歡的話，你可以傳遞一個strftime風格的格式化串作為它的引數。不過這裡它用的不是Python裡time模組的轉換程式碼，而是PHP的date函式的格式化說明。例如，如果你要顯示星期幾，但是不要顯示年份的話，程式碼就變成下面這個樣子了：

這個格式化字串會返回“Friday，July 6th”風格的日期。注意這裡不要在冒號兩邊留有空格—Django的模板引擎對空格敏感。

2.10   總結

我們可以給這個blog引擎不停地加入新特性（很多人就是這麼幹的！），但是作為體驗Django能力的話，希望你已經看的差不多了。在構建這個基本的blog app過程中你已經看到了好幾個Django優雅、簡潔的特性：

?內建的Web伺服器能讓開發工作自給自足，同時它能在程式碼被修改時自動重新載入你的程式碼。

?資料模型的建立採用純Python方式完成，你不用編寫維護任何SQL程式碼或XML描述檔案。

?自動化的admin應用程式，提供了完整的內容編輯特性，甚至非技術背景的使用者也能使用。

?模板系統，可以用來生成HTML、CSS、JavaScript以及任何文字輸出格式。

?模板過濾器，可以在不解除應用程式商業邏輯的前提下修改表示層的資料顯示（比如日期）。

?URLconf系統，在給予你URL設計極大靈活性的同時還能將應用程式特定的URL部分保留在其所屬的應用程式內部。

下面是一些可以透過Django內建的特性就能新增到blog上的功能，這能

讓你有個基本的概念：

?釋出關於最新帖子的Atom或RSS feed（參見第11章）。

?新增一個搜尋功能，讓使用者能迅速定位包含特定詞句的blog帖子（參見第8章裡的CMS例子）。

?用Django的“通用檢視”來避免在views.py裡編寫任何程式碼（參見第10章裡的Pastebin示例）。

到此你已經完成了Django基礎的旋風之旅。第3章會總覽Django中的關鍵元件和它們背後的設計哲學，以及簡要地複述一下Web開發原則，它們不僅是對Django自身，而且也是對書後幾章的經驗教訓總結。第4章將帶你進入框架的細節，你會找到很多之前例子中碰到的關於“怎麼樣，為什麼和什麼是等等？”問題的解答。第4章之後你就會對框架有足夠的理解，可以繼續構建示例應用了：一個內容管理系統（CMS）、一個Pastebin、一個相簿和一個基於Ajax技術的“live blog”。