QueryDict 对象

在一个 HttpRequest 对象中， GET 和 POST 属性都是 django.http.QueryDict 的实例。 QueryDict 是一个类似于字典的类，专门用来处理用一个键的多值。当处理一些HTML表单中的元素，特别是 <select multiple="multiple"> 之类传递同一key的多值的元素时，就需要这个类了。

QueryDict 实例是不可变的，除非创建了一个 copy() 副本。也就是说不能直接更改 request.POST 和 request.GET 的属性。

QueryDict 实现了所有标准的字典的方法，因为它正是字典的一个子类。与其不同的东西都已在表H-3中列出。

>>> q = QueryDict('a=1')
>>> q = q.copy() # 使其可变
>>> q.update({'a': '2'})
>>> q.getlist('a')
['1', '2']
>>> q['a'] # 返回最后一个值
['2']

>>> q = QueryDict('a=1&a=2&a=3')
>>> q.items()
[('a', '3')]

另外， QueryDict 还有在表H-4中列出的方法。

>>> q = QueryDict('a=1&a=2&a=3')
>>> q.lists()
[('a', ['1', '2', '3'])]

一个完整的例子

例如, 给定这个HTML表单:

<form action="/foo/bar/" method="post">
<input type="text" name="your_name" />
<select multiple="multiple" name="bands">
    <option value="beatles">The Beatles</option>
    <option value="who">The Who</option>
    <option value="zombies">The Zombies</option>
</select>
<input type="submit" />
</form>

如果用户在 your_name 中输入 "John Smith" ，并且在多选框中同时选择了The Beatles和The Zombies，那么以下就是Django的request对象所拥有的：

>>> request.GET
{}
>>> request.POST
{'your_name': ['John Smith'], 'bands': ['beatles', 'zombies']}
>>> request.POST['your_name']
'John Smith'
>>> request.POST['bands']
'zombies'
>>> request.POST.getlist('bands')
['beatles', 'zombies']
>>> request.POST.get('your_name', 'Adrian')
'John Smith'
>>> request.POST.get('nonexistent_field', 'Nowhere Man')
'Nowhere Man'

使用时请注意:

GET , POST , COOKIES , FILES , META , REQUEST , raw_post_data 和 user 这些属性都是延迟加载的。 也就是说除非代码中访问它们，否则Django并不会花费资源来计算这些属性值。

构造HttpResponse

一般情况下，你创建一个 HttpResponse 时，以字符串的形式来传递页面的内容给 HttpResponse 的构造函数：

>>> response = HttpResponse("Here's the text of the Web page.")
>>> response = HttpResponse("Text only, please.", mimetype="text/plain")

但是如果希望逐渐增加内容，则可以把 response 当作一个类文件对象使用：

>>> response = HttpResponse()
>>> response.write("<p>Here's the text of the Web page.</p>")
>>> response.write("<p>Here's another paragraph.</p>")

你可以将一个迭代器传递给 HttpResponse ，而不是固定的字符串。如果你要这样做的话，请遵循以下规则：

• 迭代器应返回字符串。

• 若一个 HttpResponse 已经通过实例化，并以一个迭代器作为其内容，就不能以一个类文件对象使用 HttpResponse 实例。这样做的话，会导致一个 Exception 。

最后，注意 HttpResponse 实现了一个 write() 方法，使其可以在任何可以使用类文件对象的地方使用。 这方面的例子见第11章。

设置 Headers

您可以使用字典一样地添加和删除头信息。

>>> response = HttpResponse()
>>> response['X-DJANGO'] = "It's the best."
>>> del response['X-PHP']
>>> response['X-DJANGO']
"It's the best."

你也可以使用 has_header(header) 来检查一个头信息项是否存在。

请避免手工设置 Cookie 头，参见第12章Django中cookie工作原理的说明。

HttpResponse的子类

Django包含许多处理不同类型的HTTP请求的 HttpResponse 子类（见表H-5）。像 HttpResponse 一样，这些类在 django.http 中。

