1. 深入理解Django HttpRequest HttpResponse的类和实例
2. 了解META选项
3. 了解中间件
4. 理清所有模板传输模板变量的方式，并作出选择
5. Django模板系统：如何利用Django模板设计网站的页面结构
6. 了解各context处理器及各处理器之间的关系
7. 了解view层可以做的事情，并了解具体是如何做的，需要使用哪些库
8. 了解如何设计网站的URL，以方便参数（广义上）的准确清晰的传递
9. 了解正则表达式并作笔记

———————————————————————————————正文深入理解Django HttpRequest HttpResponse的类和实例——————————————————————————————

当请求一张页面时，Django把请求的metadata数据包装成一个HttpRequest对象（HttpRequest对象request是一个可以查询、操作的数据包，这个request对象还提供了一些方法帮助查询和使用request），然后Django加载合适的view方法,把这个 HttpRequest 对象作为第一个参数传给view方法。任何view方法都应该返回一个HttpResponse对象。

我们在本书中大量使用这两个对象；本附录详细解释HttpRequest和HttpResponse对象。

HttpRequest

HttpRequest代表一个来自uesr-agent的HTTP请求。

大多重要的请求信息都是作为HttpRequest 对象的属性出现(see Table H-1). 除了session外，其他所有属性都是只读的。

Table H-1. HttpRequest对象的属性（可以查询的条目）

Request对象也有一些有用的方法,见Table H-2：（方便查询的方法）

QueryDict对象（request作为QueryDict类实例，因此具有的的方法）

在 HttpRequest对象中, GET和POST属性是django.http.QueryDict类的实例。 QueryDict类似字典的自定义类，用来处理单键对应多值的情况。因为一些HTML form元素，例如，<selectmultiple=”multiple”>, 就会传多个值给单个键。

QueryDict对象是immutable(不可更改的),除非创建它们的copy()。这意味着我们不能直接改变request.POST and request.GET的属性。

QueryDict实现所有标准的字典方法。还包括一些特有的方法，见Table H-3.

此外, QueryDict也有一些方法，见Table H-4.

A Complete Example（经常要提交表单，下面的例子可以加深理解）

例如, 下面是一个HTML form:

<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域中输入”JohnSmith”，同时在多选框中选择了“The Beatles”和“The Zombies”，下面是Django请求对象的内容:

>>> 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’

HttpResponse

对于HttpRequest 对象来说，是由Django自动创建, 但是，HttpResponse对象就必须我们自己创建。每个View方法必须返回一个HttpResponse对象。

HttpResponse类在django.http.HttpResponse。

构造HttpResponses

一般地, 你可以通过给HttpResponse的构造函数传递字符串表示的页面内容来构造HttpResponse对象:

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

但是如果想要增量添加内容, 你可以把response当作filelike对象使用:

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

也可以给HttpResponse传递一个iterator作为参数，而不用传递硬编码字符串。 如果你使用这种技术, 下面是需要注意的一些事项:

·         iterator应该返回字符串.

·         如果HttpResponse使用iterator进行初始化，就不能把HttpResponse实例作为filelike 对象使用。这样做将会抛出异常。

最后，再说明一下，HttpResponse实现了write()方法, 可以在任何需要filelike对象的地方使用HttpResponse对象。参见第11章，有一些例子。

设置Headers

你可以使用字典语法添加，删除headers:

>>> response = HttpResponse() 
>>> response[‘X-DJANGO’] = “It’s the best.”
>>> del response[‘X-PHP’]
>>> response[‘X-DJANGO’]
“It’s the best.”

你也可以使用has_header(header)方法检测某个header是否存在。

不要手动设置Cookie headers；具体的做法，参见第12章，有关于怎样在Django中处理cookies的详细讲解。

HttpResponse子类（可以方便的应用于不同情况下的response）

Django包含很多HttpResponse子类，用来处理不同的HTTP响应类型(见Table H-5). 和HttpResponse一样, 这些子类在django.http中.

当然，你也可以自己定义不包含在上表中的HttpResponse子类。

返回Errors

在Django中返回HTTP错误码是很容易的。上面介绍了HttpResponseNotFound, HttpResponseForbidden, HttpResponseServerError等一些子类。View方法中返回这些子类的实例就OK了,例如:

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

当返回HttpResponseNotFound时,你需要定义错误页面的HTML:

return HttpResponseNotFound(‘<h1>Page not found</h1>’)

因为404错误是最常使用的HTTP错误, 有一个更方便的方法处理它。

为了方便，而且整个站点有一致的404错误页面也是友好的,Django提供一个Http404异常类。如果在一个View方法中抛出Http404,Django将会捕获它并且返回标准错误页面,同时返回错误码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.html,在模板根目录下创建。

自定义404 (Not Found) View方法

当抛出Http404异常时, Django会加载一个特殊的view方法处理404错误。默认地, 它是django.views.defaults.page_not_found,负责加载和渲染404.html模板文件。

这意味着我们必须在模板根目录定义404.html模板文件，该模板文件应用于所有的404异常。

该page_not_found view方法应该可以应对几乎99%的Web App，但是如果想要重载该view方法时, 你可以在URLConf文件中指定handler404为自定义的404 errpr view方法, 像这样:

from django.conf.urls.defaults import *

urlpatterns = patterns(”,    
    …
)

handler404 = ‘mysite.views.my_custom_404_view’

Django就是通过在URLConf文件中查找handler404来决定404 view方法的。默认地, URLconfs包含下面一行代码:

from django.conf.urls.defaults import *

在 django/conf/urls/defaults.py模块中, handler404赋值为 ‘django.views.defaults.page_not_found’。

注意:

·         如果请求URL没有和Django的URLConf文件中的任何一个正则表示式匹配，404 view方法就会被调用。

·         如果没有定义自己的404 view — 使用默认地404 view，你仍然有一个工作要做：在模板根目录创建404.html模板文件。默认地404 view将使用该模板处理所有404错误。

·         如果 DEBUG设置为True (在setting模块中)，404 view方法不会被使用，取而代之的是，traceback信息。

自定义500 (Server Error) View方法

同样地，当view代码发生运行时错误时，Django也会产生特殊行为。如果view方法产生异常，Django将会调用默认地view方法django.views.defaults.server_error, 该方法加载渲染500.html模板文件。

这意味着我们必须在模板根目录定义500.html模板文件，该模板文件应用于所有的服务器错误。

该server_error view方法应该可以应对几乎99%的Web App，但是如果想要重载该view方法时, 你可以在URLConf文件中指定handler500为自定义的server error view方法, 像这样:

from django.conf.urls.defaults import *

   urlpatterns = patterns(”,    

        …

   )

   handler500 = ‘mysite.views.my_custom_error_view’