Django从请求到返回流程

图1:流程图

1. 用户通过浏览器请求一个页面
2.请求到达Request Middlewares,中间件对request做一些预处理或者直接response请求
3.URLConf通过urls.py文件和请求的URL找到相应的View
4.View Middlewares被访问,它同样可以对request做一些处理或者直接返回response
5.调用View中的函数
6.View中的方法可以选择性的通过Models访问底层的数据
7.所有的Model-to-DB的交互都是通过manager完成的,这里的manager默认命名为objects

8.如果需要,Views可以使用一个特殊的Context
9.Context被传给Template用来生成页面
    a.Template使用Filters和Tags去渲染输出
    b.输出被返回到View
    c.HTTPResponse被发送到Response Middlewares
    d.任何Response Middlewares都可以丰富response或者返回一个完全不同的response
    e.Response返回到浏览器,呈现给用户

一:Middleware(中间件)
Middleware并不是Django所独有的东西,在其他的Web框架中也有这种概念。在Django中,Middleware可以渗入处理流程的四个阶段:
request,view,response和exception,相应的,在每个Middleware类中都有process_request,process_view, process_response 和 process_exception这四个方法。
你可以定义其中任意一个活多个方法,这取决于你希望该Middleware作用于哪个处理阶段。每个方法都可以直接返回response对象。
Middleware是在Django BaseHandler的load_middleware方法执行时加载的,加载之后会建立四个列表作为处理器的实例变量:
_request_middleware:process_request方法的列表
_view_middleware:process_view方法的列表
_response_middleware:process_response方法的列表
_exception_middleware:process_exception方法的列表
Django的中间件是在其配置文件(settings.py)的MIDDLEWARE_CLASSES元组中定义的。
在MIDDLEWARE_CLASSES中,中间件组件用字符串表示:指向中间件类名的完整Python路径。例如
MIDDLEWARE_CLASSES = [
‘django.middleware.security.SecurityMiddleware‘,
‘django.contrib.sessions.middleware.SessionMiddleware‘,
‘django.middleware.common.CommonMiddleware‘,
‘django.middleware.csrf.CsrfViewMiddleware‘,
‘django.contrib.auth.middleware.AuthenticationMiddleware‘,
‘django.contrib.auth.middleware.SessionAuthenticationMiddleware‘,
‘django.contrib.messages.middleware.MessageMiddleware‘,
‘django.middleware.clickjacking.XFrameOptionsMiddleware‘,
]`

Django项目的安装并不强制要求任何中间件,如果你愿意,MIDDLEWARE_CLASSES可以为空。中间件出现的顺序非常重要:
在request和view的处理阶段,Django按照MIDDLEWARE_CLASSES中出现的顺序来应用中间件,而在response和exception异常处理阶段,
Django则按逆序来调用它们。也就是说,Django将MIDDLEWARE_CLASSES视为view函数外层的顺序包装子:
在request阶段按顺序从上到下穿过,而在response则反过来。以下这张图可以更好地帮助你理解:

图2:中间件

 文章转载于:http://projectsedu.com/2016/10/17/django%E4%BB%8E%E8%AF%B7%E6%B1%82%E5%88%B0%E8%BF%94%E5%9B%9E%E9%83%BD%E7%BB%8F%E5%8E%86%E4%BA%86%E4%BB%80%E4%B9%88/
时间: 2024-11-07 12:49:14

Django从请求到返回流程的相关文章

Django——如何处理请求(URL配置和视图)

URLconfig—— 为了绑定视图函数和URL,我们使用URLconf. URLconf 就像是 Django 所支撑网站的目录. 它的本质是 URL 模式以及要为该 URL 模式调用的视图函数之间的映射表. 你就是以这种方式告诉 Django,对于这个 URL 调用这段代码,对于那个 URL 调用那段代码. 例如,当用户访问/foo/时,调用视图函数foo_view(),这个视图函数存在于Python模块文件view.py中. 当访问 URL /hello/ 时,Django 根据 ROOT

ICE学习第四步-----客户端请求服务器返回数据

这次我们来做一个例子,流程很简单:客户端向服务器发送一条指令,服务端接收到这条指令之后,向客户端发送数据库中查询到的数据,最终显示在DataGridView上. 根据上一篇文章介绍的Slice语法,我们先来定义ICE文件.我定义两个ICE文件,一个用来描述测试数据库表中属性相关信息,另一个则是请求数据的方法. 结构如下:    定义结构体,和数据库中表的列对应,添加序列(相当于数组类型). 在获取表的方法中注意要记得#include带有结构的ice文件,并把接口函数的返回值类型写成之前定义的数组

web请求的处理流程

web请求的处理流程如下: 1.客户发起请求到服务器网卡:2.服务器网卡接受到请求后转交给内核处理:3.内核根据请求对应的套接字,将请求交给工作在用户空间的Web服务器进程4.Web服务器进程根据用户请求,向内核进行系统调用,申请获取相应资源(如index.html)5.内核发现web服务器进程请求的是一个存放在硬盘上的资源,因此通过驱动程序连接磁盘6.内核调度磁盘,获取需要的资源7.内核将资源存放在自己的缓冲区中,并通知Web服务器进程8.Web服务器进程通过系统调用取得资源,并将其复制到自己

django HTTP请求(Request)和回应(Response)对象

Django使用request和response对象在系统间传递状态.—(阿伦)当一个页面被请示时,Django创建一个包含请求元数据的 HttpRequest 对象. 然后Django调入合适的视图,把HttpRequest 作为视图的函数的第一个参数 传入.每个视图要负责返回一个 HttpResponse 对象. HttpRequest对象HttpRequest 表示来自某客户端的一个单独的HTTP请求.HttpRequest实例的属性包含了关于此次请求的大多数重要信息(详见表H-1). 除

关于多个Ajax请求执行返回先后的问题

注:转载请在显著地方标注来源 有时候在一个业务事件处理流程上,可能会遇到点击了一个按钮或者其他事件触发了一个动作 需要执行两个以上的Ajax请求,但是可能要顾虑到Ajax请求执行的先后顺序,有时候Ajax请求顺序出问题,会导致各种问题 例如现在有两个ajax事件,分别为ajax1 ,ajax2 一个叫做main的方法调用执行入口 1. function main(){ ajax1(data,callback); ajax2(data,callback); } 如果我们按照上面的方法去执行,表面上

【Django】Django中请求的生命周期

Django的请求生命周期是指当用户在浏览器上输入url到用户看到网页的这个时间段内,Django后台所发生的事情 1. 当用户在浏览器中输入url时,浏览器会生成请求头和请求体发给服务端 请求头和请求体中会包含浏览器的动作(action),这个动作通常为get或者post,体现在url之中. 2. url经过Django中的wsgi,再经过Django的中间件,最后url到过路由映射表,在路由中一条一条进行匹配, 一旦其中一条匹配成功就执行对应的视图函数,后面的路由就不再继续匹配了. 3. 视

nginx用户请求反向代理流程

保障后端业务正常运行,通过nginx实现多级代理,后端业务官网 小程序 APP H5等 场景: 192.168.0.55 SLB01 192.168.0.42 SLB02 192.168.0.4 WEB01 SLB01配置代理SLB02:prot80 SLB02配置代理后端真实web节点 后端web节点配置如下  ps:为了精简配置文件把所有的配置参数放在了nginx 同一级目录proxy_params里面 流程梳理 以上我们配置好了nginx多级代理 来看下代理请求的流程 三台服务器执行 ta

图解 Spring:HTTP 请求的处理流程与机制【3】

3. HTTP 请求在 Web 应用中的处理流程 在穿越了 Web 容器之后,HTTP 请求将被投送到 Web 应用,我们继续以 Tomcat 为例剖析后续流程.Web 容器与 Web 应用的衔接是通过配置文件 web.xml 完成的.web.xml 是遵循 Java Servlet 标准规范的配置文件,我们通过这份配置文件定义构成 Web 应用的各种核心组件和初始化配置,其中包括:过滤器 Filter.监听器 Listener.伺服器 Servlet 等等.不同组件分别承担不同的功能,在介绍

图解 Spring:HTTP 请求的处理流程与机制【4】

4. HTTP 请求在 Spring 框架中的处理流程 在穿越了 Web 容器和 Web 应用之后,HTTP 请求将被投送到 Spring 框架,我们继续剖析后续流程.Web 应用与 Spring MVC 的衔接是通过配置文件 mvc-servlet.xml 完成的,我们通过这份配置文件定义构成 Spring MVC 的各种核心组件和初始化配置,其中包括:控制器 Controller.视图解析器 ViewResolver.视图 View 等等.不同组件分别承担不同的功能,在介绍 Spring 框