Django | RequestContext 和 Context

版本

django 1.8.3

简述

一般我们在练习 django 渲染时，都需要使用 context 来解析渲染模板。
通常，context 是 django.template.Context 的实例，不过在 context 中还有一个特殊的子类， django.template.RequestContext ，这个和 context 稍微有些不同。 RequestContext 默认地在模板 context 中添加一些变量

使用 Context

from django.template import Context
c = Context({
    'foo': 'bar',
})

使用 RequestContext

RequestContext 使用 HttpRequest 作为第一个参数

from django.template import RequestContext
c = RequestContext(request, {
    'foo': 'bar',
})

其实到这里，对于作者起了个 RequestContext 名字，鄙人有些不敢苟同，对于开发人员很容易造成误解，个人以为应该为 WrapperContext(纯属个人意见)

应用场景

最熟悉的场景就是配置文件中设置的 context_processors

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [os.path.join(os.path.dirname(os.path.abspath(__file__)), '../../templates/')],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.contrib.auth.context_processors.auth',
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.template.context_processors.static',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

BaseView 中默认把 context_processors 指定的变量包装到 RequestContext, 这时最常见的应用了，但是也有一定的弊端，就是所有的 View 中都会包含这些变量；

如果想避免这个坑，可以根据业务需要，自己自定义，这样哪里有需求，哪里就加载

from django.shortcuts import render_to_response
from django.template import RequestContext

def custom_proc(request):
    return {
        'name': 'haha',
        'sex': 'man'
    }

def viewA(request):
    return render_to_response('tmpl1.html',
        {'name': 'viewA'},
        context_instance=RequestContext(request, processors=[custom_proc]))

def viewB(request):
    return render_to_response('tmpl2.html',
        {'name': 'viewB'},
        context_instance=RequestContext(request, processors=[custom_proc]))

这样做也是有弊端，不方便使用 BaseView, 还有如果重复次数太多，也不建议这样做

待续.....