抽取出我們代碼中共性的東西是一個很好的編程習慣。 比如，像以下的兩個Python函數：
|
1
2
3
4
5
|
def say_hello(person_name): print 'Hello, %s' % person_namedef say_goodbye(person_name): print 'Goodbye, %s' % person_name |
我們可以把問候語提取出來變成一個參數：
|
1
2
|
def greet(person_name, greeting): print '%s, %s' % (greeting, person_name) |
通過使用額外的URLconf參數，你可以把同樣的思想應用到Django的視圖中。
了解這個以后，你可以開始創作高抽象的視圖。 更具體地說，比如這個視圖顯示一系列的 Event 對象，那個視圖顯示一系列的 BlogEntry 對象，并意識到它們都是一個用來顯示一系列對象的視圖的特例，而對象的類型其實就是一個變量。
以這段代碼作為例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
# urls.pyfrom django.conf.urls.defaults import *from mysite import viewsurlpatterns = patterns('', (r'^events/$', views.event_list), (r'^blog/entries/$', views.entry_list),)# views.pyfrom django.shortcuts import render_to_responsefrom mysite.models import Event, BlogEntrydef event_list(request): obj_list = Event.objects.all() return render_to_response('mysite/event_list.html', {'event_list': obj_list})def entry_list(request): obj_list = BlogEntry.objects.all() return render_to_response('mysite/blogentry_list.html', {'entry_list': obj_list}) |
這兩個視圖做的事情實質上是一樣的： 顯示一系列的對象。 讓我們把它們顯示的對象的類型抽象出來：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
# urls.pyfrom django.conf.urls.defaults import *from mysite import models, viewsurlpatterns = patterns('', (r'^events/$', views.object_list, {'model': models.Event}), (r'^blog/entries/$', views.object_list, {'model': models.BlogEntry}),)# views.pyfrom django.shortcuts import render_to_responsedef object_list(request, model): obj_list = model.objects.all() template_name = 'mysite/%s_list.html' % model.__name__.lower() return render_to_response(template_name, {'object_list': obj_list}) |
就這樣小小的改動，我們突然發現我們有了一個可復用的，模型無關的視圖！ 從現在開始，當我們需要一個視圖來顯示一系列的對象時，我們可以簡簡單單的重用這一個 object_list 視圖，而無須另外寫視圖代碼了。 以下是我們做過的事情：
我們通過 model 參數直接傳遞了模型類。 額外URLconf參數的字典是可以傳遞任何類型的對象，而不僅僅只是字符串。
這一行： model.objects.all() 是 鴨子界定 （原文：
我們使用 model.__name__.lower() 來決定模板的名字。 每個Python的類都有一個 __name__ 屬性返回類名。 這特性在當我們直到運行時刻才知道對象類型的這種情況下很有用。 比如， BlogEntry 類的 __name__ 就是字符串 'BlogEntry' 。
這個例子與前面的例子稍有不同，我們傳遞了一個通用的變量名給模板。 當然我們可以輕易的把這個變量名改成 blogentry_list 或者 event_list ，不過我們打算把這當作練習留給讀者。
因為數據庫驅動的網站都有一些通用的模式，Django提供了一個通用視圖的集合，使用它可以節省你的時間。 我們將會在下一章講講Django的內置通用視圖。
提供視圖配置選項
如果你發布一個Django的應用，你的用戶可能會希望配置上能有些自由度。 這種情況下，為你認為用戶可能希望改變的配置選項添加一些鉤子到你的視圖中會是一個很好的主意。 你可以用額外URLconf參數實現。
一個應用中比較常見的可供配置代碼是模板名字：
|
1
2
3
|
def my_view(request, template_name): var = do_something() return render_to_response(template_name, {'var': var}) |
了解捕捉值和額外參數之間的優先級 額外的選項
當沖突出現的時候，額外URLconf參數優先于捕捉值。 也就是說，如果URLconf捕捉到的一個命名組變量和一個額外URLconf參數包含的變量同名時，額外URLconf參數的值會被使用。
例如，下面這個URLconf：
|
1
2
3
4
5
6
|
from django.conf.urls.defaults import *from mysite import viewsurlpatterns = patterns('', (r'^mydata/(?P<id>\d+)/$', views.my_view, {'id': 3}),) |
這里，正則表達式和額外字典都包含了一個 id 。硬編碼的（額外字典的） id 將優先使用。 就是說任何請求（比如， /mydata/2/ 或者 /mydata/432432/ ）都會作 id 設置為 3 對待，不管URL里面能捕捉到什么樣的值。
聰明的讀者會發現在這種情況下，在正則表達式里面寫上捕捉是浪費時間的，因為 id 的值總是會被字典中的值覆蓋。 沒錯，我們說這個的目的只是為了讓你不要犯這樣的錯誤。
