前言
最近学习了 django 的一个 restframework 框架,对于里面的执行流程产生了兴趣,经过昨天一晚上初步搞清楚了执行流程(部分方法还不太清楚),于是想详细的总结一下当来一个请求时,在该框架里面是如何执行的?
启动项目时
昨天在调试django时,发现在 APIView 中打的断点没有断下来,而是打在 View 中的断点断下来了,调试了很多次,最后发现,在 django 项目启动时,会首先加载 urls 中的文件,执行 views 中类的 as_view方法,其实是继承自 APIView 的,APIView 继承自 django 原生 View 的as_view 方法。
里面一个参数叫 pattern_name,对应的值是admin:auth_group_change,如下图所示:
目前还不清楚这里面的具体流程是什么,但是并不妨碍阅读之后的源码,在这只要清楚一点,在 Django 项目启动时,路由所对应的CBV里面的相关方法的内存地址已经获取到。这样做的好处就是提高效率,坏处可能有一点点,会提升性能的消耗。
具体路由和逻辑代码
在这里假设来一个 GET 请求,urls 和 views里面的代码如下:
# urls.py url(r'^book/(?P<id>\d+)/', views.Book.as_view()),
# views.py class Book(APIView): def dispatch(self, request, *args, **kwargs): return super().dispatch(request, *args, **kwargs) def get(self, request, id): response = {'status': 100, 'msg': None} book = models.Book.objects.filter(pk=id).first() book_ser = BookSerib(book, many=False) print('book_ser.data', book_ser.data) response['books'] = book_ser.data response['msg'] = '获取图书成功' print('response', response) return Response(response)
urls 里面就是一个典型的 CBV 的路由配置,在 views 中一个是路由分发方法,一个是获取单本图书信息(通过 id)。
as_view 具体执行流程
在项目启动时,相应的函数内存地址已经获取到,那么具体是怎么获取到的呢?
在上面的代码中可以看到 Book 类是继承自 APIView 类的,所以在路由配置里面执行的 as_view 方法如果 Book 类没有重写,那么执行的就是按照 mro 列表顺序查找到的第一个方法,在这里执行的是 APIView 类中的 as_view 方法。
查看该源码如下:
APIView 类的父类是 View 类,查看该类的 as_view 方法,源码如下:
具体 as_view 就是将 view 函数的内存地址返回,以便请求来时直接调用。
而 initkwargs 这个参数应该是由 django 内部传的一些参数,如下所示:
请求到来时
因为经过 django 先执行了 as_view 返回 view 的内存地址,所以会直接执行 view 函数,如下:
在这里该 self 由于是 继承自 APIView 类的 Book 类的对象,所以 dispatch 方法首先去自身找,之后去父类找,在 APIView 类中找到 dispatch 方法,源码如下:
initialize_request方法:
源码如下:
在实例化 Request 对象时, authenticators 参数需要在认证时使用,所以先把这个参数的值找出来。步骤如下:
调用 self.get_authenticators
找到 self.authentication_classes
找到 api_settings,才能找到DEFAULT_AUTHENTICATION_CLASSES
DEFAULT和IMPORT_STRINGS参数
DEFAULT参数
IMPORT_STRINGS参数
实例化 APISettings 对象
通过__getattr__方法获取值
执行perform_import方法
执行import_from_string
执行import_module
执行_bootstrap._gcd_import
执行_sanity_check
_sanity_check返回,执行_find_and_load方法
所以通过__getattr__的到的是一个列表,里面是两个类,分别是[rest_framework_authentication_SessionAuthentication, rest_framework_authentication_BasicAuthentication]
到这里,initialize_request方法执行结束,得到一个经过 Request 类实例化的 request 对象,该对象里面含有原生 request 对象,可以通过 request._request 取到。
initial 方法:
源码如下:
这里传入的 request 参数是经过 Request 封装后的参数
执行get_format_suffix
执行完这个方法, self_format_kwarg = None ,
执行perform_content_negotiation
执行self.get_renders
执行self.get_content_negotiator
执行 conneg.select_renderer方法
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小牛知识库。
ethereum的虚拟机源码所有部分在core/vm下。 去除测试总共有24个源码文件。 整个vm调用的入口在go-ethereum/core/state_transaction.go中。 我们主要是为了分析虚拟机源码,所以关于以太坊是如何进行交易转账忽略过去。 从上面的截图我们可以看出, 当以太坊的交易中to地址为nil时, 意味着部署合约, 那么就会调用evm.Create方法。 否则调用了e
本文向大家介绍Vue中之nextTick函数源码分析详解,包括了Vue中之nextTick函数源码分析详解的使用技巧和注意事项,需要的朋友参考一下 1. 什么是Vue.nextTick()? 官方文档解释如下: 在下次DOM更新循环结束之后执行的延迟回调。在修改数据之后立即使用这个方法,获取更新后的DOM。 2. 为什么要使用nextTick? 如上代码 在页面视图上显示bb,但是当我在控制台打印
本文向大家介绍jQuery源码分析之init的详细介绍,包括了jQuery源码分析之init的详细介绍的使用技巧和注意事项,需要的朋友参考一下 init 构造器 由于这个函数直接和 jQuery() 的参数有关,先来说下能接受什么样的参数。 源码中接受 3 个参数: jQuery() ,空参数,这个会直接返回一个空的 jQuery 对象,return this。 jQuery( selector
本文向大家介绍JUC之Semaphore源码分析,包括了JUC之Semaphore源码分析的使用技巧和注意事项,需要的朋友参考一下 Semaphore 主要用于限量控制并发执行代码的工具类, 其内部通过 一个 permit 来进行定义并发执行的数量。 以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持呐喊教程。
区块链技术是计算机技术与金融技术交融的成功创新,被认为是极具潜力的分布式账本平台的核心技术。如果你还不了解区块链,可以阅读 区块链技术指南。
Memcached源码分析共8篇文章,前7篇文章主要分析每个模块的c源代码。这一篇文章主要是将之前的流程串起来,总结和回顾。同时通过这篇文章可以全局去看Memcached的结构。 一、Memcache的网络模型 Memcached主要是基于Libevent 网络事件库进行开发的。 Memcached的网络模型分为两部分:主线程和工作线程。主线程主要用来接收客户端的连接信息;工作线程主要用来接管客户