tornado web.py Application类源码剖析

【课程】web2.0程序设计
【作业要求】研究 application 对象源代码。说明 Application 对象实例化时,给出“debug=True”参数,代码动态自动编译的原理。
【参考文档】Application 类源代码   tornado Application 官方文档   debug模式和自动重新加载

tornado.web提供了一个简单的Web框架的异步功能。一个请求处理程序的集合就组成了一个web application.

1.分析application类的源码我们知道,application类有以下几种方法:

·__init__(self, handlers=None, default_host="", transforms=None, **settings)

构造函数,接受一个URLSpec类对象或者一个(正则表达式,被请求的类)的元组作为参数。当我们接受请求时,程序会按顺序遍历列表,并且实例化第一个正则表达式能够匹配的请求类。

对应的元组也可以包括其他部分,参见URLSpec构造函数的参数列表。

其中setting可以做一系列设置。

在tornado中的通用setting有:autoreload,debug,default_handler_classcompress_response,gzip,serve_traceback,log_function,ui_modules,ui_method

身份验证和安全设置的setting:cookie_secretlogin_urlxsrf_cookiesxsrf_cookie_version等等。

模板设置的setting:autoescape,compiled_template_cache,template_pathtemplate_loader

静态文件设置的setting:static_hash_cachestatic_path,static_url_prefix,static_handler_class, static_handler_args

·listen(self, port, address="", **kwargs)

为这个应用在给定的端口启动http服务器。这是一个创建HTTPServer对象并且调用listen函数的简便方法。

注意: HTTPServer.listen不支持的关键字参数通过HTTPServer的构造函数传进来;在高级用途如多进程模式中,不调用这个方法,而是创建一个HTTPServer对象,并且直接调用 TCPServer.bind/TCPServer.start();调用完这个函数之后,还是需要调用IOLoop.instance().start()来开始服务。

·_get_host_handlers(self, request)

获取主机的handlers,若找不到,返回false;

以下函数就和构造函数中的setting的一些值相对应:

·_load_ui_methods(self, methods)

·_load_ui_modules(self, modules)

·start_request(self, connection)

·__call__(self, request)
python一个语法特性,使得application可以直接当作函数被调用

·reverse_url(self, name, *args)

返回一个handler的URL路径,这个handler必须已经被作为URLSpec被加入application里面,

·log_request(self, handler)
一个完整的HTTP请求的记录日志,默认写入root logger.若想改变logs储存的位置,可重写这个方法,或在application的setting字典里传进一个函数作为log_function

2.现在我们重点分析Application 对象实例化时,给出“debug=True”参数,代码动态自动编译的原理,主要也就是构造函数参数列表中的setting值。

如果你将debug=true作为参数传进Application的构造函数,那么这个应用将会在debug模式下运行。在这个模式中,有几个特性是会设置好的,而这些特性也可以单独设置,当两种设置都存在时,单独设置比这样的默认设置优先级高。

特性如下:

autoreload=True:当有任何变化时,该应用程序会监视其源文件的更改,并重新加载自身。这减少了开发过程中手动重新启动服务器。然而,某些故障(如在导入时的语法错误)调试模式目前不能直接恢复。
compiled_template_cache=False:模板不会被缓存。
static_hash_cache=False:静态文件的哈希值(static_url函数会使用到的)将不会被缓存
serve_traceback=True‘:当一个RequestHandler的异常没有被捕获,会产生一个错误页,包括一个堆栈跟踪也会产生。

自动重新载入模式和多线程模式不兼容。调试模式的自动载入特性可以作为tornado.autoreload的一个独立的模块,二者可以结合:设置autoreload=True 来检测应用在运行过程中的改变,并用 python -m tornado.autoreload myserver.py 的方法来开启应用,用以捕获异步异常或其他错误。

重载会失去python解释器的命令参数,因为他的再执行使用的是sys.executable 和sys.argv.,所以修改这些值会导致重载方式不正确。在一些平台上,进程不能在适当的位置更新,那么代码的改变被检测到后,旧服务还在,新的服务已经开始了,就会使IDE产生混乱。

时间: 2024-10-24 11:49:45

tornado web.py Application类源码剖析的相关文章

Thread类源码剖析

目录 1.引子 2.JVM线程状态 3.Thread常用方法 4.拓展点 一.引子 说来也有些汗颜,搞了几年java,忽然发现竟然没拜读过java.lang.Thread类源码,这次特地拿出来晒一晒.本文将剖析Thread类源码(本文后面源码全部默认JDK8),并讲解一些重要的拓展点.希望对大家能有一些帮助. 本文讲解主干全部出自源码和注释,保证了权威性.(注意:网上,某些书中很多观点都是错的,过时的,片面的,所以大家一定要看源码,重要事情说N遍,看源码!看源码!看源码......) 二.JVM

