django -- cbv,fbv,中间件

django中请求处理方式有2种：FBV 和 CBV

FBV（function base views） 就是在视图里使用函数处理请求。

url(r'^del/',views.delarticle),

def delarticle(request):    flag={'tag':False}    if request.is_ajax():        nid=request.POST.get("article.nid")        models.Article.objects.filter(nid=nid).delete()        print(nid)        flag['tag']=True    return HttpResponse(json.dumps(flag))

CBV（class base views） 就是在视图里使用类处理请求。

url(r'^class.html$', views.Indexview.as_view()),#as_view()方法内部通过hasattr()来对应判断有没有  类的方法

from django.views import View
class Indexview(View): def dispatch(self, request, *args, **kwargs): ret=super(Indexview,self).dispatch(request, *args, **kwargs) return ret def get(self,request,*args,**kwargs): return render(request,'view.html') def post(self,request,*args,**kwargs): return HttpResponse('9')
为类添加装饰器
from django.views import Viewfrom django.utils.decorators import method_decoratordef test(func):#装饰器    def inner(*args,**kwargs):        return func(*args,**kwargs)    return innerclass Indexview(View):    @method_decorator(test)#必须以@method_decirator(装饰器函数名)形式    def dispatch(self, request, *args, **kwargs):#通过getattr来执行类的方法，执行顺序在as_view()后，其他方法前
# Try to dispatch to the right method; if a method doesn't exist,# defer to the error handler. Also defer to the error handler if the# request method isn't on the approved list.
 ret=super(Indexview,self).dispatch(request, *args, **kwargs) return ret
可以加到对应的方法上 和类上@method_decorator(test,name='方法名')加在类上需要指定方法名
特殊：CSRF Token只能加到dispatch ======================================================================================================
中间件
django 中的中间件（middleware），在django中，中间件其实就是一个类，在请求到来和结束后，django会根据自己的规则在合适的时机执行中间件中相应的方法。
在django项目的settings模块中，有一个 MIDDLEWARE 变量，其中每一个元素就是一个中间件
MIDDLEWARE = [    'django.middleware.security.SecurityMiddleware',    'django.contrib.sessions.middleware.SessionMiddleware',    'django.middleware.common.CommonMiddleware',    'django.middleware.csrf.CsrfViewMiddleware',    'django.contrib.auth.middleware.AuthenticationMiddleware',    'django.contrib.messages.middleware.MessageMiddleware',    'django.middleware.clickjacking.XFrameOptionsMiddleware',]

每一个中间件组件用字符串的方式描述：一个完整的Python全路径加上中间件的类名称。

Django的程序中，中间件不是必需的 —— 只要你喜欢，MIDDLEWARE_CLASSES可以为空 —— 但是强烈推荐你至少使用CommonMiddleware。
MIDDLEWARE中的顺序非常重要，因为一个中间件可能依赖于另外一个。例如，AuthenticationMiddleware在会话中储存已认证的用户。所以它必须在SessionMiddleware之后运行。一些关于Django中间件类的顺序的常见提示，请见http://python.usyiyi.cn/documents/django_182/ref/middleware.html#middleware-ordering。
-----------------------------------------------------------------------------------------------------
钩子和应用的顺序
在请求阶段中，调用视图之前，Django会按照MIDDLEWARE中定义的顺序自顶向下应用中间件。会用到两个钩子：
process_request()
process_view()
在响应阶段中，调用视图之后，中间件会按照相反的顺序应用，自底向上。会用到三个钩子：
process_exception()（仅当视图抛出异常的时候）
process_template_response()（仅用于模板响应）
process_response()




