The Django Book

QueryDict Objects

QueryDict 对象

In an HttpRequest object, the GET and POST attributes are instances of django.http.QueryDict . QueryDict is a dictionary-like class customized to deal with multiple values for the same key. This is necessary because some HTML form elements, notably <select multiple="multiple"> , pass multiple values for the same key.

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

QueryDict instances are immutable, unless you create a copy() of them. That means you cant change attributes of request.POST and request.GET directly.

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

QueryDict implements the all standard dictionary methods, because its a subclass of dictionary. Exceptions are outlined in Table H-3.

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

>>> q = QueryDict('a=1')
>>> q = q.copy() # to make it mutable
>>> q.update({'a': '2'})
>>> q.getlist('a')
['1', '2']
>>> q['a'] # returns the last
['2']

>>> q = QueryDict('a=1&a=2&a=3')
>>> q.items()
[('a', '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')]

In addition, QueryDict has the methods shown in Table H-4.

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

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

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

A Complete Example

一个完整的例子

For example, given this HTML form:

例如, 给定这个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>

if the user enters "John Smith" in the your_name field and selects both The Beatles and The Zombies in the multiple select box, heres what Djangos request object would have:

如果用户在 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'

Implementation Note:

使用时请注意:

The GET , POST , COOKIES , FILES , META , REQUEST , raw_post_data , and user attributes are all lazily loaded. That means Django doesnt spend resources calculating the values of those attributes until your code requests them.

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

Construction HttpResponses

构造HttpResponse

Typically, youll construct an HttpResponse to pass the contents of the page, as a string, to the HttpResponse constructor:

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

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

But if you want to add content incrementally, you can use response as a filelike object:

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

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

You can pass HttpResponse an iterator rather than passing it hard-coded strings. If you use this technique, follow these guidelines:

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

• The iterator should return strings.

• 迭代器应返回字符串。

• If an HttpResponse has been initialized with an iterator as its content, you cant use the HttpResponse instance as a filelike object. Doing so will raise Exception .

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

Finally, note that HttpResponse implements a write() method, which makes is suitable for use anywhere that Python expects a filelike object. See Chapter 11 for some examples of using this technique.

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

Setting Headers

设置 Headers

You can add and delete headers using dictionary syntax:

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

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

You can also use has_header(header) to check for the existence of a header.

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

Avoid setting Cookie headers by hand; instead, see Chapter 12 for instructions on how cookies work in Django.

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

HttpResponse Subclasses

HttpResponse的子类

Django includes a number of HttpResponse subclasses that handle different types of HTTP responses (see Table H-5). Like HttpResponse , these subclasses live in django.http .

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状态码。  |
    +---------------------------------+-------------------------------------------+

You can, of course, define your own HttpResponse subclass to support different types of responses not supported out of the box.

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

Returning Errors

返回错误

Returning HTTP error codes in Django is easy. Weve already mentioned the HttpResponseNotFound , HttpResponseForbidden , HttpResponseServerError , and other subclasses. Just return an instance of one of those subclasses instead of a normal HttpResponse in order to signify an error, for example:

在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>')

Because a 404 error is by far the most common HTTP error, theres an easier way to handle it.

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

When you return an error such as HttpResponseNotFound , youre responsible for defining the HTML of the resulting error page:

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

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

For convenience, and because its a good idea to have a consistent 404 error page across your site, Django provides an Http404 exception. If you raise Http404 at any point in a view function, Django will catch it and return the standard error page for your application, along with an HTTP error code 404.

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

Heres an example:

例如：

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})

In order to use the Http404 exception to its fullest, you should create a template that is displayed when a 404 error is raised. This template should be called 404.html , and it should be located in the top level of your template tree.

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

Customizing the 404 (Not Found) View

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

When you raise an Http404 exception, Django loads a special view devoted to handling 404 errors. By default, its the view django.views.defaults.page_not_found , which loads and renders the template 404.html .

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

This means you need to define a 404.html template in your root template directory. This template will be used for all 404 errors.

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

This page_not_found view should suffice for 99% of Web applications, but if you want to override the 404 view, you can specify handler404 in your URLconf, like so:

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

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    ...
)

handler404 = 'mysite.views.my_custom_404_view'

Behind the scenes, Django determines the 404 view by looking for handler404 . By default, URLconfs contain the following line:

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

from django.conf.urls.defaults import *

That takes care of setting handler404 in the current module. As you can see in django/conf/urls/defaults.py , handler404 is set to 'django.views.defaults.page_not_found' by default.

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

There are three things to note about 404 views:

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

• The 404 view is also called if Django doesnt find a match after checking every regular expression in the URLconf.

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

• If you dont define your own 404 view and simply use the default, which is recommended you still have one obligation: to create a 404.html template in the root of your template directory. The default 404 view will use that template for all 404 errors.

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

• If DEBUG is set to True (in your settings module), then your 404 view will never be used, and the traceback will be displayed instead.

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

Customizing the 500 (Server Error) View

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

Similarly, Django executes special-case behavior in the case of runtime errors in view code. If a view results in an exception, Django will, by default, call the view django.views.defaults.server_error , which loads and renders the template 500.html .

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

This means you need to define a 500.html template in your root template directory. This template will be used for all server errors.

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

This server_error view should suffice for 99% of Web applications, but if you want to override the view, you can specify handler500 in your URLconf, like so:

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

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    ...
)

handler500 = 'mysite.views.my_custom_error_view'