.. table:: 表 H-5. HttpResponse 子类

    +---------------------------------+-------------------------------------------+
    |类名                             |描述                                       |
    +=================================+===========================================+
    |``HttpResponseRedirect``         |构造函数的参数有一个：                     |
    |                                 |重定向的路径。 它可以是一个完整的URL       |
    |                                 |（例如， ``'http://search.yahoo.com/'`` ） |
    |                                 |或者不包括域名的绝对路径（如               |
    |                                 |``'/search/'`` ）。 注意它返回             |
    |                                 |HTTP 状态码 302。                          |
    +---------------------------------+-------------------------------------------+
    |``HttpResponsePermanentRedirect``|类似 ``HttpResponseRedirect`` ， 但是它    |
    |                                 |返回一个永久重定向 （HTTP 状态码 301），     |
    |                                 |而不是暂时性重定向（状态码302）。            |
    +---------------------------------+-------------------------------------------+
    |``HttpResponseNotModified``      |构造函数没有任何参数。                     |
    |                                 |用它来表示这个页面在上次请求后未改变。     |
    +---------------------------------+-------------------------------------------+
    |``HttpResponseBadRequest``       |类似 ``HttpResponse`` ，但使用400状态码。  |
    +---------------------------------+-------------------------------------------+
    |``HttpResponseNotFound``         |类似 ``HttpResponse`` ，但使用404状态码。  |
    +---------------------------------+-------------------------------------------+
    |``HttpResponseForbidden``        |类似 ``HttpResponse`` ，但使用403状态码。  |
    +---------------------------------+-------------------------------------------+
    |``HttpResponseNotAllowed``       |类似 ``HttpResponse`` ，但使用405状态码。  |
    |                                 |它必须有一个参数：                         |
    |                                 |允许方法的列表。                           |
    |                                 |（例如， ``['GET', 'POST']`` ）。          |
    +---------------------------------+-------------------------------------------+
    |``HttpResponseGone``             |类似 ``HttpResponse`` ，但使用410状态码。  |
    +---------------------------------+-------------------------------------------+
    |``HttpResponseServerError``      |类似 ``HttpResponse`` ，但使用500状态码。  |
    +---------------------------------+-------------------------------------------+

当然，如果框架不支持一些特性，你也可以定义自己的 HttpResponse 子类来处理不同的请求。

返回错误

在Django中返回HTTP错误代码很容易。我们前面已经提到 HttpResponseNotFound ， HttpResponseForbidden ， HttpResponseServerError ，和其它子类。为了更好地表示一个错误，只要返回这些子类之一的一个实例，而不是一个通常的 HttpResponse ，例如：

def my_view(request):
    # ...
    if foo:
        return HttpResponseNotFound('<h1>Page not found</h1>')
    else:
        return HttpResponse('<h1>Page was found</h1>')

至今为止，404错误是最常见的HTTP错误，有一种更容易的方式来处理。

当返回一个错误，比如 HttpResponseNotFound 时，需要定义错误页面的HTML：

return HttpResponseNotFound('<h1>Page not found</h1>')

为了方便，而且定义一个通用的应用于网站的404错误页面也是一个很好的选择，Django提供了一个 Http404 异常。如果在视图的任何地方引发 Http404 异常，Django就会捕获错误并返回应用程序的标准错误页面，当然，还有HTTP错误代码404。

例如：

from django.http import Http404

def detail(request, poll_id):
    try:
        p = Poll.objects.get(pk=poll_id)
    except Poll.DoesNotExist:
        raise Http404
    return render_to_response('polls/detail.html', {'poll': p})

为了完全发挥出 Http404 的功能，应创建一个模板，在404错误被引发时显示。模板的名字应该是 404.html ，而且应该位于模板树的最高层。

自定义 404 (无法找到) 视图

当引发 Http404 异常，Django加载一个专门处理404错误的视图。默认情况下，这个视图是 django.views.defaults.page_not_found ，它会加载并显示模板 404.html 。

这意味着需要在根模板目录定义一个 404.html 模板。这个模板会作用于所有404错误。

视图 page_not_found 适用于99%的网站应用程序，但若是希望重载该视图，可以在URLconf中指定 handler404 ，就像这样：sfas

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    ...
)

handler404 = 'mysite.views.my_custom_404_view'

后台执行时，Django以 handler404 来确定404视图。默认情况下，URLconf包含以下内容：

from django.conf.urls.defaults import *

这句话负责当前模块中的 handler404 设置。正如你所见，在 django/conf/urls/defaults.py 中， handler404 默认被设为 'django.views.defaults.page_not_found' 。

关于404视图，有三点需要注意：

• 当Django在URLconf无法找到匹配的正则表达式时，404视图会显示。

• 如果没有定义自己的404视图，而只是简单地使用默认的视图，此时就需要在模板目录的根目录创建一个 404.html 模板。默认的404视图会对所有404错误使用改模板。

• 若 DEBUG 被设为 True （在settings模块内），则404视图不会被使用，此时显示的是跟踪信息。

自定义 500 (服务器错误) 视图

同样地，若是在试图代码中出现了运行时错误，Django会进行特殊情况处理。如果视图引发了一个异常，Django会默认访问视图 django.views.defaults.server_error ，加载并显示模板 500.html 。

这意味着需要在根模板目录定义一个 500.html 模板。该模板作用于所有服务器错误。

视图 server_error 适用于99%的网站应用程序，但若是希望重载该视图，可以在URLconf中指定 handler500 ，就像这样：

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    ...
)

handler500 = 'mysite.views.my_custom_error_view'