笔者也使用过一段时间adminx组件,后来由于adminx停更,又遇到更简单的django-simpleui后,现在基本上只使用simpleui了,使用simpleui的几个好处,笔者认为排在第一位的是于原生admin的兼容性非常高,大量的原生配置基本可以直接用.adminx扩展就需要改很多地方,配置文件也是变成不一样的adminx.py.试用之后,比较喜欢simpleui思路,不知道以后功能多了写复杂了会不会也得走adminx的老路.不过adminx和simpleui等第三方组件都是可以让我们

流程 Django session源码流程 首先执行的是SessionMiddleware的init方法 import_module(settings.SESSION_ENGINE) 导入了一个 django.contrib.sessions.backends.db的包 将db中SessionStore 赋值给self.SessionStore 执行process_request 方法 获取存放于cookie中的session_id,赋值为session_key 实例化session仓库sess

[背景] 最近在看django官方文档的class-based-views这一节的时候一直不得要领,感觉自己清楚,但是回想起来又没有脉络:于是没有办法只 能是“暗中观察”django的源码了. 刚打开源码看了没有多久就疑窦丛生,比如说下面这一段,能看的出get_object方法中用到的self.kwargs 属性是在哪里设置过呢?如果没有设置直接用是会有报错的,详细内容看下面源码 class SingleObjectMixin(ContextMixin): """ Provi

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

Django settings源码 Django中有两个配置文件 局部配置:配置文件settings.py,即项目同名文件夹下的settings.py文件 全局配置:django内部全局的配置文件settings.py,需要导入才能看到 from django.conf import settings # 是一个对象,单例模式 from django.conf import global_settings # 真正的默认配置文件 特点: 先加载全局配置,再加载局部配置,以局部优先 源码解析 点进

Django settings 源码 """ 1.django其实有两个配置文件 一个是暴露给用户可以自定义的配置文件 项目根目录下的settings.py 一个是项目默认的配置文件 当用户不做任何配置的时候自动加载默认配置 2.配置文件变量名必须是大写 """ from django.conf import global_settings 查看源码 global_settings.py LANGUAGE_CODE = 'en-us' ('zh-

概要: 1.restful 规范(建议); 2. django rest framework框架 内容回顾: 1.开发模式; - 普通开发模式(前后端放在一起写) - 前后端分离 好处: 后端一套,前端使用app,pc等: 2. 后端开发 为前端提供URL(API的开发) 注:永远返回Httpresponse 3. django Fbv 和Cbv   一.Django CBV和FBV 在视图中,cbv支持四中method,如下: from django.views import View cla

1 CBV的源码分析 #视图 class login (View): pass #路由 url(r'^books/$', views.login.as_view()) #阅读源码: #左侧工程栏--->设置图标-->点击--->show members(能看到py文件,pu下的类,类下的方法) -Class Base View(基于类的视图) -Function Base View(基于函数的视图) -def as_view 类方法 :返回view -def view:as_view的内

admin源码解析 单例模式 单例模式(Singleton Pattern)是一种常用的软件设计模式,该模式的主要目的是确保某一个类只有一个实例存在.当你希望在整个系统中,某个类只能出现一个实例时,单例对象就能派上用场. 比如,某个服务器程序的配置信息存放在一个文件中,客户端通过一个 AppConfig 的类来读取配置文件的信息.如果在程序运行期间,有很多地方都需要使用配置文件的内容,也就是说,很多地方都需要创建 AppConfig 对象的实例,这就导致系统中存在多个 AppConfig 的实例

1 绪言 当大家看大这篇博文的时候,应该对Django rest_framework中的CBV有所了解了,大致来说就是通过定义类来继承APIView类,并在类中定义get.post.put.delete等对应于请求方法的方法,当请求来的时候会自动反射到相应的方法并执行,路由中需要配置类的as_view()的方式来配置路由,至于如何拿到请求方法并对应执行我们自定义类中的方法,在我的rest_framework系列的第一篇博文中有详细的分析,这里不再多说.这一篇博文我们来研究一下视图类. 2 视图进

1 绪论 Djangorest_framework的版本控制允许用户更改不同客户端之间的行为,且提供了许多不同的版本控制方案.版本控制由传入的客户端请求确定,可以基于请求URL,也可以基于请求标头. 版本控制入口在在dispatch方法中调用的initial方法中,如下所示: def initial(self, request, *args, **kwargs): …… #版本控制 version, scheme = self.determine_version(request, *args,

1 绪言 权限判定之后的下一个环节是访问频率控制,本篇我们分析访问频率控制部分源码. 2 源码分析 访问频率控制在dispatch方法中的initial方法调用check_throttles方法开始.入口如下: def check_throttles(self, request): for throttle in self.get_throttles():#遍历每一个频率控制对象 if not throttle.allow_request(request, self): self.throttl

1 绪言 上一篇中讲了django rest_framework总体流程,整个流程中最关键的一步就是执行dispatch方法.在dispatch方法中,在调用了一个initial方法,所有的认证.权限检查.访问频率控制都是在这个方法中进行的.下面代码为init方法执行这三个操作的源码: def initial(self, request, *args, **kwargs): """ 在调用方法处理程序之前运行需要发生的任何事情(例如:认证.权限.访问频率控制). "