先执行所有类的process_request()再从头执行所有类的process_view()经过路由、视图然后从下到上执行process_response()
----------------------------------------------------------------------------------------------------、
编写自己的中间件
编写自己的中间件很容易的。每个中间件组件是一个独立的Python 类，你可以定义下面这些方法中的一个或多个：
process_request
process_request(request)
request是一个HttpRequest 对象。
在Django决定执行哪个视图之前，process_request()会在每个请求上调用。
它应该返回一个None 或一个HttpResponse对象。如果返回None，Django会继续处理这个请求，执行其它process_request()中间件，然后process_view()中间件，最后是对应的视图。如果它返回一个HttpResponse对象，Django 就不用再去调用其它的request、view 或exception 中间件，或对应的视图；它将对HttpResponse 运用响应阶段的中间件，并返回结果。
process_view
process_view(request,view_func, view_args, view_kwargs)
request是一个HttpRequest对象。view_func是 Django会调用的一个Python的函数。（它是一个真实的函数对象，不是函数的字符名称。)view_args是一个会被传递到视图的位置参数列表，而view_kwargs 是一个会被传递到视图的关键字参数字典。view_args和 view_kwargs 都不包括第一个视图参数(request)。
process_view()会在Django 调用视图之前被调用。
它将返回None 或一个HttpResponse 对象。如果返回None，Django 将会继续处理这个请求，执行其它的process_view() 中间件，然后调用对应的视图。如果返回一个HttpResponse对象，Django 就不用再去调用其它的view 或exception 中间件，或对应的视图；它将对HttpResponse 运用响应阶段的中间件，并返回结果。
注意
在中间件内部，从process_request 或process_view 中访问request.POST 或request.REQUEST 将阻碍该中间件之后的所有视图无法修改请求的上传处理程序，一般情况下要避免这样使用。
类CsrfViewMiddleware可以被认为是个例外，因为它提供csrf_exempt() 和csrf_protect()两个装饰器，允许视图显式控制在哪个点需要开启CSRF验证。
process_template_response
process_template_response(request,response)
request是一个HttpRequest对象。response是一个TemplateResponse对象（或等价的对象），由Django视图或者中间件返回。
如果响应的实例有render()方法，process_template_response()在视图刚好执行完毕之后被调用，这表明了它是一个TemplateResponse对象（或等价的对象）。
这个方法必须返回一个实现了render方法的响应对象。它可以修改给定的response对象，通过修改 response.template_name和response.context_data或者它可以创建一个全新的 TemplateResponse或等价的对象。
你不需要显式渲染响应 —— 一旦所有的模板响应中间件被调用，响应会自动被渲染。
在一个响应的处理期间，中间件以相反的顺序运行，这包括process_template_response()。
process_response
process_response(request,response)¶
request是一个HttpRequest对象。response是Django视图或者中间件返回的HttpResponse或者StreamingHttpResponse对象。
process_response()在所有响应返回浏览器之前被调用。
这个方法必须返回HttpResponse或者StreamingHttpResponse对象。它可以改变已有的response，或者创建并返回新的HttpResponse或StreamingHttpResponse对象。
不像 process_request()和process_view()方法，即使同一个中间件类中的process_request()和process_view()方法会因为前面的一个中间件返回HttpResponse而被跳过，process_response()方法总是会被调用。特别是，这意味着你的process_response()方法不能依赖于process_request()方法中的设置。
最后，记住在响应阶段中，中间件以相反的顺序被应用，自底向上。意思是定义在MIDDLEWARE最底下的类会最先被运行。
处理流式响应
不像HttpResponse，StreamingHttpResponse并没有content属性。所以，中间件再也不能假设所有响应都带有content属性。如果它们需要访问内容，他们必须测试是否为流式响应，并相应地调整自己的行为。
if response.streaming:    response.streaming_content = wrap_streaming_content(response.streaming_content)else:    response.content = alter_content(response.content)
注意
我们需要假设streaming_content可能会大到在内存中无法容纳。响应中间件可能会把它封装在新的生成器中，但是一定不要销毁它。封装一般会实现成这样：
def wrap_streaming_content(content):    for chunk in content:        yield alter_content(chunk)
process_exception
process_exception(request,exception)
request是一个HttpRequest对象。exception是一个被视图中的方法抛出来的Exception对象。
当一个视图抛出异常时，Django会调用process_exception()来处理。process_exception()应该返回一个None 或者一个HttpResponse对象。如果它返回一个HttpResponse对象，模型响应和响应中间件会被应用，响应结果会返回给浏览器。否则， 默认的异常处理机制将会被触发。
再次提醒，在处理响应期间，中间件的执行顺序是倒序执行的，这包括process_exception。如果一个异常处理的中间件返回了一个响应，那这个中间件上面的中间件都将不会被调用。
__init__
大多数的中间件类都不需要一个初始化方法，因为中间件的类定义仅仅是为process_*提供一个占位符。如果你确实需要一个全局的状态那就可以通过__init__来加载。然后要铭记如下两个警告：
Django初始化你的中间件无需任何参数，因此不要定义一个有参数的__init__方法。
不像process_* 对每个请求都要调用，__init__ 只会被调用一次，就是在Web 服务器响应第一个请求的时候。
标记中间件不被使用
有时在运行时决定是否一个中间件需要被加载是很有用的。 在这种情况下，你的中间件中的 __init__方法可以抛出一个django.core.exceptions.MiddlewareNotUsed异常。Django会从中间件处理过程中移除这部分中间件，并且当DEBUG为True的时候在django.request记录器中记录调试信息。
指导准则
中间件的类不能是任何类的子类。
中间件可以存在于你Python 路径中的任何位置。 Django所关心的只是被包含在MIDDLEWARE中的配置。
---------------------------------------------------------------------------------------------------
class MiddlewareMixin(object):    def __init__(self, get_response=None):        self.get_response = get_response        super(MiddlewareMixin, self).__init__()    def __call__(self, request):        response = None        if hasattr(self, 'process_request'):            response = self.process_request(request)        if not response:            response = self.get_response(request)        if hasattr(self, 'process_response'):            response = self.process_response(request, response)        return response
class M1(MiddlewareMixin):    def process_request(self,request):        print('m1.process_request')    def process_view(self,request, view_func, view_func_args, view_func_kwargs):        print('m1.process_view')    def process_exception(self,request,exception):        print('m1.process_exception')    def process_response(self,request,response):        print('m1.process_response')        return response    def process_template_response(self,request,response):        print('m1.process_template_response')        return response


MIDDLEWARE = [    'django.middleware.security.SecurityMiddleware',    'django.contrib.sessions.middleware.SessionMiddleware',    'django.middleware.common.CommonMiddleware',    'django.middleware.csrf.CsrfViewMiddleware',    'django.contrib.auth.middleware.AuthenticationMiddleware',    'django.contrib.messages.middleware.MessageMiddleware',    'django.middleware.clickjacking.XFrameOptionsMiddleware',    'md.middleware.M1',   ]