author: http://www.b-list.org/weblog/2006/06/13/how-django-processes-request

很潦草的翻译，有时间在整理整理

—-进来的请求—-

调用django的server，有2类：

 1,apache的mod_python 它收到的请求通过mod_python建立一个‘#a’的实例来处理传给django 2,其他使用WSGI的server 它会建立一个‘#b’的实例

•  #a django.core.handlers.modpython.ModPythonHandler
  
•  #b django.core.handlers.wsgi.WsgiHandler

 这2个类均继承自django.core.handlers.base.BaseHandler，它包含了任何类型的request 所需的基本代码

 —-server建立handle实例—-

建立handler时发生：

•  1 import你的django settings file
  
•  2 import django的自定义异常处理类
  
•  3 hander调用自己的load_middleware method,来加载setting里列出的所有MIDDLEWARE_CLASSES 然后被‘#内省’

 middleware能处理4类过程：request, view, response and exception，

通过定义4种methods， 他们是：

process_request, process_view, process_response and process_exception middleware定义哪几个取决于自己要提供什么杨的功能

#内省 即hander查找middleware的method名，建立4个lists，他们是handler的instance wariables

1 _request_middleware 内含所有middleware定义的各自的process_request methods 2 ，3，4 是_view_middleware _response_middleware _exception_middleware

 —-server准备好了—-

1 hander‘点亮’dispatcher signal:‘request_started’。django的内部调度员dispatcher容许其他部件广播他们 在做什么，和其他代码监听某些事件。

2 然后handler建立一个 django.http.HttpRequest的子类，这个子类可以是#a或者#b

• #a django.core.handlers.modpython.ModPythonRequest
  
• #b django.core.handlers.wsgi.WSGIRequest

因为mod_python 或 WSGI APIs 传来的request的信息的格式不一样，必须被这2个子类转成统一格式 一旦有HttpRequest ，handler调用自己的get_response method，参数即HttpRequest

—-Middleware, round 1—-

get_response 首先在handler的_request_middleware提供的method里循环，以HttpRequest为参数

每个method都可以在自己处理后直接让get_response返回，而不继续下一轮循环。返回的是 django.http.HttpResponse的实例。

如果直接返回了，那就继续handler的其他代码 middleware其实就是对request的属性做些处理

—-正式处理开始—-

假设middleware都没让handler的get_response直接返回，那么handler就：

1 试着分析请求url，它在setting里寻找ROOT_URLCONF 找到处理后把它作为建立 django.core.urlresolvers.RegexURLResolver的实例的参数-是加了‘/’的urlpatterns

2 最后调用RegexURLResolver的resolve method ，参数是requested URL path，

即找url path 符合那个urlpatterns，找到后：

1 若符合的urlpatterns 有一个 include，那就分解url 继续往下传

2 负责返回3项：view function ，view的参数lists，额外的 keyword arguments 它会在找到第一个match后停止，所以将正则写的尽量详细些，若没找到resolve将产生 django.http.Http404的子类django.core.urlresolvers.Resolver404

—-Middleware, round 2—-

找到请求的view fuction后，handler调用_view_middleware list里的每个method，参数为view fuction和相关的其他参数，当然，这回合middleware也可以让handler直接返回。

—- Into the view—-

到了这步，handler将调用view fuction。view在django里它只要求3点：

1.  可调用
   
2.  第一个参数必须是django.http.HttpRequest 的实例或子类
   
3.  要么返回django.http.HttpResponse的实例 ，要么抛出异常

所以view是有限制的，一般情况view使用django的dbapi来建立，取得，更新，删除数据库里的东西，

他们加载，渲染模版后展示给用户

—- 模版 —-

django的模版系统2面性：

• 一面是html加上一些额外的东西给设计者使用
  
• 一面是纯python代码 给程序员使用

html作者的观点，模版系统是绝对简单的，3个概念：

1. 
   
2. 
   

按循序处理3件事：

1. 
   
2. 
   

—- django模版系统的构造—-

实际上，模版由一堆‘nodes’所描述，他们是python的类，继承自base node类django.template.Node

一般来说，view渲染一个模版分3步：

1. 
   
2. 
   

——response time—-

一旦模版被渲染或者其他何时的输出建立后，view会建立django.http.HttpResponse的实例

这个类的构造器有2个参数：

1. 
   

—- Middleware, round 3: exception edition—-

如果view函数或者其他代码 出现了异常，handler的get_response 将会在_exception_middleware 里循环，参数是HttpRequest 和the exception ，但愿会有一个mothod返回HttpResponse

——仍然没响应？——

依然没有HttpResponse的话，有3个因素：

1. view没返回值
   
2. view产生异常，但是没有一个middleware能够处理
   
3. 也许有个middleware处理view的异常 但是这个middleware自己产生了异常

这样的话get_response 将退回到自己的异常处理机制，4种情况：

1.  若异常是Http404 而且DEBUG setting is True，get_response 将执行viewdjango.views.debug.technical_404_response
   
2. 
   
3. 
   

除了django.http.Http404和 Python’s built-in SystemExit，handler将点亮dispatcher signal got_request_exception 邮寄给admin

——Middleware, final round——

不管怎样get_response出现什么异常，都会返回一个HttpResponse实例让那个HttpResponse在_response_middleware里循环

——-The check is in the mail——-

一旦middleware的最后回合执行后，handler将点亮 dispatcher signal request_finished 最后handler生成合适的返回值给server

{   •  文章分类:diary }
{ tags: django, python }