述說正確安裝Python應用程序過程
如果你安裝了Python應用程序，這些功能都是可用的除了標準庫以外，還有許多其他高質量的庫，如wxPython、Twisted和Python圖形庫等等數不勝數，希望大家能夠進行學習研究。
最復雜功能最強大的還是freemarker，支持jsp tag的嵌入讓我們可以重用很多已經存在的組件，這一點我在之前的文章中也有過比較詳細的描述(強強聯手，看freemarker和displaytag的結合)。由于了解，才有發言權，django的模板可以說是為互連網應用而誕生的，簡潔及快速開發的特點讓人情不自禁的喜歡。
關于jsp的題外話，不管是ruby，還是c++，還是Python應用程序，在它們的web框架中都使用了模板，java中也有很多模板。我們最熟悉的是freemarker和velocity。這從一個側面反映出我們web開發中的一個模式，那就是我們的view基本上是基于模板產生的。
而jsp這個東西應該來說是時代的產物，在那個混亂的落后的時代產生的，不過很奇怪的是現在還有這么多人抱著它不放。Django有兩種form，一種是自己定義form class，還有一種是通過我們定義的model自動form class。 由于ahuaxuan只做 了一個信息發布的小例子。
所以并不能全面的了解或者理解django中form的所有細節，不過從我涉及到的部分來講，我對django的從模型創建表單的做法確實感到有比較大的局限性。因為很多時候，model中的數據 并不是從頁面上來的，在這種情況下，form對象被構造出來之后，ahuaxuan還沒有找到修改form中值的方法。
而自定義form類也比較麻煩，就是要寫自己的model，這個和我們之前的做法比較不一樣，這里的form代表我們java中的value object，model是domain object。在我們的ssh框架中我們通常把value object繼承我們的domain object。雖然一堆又一堆的人提出了反對意見，說要把這兩個對象分開。
因為他們處在不同的層次中，但是從實踐經驗中，我們可以看到，這樣做沒有什么不好。而在django中自定義form和model分開的行為可能比較符合一些人的心理。 不過自定義forms也有比較讓人稱道的地方，在form中我們可以自定義驗證規則，同時我們可以根據form對象直接生成頁面中的內容。
不過這一點其實也有比較麻煩的地方，就是如果要改變樣式的時候就比較麻煩。不過總的來說django的form還是比較有特點的，而且一定程度上給我們帶來了方便。 Django的url轉發是基于正則表達式的，有的人叫好，有的人叫差，我就是叫差的那一撥人之一。url轉發應該是一個非常清楚，非常明亮的事情。
可是用上這個正則表達式匹配的東西之后，我郁悶了，所以我只能回到遙遠的過去去繞過這個東東，我不用總可以了吧。從形式上來看，兩者出奇的相似，比如說傳入的參數等。我們知道python是面向對象的語言，但是事實上它也支持函數編程，如果def定義在class內部。
那么就是對象的方法，否則，就可以認為是函數編程了，看看，我們的views里的東西都是函數，views其實是一個模塊，這個模塊我們可以認為是struts1.x中的action，而views中的函數可以認為是action中的方法。它們是遠房親戚。
Python應用程序的admin功能號稱是django的殺手級特性(killer feature)，這一說可以說是恰如其分，毫不夸張的，從我做的這個例子來看，當我做網站的時候，基本上只需要關注前臺頁面的展示這部分。
后臺的功能基本上都自動有了，比如我做的例子是一個二手信息發布平臺，category是二手信息的類型，還有一個information類，和category是多對一的關系，那么在后臺，category和information的crud就自動生產了，由于category本身是一個自關聯，所以在admin中 add category的時候，admin會根據我model的定義。
自動要求選擇一個parentCategory，而在add information的頁面上，admin會要求我選擇一個category來完成對一個information的創建，而以前在java中，這些工作都需要自己完成，當然也有很多工具可以自動生產crud。
不過這些開源的工具基本上都是針對單個model的，而且生成的代碼需要很大修改才能真正的把功能跑起來，最重要的一點是不能自動生成關聯關系的管理。當然我也見過有公司做了基于數據庫驅動的代碼生產器。
能生成完整可用的代碼和頁面，也包括關聯關系的處理，不過由于語言特性的區別，在開發的時候我們還是要不停的重啟server才能顯示出效果來，雖然在技術上，為ssh實現這個功能并不難，但是會消耗不少時間在上面，消耗了很多時間的話，很少就有公司將其貢獻出來了。
所以個人認為django在這個功能上做得還是非常不錯的，尤其這個功能可以節省開發者很多的時間。甚至有些時候，項目可以雙線執行，用戶通過admin輸入數據，程序員開發前臺，這樣，前臺功能做完之后，數據也有了，基本可以測試上線了。在需要快速開發的小項目上，這個特性顯得尤其重要，因為django產生得時候就是基于這個場景。
當然有時候后臺也沒有這么簡單，不過還好，admin提供了擴展的功能，我們可以自己寫擴展的代碼，然后集成到admin中去，不過事實上除了能改變admin的模板，我們不能改變任何admin的代碼。
不過我時常在想，如果admin支持代碼自動生成的功能，那豈不是很美妙，我們可以隨意的修改后臺的功能了，否則我們就需要自己寫代碼，不如在生成的代碼上擴展方便。 要使用admin。
必須打開django的權限模塊，這里簡單介紹一下權限模塊，django自帶了一個權限模塊，這個權限模塊中的model對于熟悉權限這塊的人來說再熟悉不過了，user，group，permission，user和group多對多。
Python應用程序和permission多對多，在acegi中，我們通常這樣定義，user，role，resource，這個和django中的權限是一樣的，不過在django中默認的permission的粒度是非常的粗了，是基于model的，如果我們要更細的權限模塊，那么就需要自己擴展了。
【編輯推薦】