1 序言 有如下django代码,视图层: from django.http import HttpResponse from rest_framework.views import APIView class OrdersView(APIView): def get(self , request , *args , **kwargs): return HttpResponse('GET请求') def post(self , request , *args , **kwargs): retur

在Django中,如果我们新建一个项目,只要在admin.py文件中注册,就可以对其相应的文件进行增删改查操作. 而我们在路由系统中只看到了一条信息:url(r'^admin/', admin.site.urls),但是我们确实是可以进行增删改查操作?这其中到底有什么端倪了? 下面我们会从Django源码的角度来分析admin执行流程. 1.循环加载执行所有已经注册的app中的admin.py文件 def autodiscover(): autodiscover_modules('admin',

首先我们导入django.contrib.sessions.middleware这个中间件,查看里面的Session源码 from django.contrib.sessions.middleware import SessionMiddleware 我们可以看到一个类,可以把他分为3部分: class SessionMiddleware(MiddlewareMixin): def __init__(self, get_response=None): ... def process_reques

回顾: 关于里面的源码流程大家可以全看视频,因为代码的跳动性很大,而且会多次调用通过一方法,所以关于中间源码的部分去找个视频看一看,我写的不是很清楚. # 1 cookie session # 2 forms, modelsform (1)效验数据 class Book(model.Model): name = models.CharField(min_length=5) price = models.InterField() publish = models.ForeignKey("Pusbl

APIView使用:luffy项目中关于APIView的使用 在Django之 CBV和FBV中,我们是分析的from django.views import View下的执行流程,以下是代码 from django.views import View class IndexView(View): def get(self,request, *args, **kwargs): return HttpResponse("ok") def dispatch(self, request, *

1 绪论 网络传输数据只能传输字符串格式的,如果是列表.字典等数据类型,需要转换之后才能使用但是我们之前的rest_framework例子都没有转换就直接可以使用了,这是因为rest_framework自带有一套解析器. 2 源码分析 我们重新回到dispatch方法中对请求进行重新封装的initialize_request类,源码如下: def initialize_request(self, request, *args, **kwargs): """ Returns t

1 绪言 上一篇中分析了认证部分的源码,认证后的下一个环节就是权限判定了.事实上,权限判定肯定要与认证联合使用才行,因为认证部分不会对请求进行禁止或者是允许,而只是根据请求中用户信息进行用户身份判断,而权限判定就是认证中添加的用户身份进行权限判定.权限判定的入口在dispatch方法中调用的initial方法中,如下所示: def initial(self, request, *args, **kwargs): …… # Ensure that the incoming request is p

实现接口类的两种方式 方式一 from abc import ABCMeta from abc import abstractmethod class BaseMessage(metaclass=ABCMeta): @abstractmethod def send(self,subject,body,to,name): pass 方式二 class BaseMessage(object): def send(self, subject, body, to, name): raise NotImp