Mongoose源码剖析:外篇之web服务器

转 http://www.cnblogs.com/skynet/archive/2010/07/24/1784110.html 这个博主里面很多关于mongoose的剖析 引言 在深入Mongoose源码剖析之前,我们应该清楚web服务器是什么?它提供什么服务?怎样提供服务?使用什么协议?客户端如何唯一标识web服务器的资源?下面我们抛开Mongoose,来介绍一个web服务的这些通性. web服务器:通常是指一个计算机程序(web服务器是什么?),在World Wide Web上提供诸如web

老李推荐:第6章3节《MonkeyRunner源码剖析》Monkey原理分析-事件源-事件源概览-命令翻译类

老李推荐:第6章3节<MonkeyRunner源码剖析>Monkey原理分析-事件源-事件源概览-命令翻译类 每个来自网络的字串命令都需要进行解析执行,只是有些是在解析的过程中直接执行了事,而有些是需要在解析后创建相应的事件类实例并添加到命令队列里面排队执行.负责这部分工作的就是命令翻译类.那么我们往下还是继续在MonkeySourceNetwork这个范畴中MonkeyCommand类是怎么一回事: 图6-3-1 MonkeyCommand族谱 图中间的MonkeyCommand是一个接口,

python附录-builtins.py模块str类源码(含str官方文档链接)

python附录-builtins.py模块str类源码 str官方文档链接:https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str builtins.py class str(object): """ str(object='') -> str str(bytes_or_buffer[, encoding[, errors]]) -> str Create a new stri

SpringMVC源码剖析(二)- DispatcherServlet的前世今生

上一篇文章<SpringMVC源码剖析(一)- 从抽象和接口说起>中,我介绍了一次典型的SpringMVC请求处理过程中,相继粉墨登场的各种核心类和接口.我刻意忽略了源码中的处理细节,只列出最简单的类甚至是接口类,目的就是让大家先从最高层次的抽象意义上来审视SpringMVC这个框架:我也刻意将SpringMVC和Struts2做对比,目的是让大家看到,SpringMVC究竟吸取了Sturts2设计思想中的哪些精华,又弥补了它的哪些遗憾. DispatcherServlet作为SpringMV

tomcat(12)org.apache.catalina.core.StandardContext源码剖析

[0]README 0)本文部分文字描述转自 "how tomcat works",旨在学习 "tomcat(12)StandardContext源码剖析" 的基础知识: 1)Context实例表示一个具体的web 应用程序,其中包含一个或多个Wrapper实例,每个Wrapper 表示一个具体的servlet定义: 2)Context容器还需要其他组件的支持,如载入器和Session 管理器.本章要intro 的 StandardContext是 catalina

tomcat(11)org.apache.catalina.core.StandardWrapper源码剖析

[0]README 0.0)本文部分文字描述转自 "how tomcat works",旨在学习 "tomcat(11)StandardWrapper源码剖析" 的基础知识: 0.1)StandardWrapper 是 Catalina中对Wrapper接口的标准实现:要知道,tomcat 中有4种类型的容器:Engine,Host,Context 和 Wrapper:(干货--review  tomcat 中有4种类型的容器:Engine,Host,Context

Django对中间件的调用思想、csrf中间件详细介绍、Django settings源码剖析、Django的Auth模块

目录 使用Django对中间件的调用思想完成自己的功能 功能要求 importlib模块介绍 功能的实现 csrf中间件详细介绍 跨站请求伪造 Django csrf中间件 form表单 ajax csrf相关装饰器 在CBV上加csrf装饰器 Django settings源码剖析及模仿使用 Django settings源码剖析 查看内部配置文件 模仿使用 Auth模块 auth简介 auth模块常用方法 创建用户 校验用户名和密码 保存用户登录状态 判断当前用户是否登录 校验原密码 修改密

DICOM医学图像处理:storescp.exe与storescu.exe源码剖析,学习C-STORE请求

背景: 上一篇专栏博文中针对PACS终端(或设备终端,如CT设备)与RIS系统之间worklist查询进行了介绍,并着重对比分析了DICOM3.0中各部分对DICOM网络通讯服务的定义.此次通过结合早些时间的博文DICOM医学图像处理:基于DCMTK工具包学习和分析worklist,对DCMTK开源库中提供的storescp.exe和storescu.exe工具的源码进行剖析,从底层深入了解C-STORE服务的触发及响应. 分析思路: storescp.exe和storescu.exe分别充当着