在第三章，我们已经对基本的Django视图和URL配置做了介绍。 在这一章，将进一步说明框架中这两个部分的高级机能。
## URLconf 技巧
URLconf没什么特别的，就象 Django 中其它东西一样，它们只是 Python 代码。 你可以在几方面从中得到好处，正如下面所描述的。
### 流线型化(Streamlining)函数导入
看下这个 URLconf，它是建立在第三章的例子上:
~~~
from django.conf.urls.defaults import *
from mysite.views import hello, current_datetime, hours_ahead
urlpatterns = patterns('',
(r'^hello/$', hello),
(r'^time/$', current_datetime),
(r'^time/plus/(\d{1,2})/$', hours_ahead),
)
~~~
正如第三章中所解释的，在 URLconf 中的每一个入口包括了它所关联的视图函数，直接传入了一个函数对象。 这就意味着需要在模块开始处导入视图函数。
但随着 Django 应用变得复杂，它的 URLconf 也在增长，并且维护这些导入可能使得管理变麻烦。 (对每个新的view函数，你不得不记住要导入它，并且采用这种方法会使导入语句将变得相当长。)可以通过导入 views 模块本身来避免这个麻烦。 下面例子的URLconf与前一个等价：
~~~
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
(r'^hello/$', views.hello ),
(r'^time/$', views.current_datetime ),
(r'^time/plus/(d{1,2})/$', views.hours_ahead ),
)
~~~
Django 还提供了另一种方法可以在 URLconf 中为某个特别的模式指定视图函数： 你可以传入一个包含模块名和函数名的字符串，而不是函数对象本身。 继续示例:
~~~
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^hello/$', 'mysite.views.hello' ),
(r'^time/$', 'mysite.views.current_datetime' ),
(r'^time/plus/(d{1,2})/$', 'mysite.views.hours_ahead' ),
)
~~~
(注意视图名前后的引号。 应该使用带引号的 'mysite.views.current_datetime' 而不是mysite.views.current_datetime 。)
使用这个技术，就不必导入视图函数了；Django 会在第一次需要它时根据字符串所描述的视图函数的名字和路径，导入合适的视图函数。
当使用字符串技术时，你可以采用更简化的方式：提取出一个公共视图前缀。 在我们的URLconf例子中，每个视图字符串的开始部分都是\，造成重复输入。 我们可以把公共的前缀提取出来，作为第一个参数传给函数：
System Message: WARNING/2 (, line 99); _[backlink](http://docs.30c.org/djangobook2/chapter08/index.html#id2)_
Inline literal start-string without end-string.
~~~
from django.conf.urls.defaults import *
urlpatterns = patterns('mysite.views' ,
(r'^hello/$', 'hello' ),
(r'^time/$', 'current_datetime' ),
(r'^time/plus/(d{1,2})/$', 'hours_ahead' ),
)
~~~
注意既不要在前缀后面跟着一个点号("." )，也不要在视图字符串前面放一个点号。 Django 会自动处理它们。
牢记这两种方法，哪种更好一些呢？ 这取决于你的个人编码习惯和需要。
字符串方法的好处如下:
* 更紧凑，因为不需要你导入视图函数。
* 如果你的视图函数存在于几个不同的 Python 模块的话，它可以使得 URLconf 更易读和管理。
函数对象方法的好处如下:
* 更容易对视图函数进行包装(wrap)。 参见本章后面的《包装视图函数》一节。
* 更 Pythonic，就是说，更符合 Python 的传统，如把函数当成对象传递。
两个方法都是有效的，甚至你可以在同一个 URLconf 中混用它们。 决定权在你。
### 使用多个视图前缀
在实践中，如果你使用字符串技术，特别是当你的 URLconf 中没有一个公共前缀时，你最终可能混合视图。 然而，你仍然可以利用视图前缀的简便方式来减少重复。 只要增加多个 patterns() 对象，象这样:
旧的:
~~~
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^hello/$', 'mysite.views.hello'),
(r'^time/$', 'mysite.views.current_datetime'),
(r'^time/plus/(\d{1,2})/$', 'mysite.views.hours_ahead'),
(r'^tag/(\w+)/$', 'weblog.views.tag'),
)
~~~
新的:
~~~
from django.conf.urls.defaults import *
urlpatterns = patterns('mysite.views',
(r'^hello/$', 'hello'),
(r'^time/$', 'current_datetime'),
(r'^time/plus/(\d{1,2})/$', 'hours_ahead'),
)
urlpatterns += patterns('weblog.views',
(r'^tag/(\w+)/$', 'tag'),
)
~~~
整个框架关注的是存在一个名为 urlpatterns 的模块级别的变量。如上例，这个变量可以动态生成。 这里我们要特别说明一下，patterns()返回的对象是可相加的，这个特性可能是大家没有想到的。
### 调试模式中的特例
说到动态构建 urlpatterns，你可能想利用这一技术，在 Django 的调试模式下修改 URLconf 的行为。 为了做到这一点，只要在运行时检查 DEBUG 配置项的值即可，如:
~~~
from django.conf import settings
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
(r'^$', views.homepage),
(r'^(\d{4})/([a-z]{3})/$', views.archive_month),
)
if settings.DEBUG:
urlpatterns += patterns('',
(r'^debuginfo/$', views.debug),
)
~~~
在这个例子中，URL链接/debuginfo/ 只在你的 DEBUG 配置项设为 True 时才有效。
### 使用命名组
在目前为止的所有 URLconf 例子中，我们使用简单的_无命名_ 正则表达式组，即，在我们想要捕获的URL部分上加上小括号，Django 会将捕获的文本作为位置参数传递给视图函数。 在更高级的用法中，还可以使用 _命名_ 正则表达式组来捕获URL，并且将其作为 _关键字_ 参数传给视图。
关键字参数 对比 位置参数
一个 Python 函数可以使用关键字参数或位置参数来调用，在某些情况下，可以同时进行使用。 在关键字参数调用中，你要指定参数的名字和传入的值。 在位置参数调用中，你只需传入参数，不需要明确指明哪个参数与哪个值对应，它们的对应关系隐含在参数的顺序中。
例如，考虑这个简单的函数:
~~~
def sell(item, price, quantity):
print "Selling %s unit(s) of %s at %s" % (quantity, item, price)
~~~
为了使用位置参数来调用它，你要按照在函数定义中的顺序来指定参数。
~~~
sell('Socks', '$2.50', 6)
~~~
为了使用关键字参数来调用它，你要指定参数名和值。 下面的语句是等价的:
~~~
sell(item='Socks', price='$2.50', quantity=6)
sell(item='Socks', quantity=6, price='$2.50')
sell(price='$2.50', item='Socks', quantity=6)
sell(price='$2.50', quantity=6, item='Socks')
sell(quantity=6, item='Socks', price='$2.50')
sell(quantity=6, price='$2.50', item='Socks')
~~~
最后，你可以混合关键字和位置参数，只要所有的位置参数列在关键字参数之前。 下面的语句与前面的例子是等价:
~~~
sell('Socks', '$2.50', quantity=6)
sell('Socks', price='$2.50', quantity=6)
sell('Socks', quantity=6, price='$2.50')
~~~
在 Python 正则表达式中，命名的正则表达式组的语法是 (?Ppattern) ，这里 name 是组的名字，而pattern 是匹配的某个模式。
下面是一个使用无名组的 URLconf 的例子:
~~~
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
(r'^articles/(\d{4})/$', views.year_archive),
(r'^articles/(\d{4})/(\d{2})/$', views.month_archive),
)
~~~
下面是相同的 URLconf，使用命名组进行了重写:
~~~
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
(r'^articles/(?P<year>\d{4})/$', views.year_archive),
(r'^articles/(?P<year>\d{4})/(?P<month>\d{2})/$', views.month_archive),
)
~~~
这段代码和前面的功能完全一样，只有一个细微的差别： 取的值是以关键字参数的方式而不是以位置参数的方式传递给视图函数的。
例如，如果不带命名组，请求 /articles/2006/03/ 将会等同于这样的函数调用：
~~~
month_archive(request, '2006', '03')
~~~
而带命名组，同样的请求就会变成这样的函数调用：
~~~
month_archive(request, year='2006', month='03')
~~~
使用命名组可以让你的URLconfs更加清晰，减少搞混参数次序的潜在BUG，还可以让你在函数定义中对参数重新排序。 接着上面这个例子，如果我们想修改URL把月份放到 年份的 _前面_ ，而不使用命名组的话，我们就不得不去修改视图 month_archive 的参数次序。 如果我们使用命名组的话，修改URL里提取参数的次序对视图没有影响。
当然，命名组的代价就是失去了简洁性： 一些开发者觉得命名组的语法丑陋和显得冗余。 命名组的另一个好处就是可读性强。
### 理解匹配/分组算法
需要注意的是如果在URLconf中使用命名组，那么命名组和非命名组是不能同时存在于同一个URLconf的模式中的。 如果你这样做，Django不会抛出任何错误，但你可能会发现你的URL并没有像你预想的那样匹配正确。 具体地，以下是URLconf解释器有关正则表达式中命名组和 非命名组所遵循的算法:
* 如果有任何命名的组，Django会忽略非命名组而直接使用命名组。
* 否则，Django会把所有非命名组以位置参数的形式传递。
* 在以上的两种情况，Django同时会以关键字参数的方式传递一些额外参数。 更具体的信息可参考下一节。
### 传递额外的参数到视图函数中
有时你会发现你写的视图函数是十分类似的，只有一点点的不同。 比如说，你有两个视图，它们的内容是一致的，除了它们所用的模板不太一样：
~~~
# urls.py
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
(r'^foo/$', views.foo_view),
(r'^bar/$', views.bar_view),
)
# views.py
from django.shortcuts import render_to_response
from mysite.models import MyModel
def foo_view(request):
m_list = MyModel.objects.filter(is_new=True)
return render_to_response('template1.html', {'m_list': m_list})
def bar_view(request):
m_list = MyModel.objects.filter(is_new=True)
return render_to_response('template2.html', {'m_list': m_list})
~~~
我们在这代码里面做了重复的工作，不够简练。 起初你可能会想，通过对两个URL都使用同样的视图，在URL中使用括号捕捉请求，然后在视图中检查并决定使用哪个模板来去除代码的冗余，就像这样：
~~~
# urls.py
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
(r'^(foo)/$', views.foobar_view),
(r'^(bar)/$', views.foobar_view),
)
# views.py
from django.shortcuts import render_to_response
from mysite.models import MyModel
def foobar_view(request, url):
m_list = MyModel.objects.filter(is_new=True)
if url == 'foo':
template_name = 'template1.html'
elif url == 'bar':
template_name = 'template2.html'
return render_to_response(template_name, {'m_list': m_list})
~~~
这种解决方案的问题还是老缺点，就是把你的URL耦合进你的代码里面了。 如果你打算把 /foo/ 改成 /fooey/的话，那么你就得记住要去改变视图里面的代码。
对一个可选URL配置参数的优雅解决方法： URLconf里面的每一个模式都可以包含第三个数据： 一个关键字参数的字典：
有了这个概念以后，我们就可以把我们现在的例子改写成这样：
~~~
# urls.py
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
(r'^foo/$', views.foobar_view, {'template_name': 'template1.html'}),
(r'^bar/$', views.foobar_view, {'template_name': 'template2.html'}),
)
# views.py
from django.shortcuts import render_to_response
from mysite.models import MyModel
def foobar_view(request, template_name):
m_list = MyModel.objects.filter(is_new=True)
return render_to_response(template_name, {'m_list': m_list})
~~~
如你所见，这个例子中，URLconf指定了 template_name 。 而视图函数会把它当成另一个参数。
这种使用额外的URLconf参数的技术以最小的代价给你提供了向视图函数传递额外信息的一个好方法。 正因如此，这技术已被很多Django的捆绑应用使用，其中以我们将在第11章讨论的通用视图系统最为明显。
下面的几节里面有一些关于你可以怎样把额外URLconf参数技术应用到你自己的工程的建议。
#### 伪造捕捉到的URLconf值
比如说你有匹配某个模式的一堆视图，以及一个并不匹配这个模式但视图逻辑是一样的URL。 这种情况下，你可以通过向同一个视图传递额外URLconf参数来伪造URL值的捕捉。
例如，你可能有一个显示某一个特定日子的某些数据的应用，URL类似这样的：
~~~
/mydata/jan/01/
/mydata/jan/02/
/mydata/jan/03/
# ...
/mydata/dec/30/
/mydata/dec/31/
~~~
这太简单了，你可以在一个URLconf中捕捉这些值，像这样（使用命名组的方法）：
~~~
urlpatterns = patterns('',
(r'^mydata/(?P<month>\w{3})/(?P<day>\d\d)/$', views.my_view),
)
~~~
然后视图函数的原型看起来会是：
~~~
def my_view(request, month, day):
# ....
~~~
这种解决方案很直接，没有用到什么你没见过的技术。 当你想添加另外一个使用 my_view 视图但不包含month和/或者day的URL时，问题就出现了。
比如你可能会想增加这样一个URL， /mydata/birthday/ ， 这个URL等价于 /mydata/jan/06/ 。这时你可以这样利用额外URLconf参数：
~~~
urlpatterns = patterns('',
(r'^mydata/birthday/$', views.my_view, {'month': 'jan', 'day': '06'}),
(r'^mydata/(?P<month>\w{3})/(?P<day>\d\d)/$', views.my_view),
)
~~~
在这里最帅的地方莫过于你根本不用改变你的视图函数。 视图函数只会关心它 _获得_ 了 参数，它不会去管这些参数到底是捕捉回来的还是被额外提供的。month和day
#### 创建一个通用视图
抽取出我们代码中共性的东西是一个很好的编程习惯。 比如，像以下的两个Python函数：
~~~
def say_hello(person_name):
print 'Hello, %s' % person_name
def say_goodbye(person_name):
print 'Goodbye, %s' % person_name
~~~
我们可以把问候语提取出来变成一个参数：
~~~
def greet(person_name, greeting):
print '%s, %s' % (greeting, person_name)
~~~
通过使用额外的URLconf参数，你可以把同样的思想应用到Django的视图中。
了解这个以后，你可以开始创作高抽象的视图。 更具体地说，比如这个视图显示一系列的 Event 对象，那个视图显示一系列的 BlogEntry 对象，并意识到它们都是一个用来显示一系列对象的视图的特例，而对象的类型其实就是一个变量。
以这段代码作为例子：
~~~
# urls.py
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
(r'^events/$', views.event_list),
(r'^blog/entries/$', views.entry_list),
)
# views.py
from django.shortcuts import render_to_response
from mysite.models import Event, BlogEntry
def 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})
~~~
这两个视图做的事情实质上是一样的： 显示一系列的对象。 让我们把它们显示的对象的类型抽象出来：
~~~
# urls.py
from django.conf.urls.defaults import *
from mysite import models, views
urlpatterns = patterns('',
(r'^events/$', views.object_list, {'model': models.Event}),
(r'^blog/entries/$', views.object_list, {'model': models.BlogEntry}),
)
# views.py
from django.shortcuts import render_to_response
def 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参数实现。
一个应用中比较常见的可供配置代码是模板名字：
~~~
def my_view(request, template_name):
var = do_something()
return render_to_response(template_name, {'var': var})
~~~
#### 了解捕捉值和额外参数之间的优先级 额外的选项
当冲突出现的时候，额外URLconf参数优先于捕捉值。 也就是说，如果URLconf捕捉到的一个命名组变量和一个额外URLconf参数包含的变量同名时，额外URLconf参数的值会被使用。
例如，下面这个URLconf：
~~~
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
(r'^mydata/(?P<id>\d+)/$', views.my_view, {'id': 3}),
)
~~~
这里，正则表达式和额外字典都包含了一个 id 。硬编码的（额外字典的） id 将优先使用。 就是说任何请求（比如， /mydata/2/ 或者 /mydata/432432/ ）都会作 id 设置为 3 对待，不管URL里面能捕捉到什么样的值。
聪明的读者会发现在这种情况下，在正则表达式里面写上捕捉是浪费时间的，因为 id 的值总是会被字典中的值覆盖。 没错，我们说这个的目的只是为了让你不要犯这样的错误。
### 使用缺省视图参数
另外一个方便的特性是你可以给一个视图指定默认的参数。 这样，当没有给这个参数赋值的时候将会使用默认的值。
例子：
~~~
# urls.py
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
(r'^blog/$', views.page),
(r'^blog/page(?P<num>\d+)/$', views.page),
)
# views.py
def page(request, num='1'):
# Output the appropriate page of blog entries, according to num.
# ...
~~~
在这里，两个URL表达式都指向了同一个视图 views.page ，但是第一个表达式没有传递任何参数。 如果匹配到了第一个样式， page() 函数将会对参数 num 使用默认值 "1" ，如果第二个表达式匹配成功， page() 函数将使用正则表达式传递过来的num的值。
（注：我们已经注意到设置默认参数值是字符串 `` ‘1’`` ，不是整数`` 1`` 。为了保持一致，因为捕捉给`` num`` 的值总是字符串。
就像前面解释的一样，这种技术与配置选项的联用是很普遍的。 以下这个例子比提供视图配置选项一节中的例子有些许的改进。
~~~
def my_view(request, template_name='mysite/my_view.html'):
var = do_something()
return render_to_response(template_name, {'var': var})
~~~
### 特殊情况下的视图
有时你有一个模式来处理在你的URLconf中的一系列URL，但是有时候需要特别处理其中的某个URL。 在这种情况下，要使用将URLconf中把特殊情况放在首位的线性处理方式 。
比方说，你可以考虑通过下面这个URLpattern所描述的方式来向Django的管理站点添加一个目标页面
~~~
urlpatterns = patterns('',
# ...
('^([^/]+)/([^/]+)/add/$', views.add_stage),
# ...
)
~~~
这将匹配像 /myblog/entries/add/ 和 /auth/groups/add/ 这样的URL 。然而，对于用户对象的添加页面（/auth/user/add/ ）是个特殊情况，因为它不会显示所有的表单域，它显示两个密码域等等。 我们 _可以_ 在视图中特别指出以解决这种情况：
~~~
def add_stage(request, app_label, model_name):
if app_label == 'auth' and model_name == 'user':
# do special-case code
else:
# do normal code
~~~
不过，就如我们多次在这章提到的，这样做并不优雅： 因为它把URL逻辑放在了视图中。 更优雅的解决方法是，我们要利用URLconf从顶向下的解析顺序这个特点：
~~~
urlpatterns = patterns('',
# ...
('^auth/user/add/$', views.user_add_stage),
('^([^/]+)/([^/]+)/add/$', views.add_stage),
# ...
)
~~~
在这种情况下，象 /auth/user/add/ 的请求将会被 user_add_stage 视图处理。 尽管URL也匹配第二种模式，它会先匹配上面的模式。 （这是短路逻辑。）
### 从URL中捕获文本
每个被捕获的参数将被作为纯Python字符串来发送，而不管正则表达式中的格式。 举个例子，在这行URLConf中：
~~~
(r'^articles/(?P<year>\d{4})/$', views.year_archive),
~~~
尽管 \d{4} 将只匹配整数的字符串，但是参数 year 是作为字符串传至 views.year_archive() 的，而不是整型。
当你在写视图代码时记住这点很重要，许多Python内建的方法对于接受的对象的类型很讲究。 许多内置Python函数是挑剔的（这是理所当然的）只接受特定类型的对象。 一个典型的的错误就是用字符串值而不是整数值来创建 datetime.date 对象：
~~~
>>> import datetime
>>> datetime.date('1993', '7', '9')
Traceback (most recent call last):
...
TypeError: an integer is required
>>> datetime.date(1993, 7, 9)
datetime.date(1993, 7, 9)
~~~
回到URLconf和视图处，错误看起来很可能是这样：
~~~
# urls.py
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
(r'^articles/(\d{4})/(\d{2})/(\d{2})/$', views.day_archive),
)
# views.py
import datetime
def day_archive(request, year, month, day):
# The following statement raises a TypeError!
date = datetime.date(year, month, day)
~~~
因此， day_archive() 应该这样写才是正确的：
~~~
def day_archive(request, year, month, day):
date = datetime.date(int(year), int(month), int(day))
~~~
注意，当你传递了一个并不完全包含数字的字符串时， int() 会抛出 ValueError 的异常，不过我们已经避免了这个错误，因为在URLconf的正则表达式中已经确保只有包含数字的字符串才会传到这个视图函数中。
### 决定URLconf搜索的东西
当一个请求进来时，Django试着将请求的URL作为一个普通Python字符串进行URLconf模式匹配（而不是作为一个Unicode字符串）。 这并不包括 GET 或 POST 参数或域名。 它也不包括第一个斜杠，因为每个URL必定有一个斜杠。
例如，在向 http://www.example.com/myapp/ 的请求中，Django将试着去匹配 myapp/ 。在向http://www.example.com/myapp/?page=3 的请求中，Django同样会去匹配 myapp/ 。
在解析URLconf时，请求方法（例如， POST ， GET ， HEAD ）并 _不会_ 被考虑。 换而言之，对于相同的URL的所有请求方法将被导向到相同的函数中。 因此根据请求方法来处理分支是视图函数的责任。
### 视图函数的高级概念
说到关于请求方法的分支，让我们来看一下可以用什么好的方法来实现它。 考虑这个 URLconf/view 设计:
~~~
# urls.py
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
# ...
(r'^somepage/$', views.some_page),
# ...
)
# views.py
from django.http import Http404, HttpResponseRedirect
from django.shortcuts import render_to_response
def some_page(request):
if request.method == 'POST':
do_something_for_post()
return HttpResponseRedirect('/someurl/')
elif request.method == 'GET':
do_something_for_get()
return render_to_response('page.html')
else:
raise Http404()
~~~
在这个示例中，`some_page()` 视图函数对`POST` 和` GET` 这两种请求方法的处理完全不同。 它们唯一的共同点是共享一个URL地址： ` /somepage/.`正如大家所看到的，在同一个视图函数中对` POST` 和` GET` 进行处理是一种很初级也很粗糙的做法。 一个比较好的设计习惯应该是，用两个分开的视图函数——一个处理` POST` 请求，另一个处理` GET` 请求，然后在相应的地方分别进行调用。
我们可以像这样做：先写一个视图函数然后由它来具体分派其它的视图，在之前或之后可以执行一些我们自定的程序逻辑。 下边的示例展示了这个技术是如何帮我们改进前边那个简单的` some_page()` 视图的：
~~~
# views.py
from django.http import Http404, HttpResponseRedirect
from django.shortcuts import render_to_response
def method_splitter(request, GET=None, POST=None):
if request.method == 'GET' and GET is not None:
return GET(request)
elif request.method == 'POST' and POST is not None:
return POST(request)
raise Http404
def some_page_get(request):
assert request.method == 'GET'
do_something_for_get()
return render_to_response('page.html')
def some_page_post(request):
assert request.method == 'POST'
do_something_for_post()
return HttpResponseRedirect('/someurl/')
# urls.py
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patterns('',
# ...
(r'^somepage/$', views.method_splitter, {'GET': views.some_page_get, 'POST': views.some_page_post}),
# ...
)
~~~
让我们从头看一下代码是如何工作的：
> 我们写了一个新的视图，`` method_splitter()`` ，它根据`` request.method`` 返回的值来调用相应的视图。可以看到它带有两个关键参数，`` GET`` 和`` POST`` ，也许应该是* 视图函数* 。如果`` request.method`` 返回`` GET`` ，那它就会自动调用`` GET`` 视图。 如果`` request.method`` 返回的是`` POST`` ，那它调用的就是`` POST`` 视图。 如果`` request.method`` 返回的是其它值（如：`` HEAD`` ），或者是没有把`` GET`` 或`` POST`` 提交给此函数，那它就会抛出一个`` Http404`` 错误。
>
> 在URLconf中，我们把`` /somepage/`` 指到`` method_splitter()`` 函数，并把视图函数额外需要用到的`` GET`` 和`` POST`` 参数传递给它。
>
> 最终，我们把`` some_page()`` 视图分解到两个视图函数中`` some_page_get()`` 和`` some_page_post()`` 。这比把所有逻辑都挤到一个单一视图的做法要优雅得多。
>
> 注意，在技术上这些视图函数就不用再去检查`` request.method`` 了，因为`` method_splitter()`` 已经替它们做了。 （比如，`` some_page_post()`` 被调用的时候，我们可以确信`` request.method`` 返回的值是`` post`` 。）当然，这样做不止更安全也能更好的将代码文档化，这里我们做了一个假定，就是`` request.method`` 能象我们所期望的那样工作。
现在我们就拥有了一个不错的，可以通用的视图函数了，里边封装着由`` request.method`` 的返回值来分派不同的视图的程序。关于`` method_splitter()`` 就不说什么了，当然，我们可以把它们重用到其它项目中。
然而，当我们做到这一步时，我们仍然可以改进`` method_splitter`` 。从代码我们可以看到，它假设`` Get`` 和`` POST`` 视图除了`` request`` 之外不需要任何其他的参数。那么，假如我们想要使用`` method_splitter`` 与那种会从URL里捕捉字符，或者会接收一些可选参数的视图一起工作时该怎么办呢？
为了实现这个，我们可以使用Python中一个优雅的特性 带星号的可变参数 我们先展示这些例子，接着再进行解释
~~~
def method_splitter(request, *args, **kwargs):
get_view = kwargs.pop('GET', None)
post_view = kwargs.pop('POST', None)
if request.method == 'GET' and get_view is not None:
return get_view(request, *args, **kwargs)
elif request.method == 'POST' and post_view is not None:
return post_view(request, *args, **kwargs)
raise Http404
~~~
这里,我们重构method_splitter(),去掉了GET和POST两个关键字参数,改而支持使用*args和和**kwargs(注意*号) 这是一个Python特性，允许函数接受动态的、可变数量的、参数名只在运行时可知的参数。 如果你在函数定义时,只在参数前面加一个*号,所有传递给函数的参数将会保存为一个元组. 如果你在函数定义时,在参数前面加两个*号,所有传递给函数的关键字参数,将会保存为一个字典
例如，对于这个函数
~~~
def foo(*args, **kwargs):
print "Positional arguments are:"
print args
print "Keyword arguments are:"
print kwargs
~~~
看一下它是怎么工作的
~~~
>>> foo(1, 2, 3)
Positional arguments are:
(1, 2, 3)
Keyword arguments are:
{}
>>> foo(1, 2, name='Adrian', framework='Django')
Positional arguments are:
(1, 2)
Keyword arguments are:
{'framework': 'Django', 'name': 'Adrian'}
~~~
回过头来看，你能发现我们用method_splitter()和*args接受**kwargs函数参数并把它们传递到正确的视图。_any_ 但是在我们这样做之前，我们要调用两次获得参数kwargs.pop()GETPOST，如果它们合法的话。 (我们通过指定pop的缺省值为None,来避免由于一个或者多个关键字缺失带来的KeyError)
### 包装视图函数
我们最终的视图技巧利用了一个高级python技术。 假设你发现自己在各个不同视图里重复了大量代码，就像 这个例子：
~~~
def my_view1(request):
if not request.user.is_authenticated():
return HttpResponseRedirect('/accounts/login/')
# ...
return render_to_response('template1.html')
def my_view2(request):
if not request.user.is_authenticated():
return HttpResponseRedirect('/accounts/login/')
# ...
return render_to_response('template2.html')
def my_view3(request):
if not request.user.is_authenticated():
return HttpResponseRedirect('/accounts/login/')
# ...
return render_to_response('template3.html')
~~~
这里，每一个视图开始都检查request.user是否是已经认证的，是的话，当前用户已经成功登陆站点否则就重定向/accounts/login/ (注意,虽然我们还没有讲到request.user,但是14章将要讲到它.就如你所想像的,request.user描述当前用户是登陆的还是匿名)
如果我们能够丛每个视图里移除那些 重复代，并且只在需要认证的时候指明它们，那就完美了。 我们能够通过使用一个视图包装达到目的。 花点时间来看看这个：
~~~
def requires_login(view):
def new_view(request, *args, **kwargs):
if not request.user.is_authenticated():
return HttpResponseRedirect('/accounts/login/')
return view(request, *args, **kwargs)
return new_view
~~~
函数requires_login,传入一个视图函数view,然后返回一个新的视图函数new_view.这个新的视图函数new_view在函数requires_login内定义 处理request.user.is_authenticated()这个验证,从而决定是否执行原来的view函数
现在,我们可以从views中去掉if not request.user.is_authenticated()验证.我们可以在URLconf中很容易的用requires_login来包装实现.
~~~
from django.conf.urls.defaults import *
from mysite.views import requires_login, my_view1, my_view2, my_view3
urlpatterns = patterns('',
(r'^view1/$', requires_login(my_view1)),
(r'^view2/$', requires_login(my_view2)),
(r'^view3/$', requires_login(my_view3)),
)
~~~
优化后的代码和前面的功能一样,但是减少了代码冗余 现在我们建立了一个漂亮,通用的函数requires_login()来帮助我们修饰所有需要它来验证的视图
## 包含其他URLconf
如果你试图让你的代码用在多个基于Django的站点上，你应该考虑将你的URLconf以包含的方式来处理。
在任何时候，你的URLconf都可以包含其他URLconf模块。 对于根目录是基于一系列URL的站点来说，这是必要的。 例如下面的，URLconf包含了其他URLConf：
~~~
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^weblog/', include('mysite.blog.urls')),
(r'^photos/', include('mysite.photos.urls')),
(r'^about/$', 'mysite.views.about'),
)
~~~
在前面第6章介绍Django的admin模块时我们曾经见过include. admin模块有他自己的URLconf,你仅仅只需要在你自己的代码中加入include就可以了.
这里有个很重要的地方： 例子中的指向 include() 的正则表达式并 _不_ 包含一个 $ （字符串结尾匹配符），但是包含了一个斜杆。 每当Django遇到 include() 时，它将截断匹配的URL，并把剩余的字符串发往包含的URLconf作进一步处理。
继续看这个例子，这里就是被包含的URLconf mysite.blog.urls ：
~~~
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^(\d\d\d\d)/$', 'mysite.blog.views.year_detail'),
(r'^(\d\d\d\d)/(\d\d)/$', 'mysite.blog.views.month_detail'),
)
~~~
通过这两个URLconf，下面是一些处理请求的例子：
* /weblog/2007/ ：在第一个URLconf中，模式 r'^weblog/' 被匹配。 因为它是一个 include() ，Django将截掉所有匹配的文本，在这里是 'weblog/' 。URL剩余的部分是 2007/ ， 将在 mysite.blog.urls 这个URLconf的第一行中被匹配到。 URL仍存在的部分为 2007/ ,与第一行的 mysite.blog.urlsURL设置相匹配。
* /weblog//2007/(包含两个斜杠) 在第一个URLconf中,r’^weblog/’匹配 因为它有一个include(),django去掉了匹配的部,在这个例子中匹配的部分是’weblog/’ 剩下的部分是/2007/ (最前面有一个斜杠),不匹配mysite.blog.urls中的任何一行.
* /about/ : 这个匹配第一个URLconf中的 mysite.views.about 视图。
### 捕获的参数如何和include()协同工作
一个被包含的URLconf接收任何来自parent URLconfs的被捕获的参数，比如:
~~~
# root urls.py
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^(?P<username>\w+)/blog/', include('foo.urls.blog')),
)
# foo/urls/blog.py
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^$', 'foo.views.blog_index'),
(r'^archive/$', 'foo.views.blog_archive'),
)),
)
~~~
在这个例子中，被捕获的 username 变量将传递给被包含的 URLconf，进而传递给那个URLconf中的 _每一个_ 视图函数。
注意，这个被捕获的参数 _总是_ 传递到被包含的URLconf中的 _每一_ 行，不管那些行对应的视图是否需要这些参数。 因此，这个技术只有在你确实需要那个被传递的参数的时候才显得有用。
### 额外的URLconf如何和include()协同工作
相似的，你可以传递额外的URLconf选项到 include() , 就像你可以通过字典传递额外的URLconf选项到普通的视图。 当你这样做的时候，被包含URLconf的 _每一_ 行都会收到那些额外的参数。
比如，下面的两个URLconf在功能上是相等的。
第一个：
~~~
# urls.py
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^blog/', include('inner'), {'blogid': 3}),
)
# inner.py
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^archive/$', 'mysite.views.archive'),
(r'^about/$', 'mysite.views.about'),
(r'^rss/$', 'mysite.views.rss'),
)
~~~
第二个
~~~
# urls.py
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^blog/', include('inner')),
)
# inner.py
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^archive/$', 'mysite.views.archive', {'blogid': 3}),
(r'^about/$', 'mysite.views.about', {'blogid': 3}),
(r'^rss/$', 'mysite.views.rss', {'blogid': 3}),
)
~~~
这个例子和前面关于被捕获的参数一样（在上一节就解释过这一点），额外的选项将 _总是_ 被传递到被包含的URLconf中的 _每一_ 行，不管那一行对应的视图是否确实作为有效参数接收这些选项，因此，这个技术只有在你确实需要那个被传递的额外参数的时候才显得有用。 因为这个原因，这种技术仅当你确信在涉及到的接受到额外你给出的选项的每个URLconf时有用的才奏效。
## 下一章
这一章提供了很多高级视图和URLconfs的小提示和技巧。 接下来，在[Chapter 9](http://docs.30c.org/djangobook2/chapter09/index.html),我们将会将这个先进的处理方案带给djangos模板系统。
