详解Django框架中用context来解析模板的方法


Posted in Python onJuly 20, 2015

你需要一段context来解析模板。 一般情况下,这是一个 django.template.Context 的实例,不过在Django中还可以用一个特殊的子类, django.template.RequestContext ,这个用起来稍微有些不同。 RequestContext 默认地在模板context中加入了一些变量,如 HttpRequest 对象或当前登录用户的相关信息。

当你不想在一系例模板中都明确指定一些相同的变量时,你应该使用 RequestContext 。 例如,考虑这两个视图:

from django.template import loader, Context

def view_1(request):
  # ...
  t = loader.get_template('template1.html')
  c = Context({
    'app': 'My app',
    'user': request.user,
    'ip_address': request.META['REMOTE_ADDR'],
    'message': 'I am view 1.'
  })
  return t.render(c)

def view_2(request):
  # ...
  t = loader.get_template('template2.html')
  c = Context({
    'app': 'My app',
    'user': request.user,
    'ip_address': request.META['REMOTE_ADDR'],
    'message': 'I am the second view.'
  })
  return t.render(c)

(注意,在这些例子中,我们故意 不 使用 render_to_response() 这个快捷方法,而选择手动载入模板,手动构造context对象然后渲染模板。 是为了能够清晰的说明所有步骤。)

每个视图都给模板传入了三个相同的变量:app、user和ip_address。 如果我们把这些冗余去掉会不会更好?

创建 RequestContext 和 context处理器 就是为了解决这个问题。 Context处理器允许你设置一些变量,它们会在每个context中自动被设置好,而不必每次调用 render_to_response() 时都指定。 要点就是,当你渲染模板时,你要用 RequestContext 而不是 Context 。

最直接的做法是用context处理器来创建一些处理器并传递给 RequestContext 。上面的例子可以用context processors改写如下:

from django.template import loader, RequestContext

def custom_proc(request):
  "A context processor that provides 'app', 'user' and 'ip_address'."
  return {
    'app': 'My app',
    'user': request.user,
    'ip_address': request.META['REMOTE_ADDR']
  }

def view_1(request):
  # ...
  t = loader.get_template('template1.html')
  c = RequestContext(request, {'message': 'I am view 1.'},
      processors=[custom_proc])
  return t.render(c)

def view_2(request):
  # ...
  t = loader.get_template('template2.html')
  c = RequestContext(request, {'message': 'I am the second view.'},
      processors=[custom_proc])
  return t.render(c)

我们来通读一下代码:

    首先,我们定义一个函数 custom_proc 。这是一个context处理器,它接收一个 HttpRequest 对象,然后返回一个字典,这个字典中包含了可以在模板context中使用的变量。 它就做了这么多。

    我们在这两个视图函数中用 RequestContext 代替了 Context 。在context对象的构建上有两个不同点。 一, RequestContext 的第一个参数需要传递一个 HttpRequest 对象,就是传递给视图函数的第一个参数( request )。二, RequestContext 有一个可选的参数 processors ,这是一个包含context处理器函数的列表或者元组。 在这里,我们传递了我们之前定义的处理器函数 curstom_proc 。

    每个视图的context结构里不再包含 app 、 user 、 ip_address 等变量,因为这些由 custom_proc 函数提供了。

    每个视图 仍然 具有很大的灵活性,可以引入我们需要的任何模板变量。 在这个例子中, message 模板变量在每个视图中都不一样。

 为了讲解context处理器底层是如何工作的,在上面的例子中我们没有使用 render_to_response() 。但是建议选择 render_to_response() 作为context的处理器。这就需要用到context_instance参数:

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

def custom_proc(request):
  "A context processor that provides 'app', 'user' and 'ip_address'."
  return {
    'app': 'My app',
    'user': request.user,
    'ip_address': request.META['REMOTE_ADDR']
  }

def view_1(request):
  # ...
  return render_to_response('template1.html',
    {'message': 'I am view 1.'},
    context_instance=RequestContext(request, processors=[custom_proc]))

def view_2(request):
  # ...
  return render_to_response('template2.html',
    {'message': 'I am the second view.'},
    context_instance=RequestContext(request, processors=[custom_proc]))

在这,我们将每个视图的模板渲染代码写成了一个单行。

虽然这是一种改进,但是,请考虑一下这段代码的简洁性,我们现在不得不承认的是在 另外 一方面有些过分了。 我们以代码冗余(在 processors 调用中)的代价消除了数据上的冗余(我们的模板变量)。 由于你不得不一直键入 processors ,所以使用context处理器并没有减少太多的输入量。

Django因此提供对 全局 context处理器的支持。 TEMPLATE_CONTEXT_PROCESSORS 指定了哪些context processors总是默认被使用。这样就省去了每次使用 RequestContext 都指定 processors 的麻烦。

默认情况下, TEMPLATE_CONTEXT_PROCESSORS 设置如下:

TEMPLATE_CONTEXT_PROCESSORS = (
  'django.core.context_processors.auth',
  'django.core.context_processors.debug',
  'django.core.context_processors.i18n',
  'django.core.context_processors.media',
)

这个设置项是一个可调用函数的元组,其中的每个函数使用了和上文中我们的 custom_proc 相同的接口,它们以request对象作为参数,返回一个会被合并传给context的字典: 接收一个request对象作为参数,返回一个包含了将被合并到context中的项的字典。

每个处理器将会按照顺序应用。 也就是说如果你在第一个处理器里面向context添加了一个变量,而第二个处理器添加了同样名字的变量,那么第二个将会覆盖第一个。

Django提供了几个简单的context处理器,有些在默认情况下被启用的。

django.core.context_processors.auth

如果 TEMPLATE_CONTEXT_PROCESSORS 包含了这个处理器,那么每个 RequestContext 将包含这些变量:
  •     user :一个 django.contrib.auth.models.User 实例,描述了当前登录用户(或者一个 AnonymousUser 实例,如果客户端没有登录)。
  •     messages :一个当前登录用户的消息列表(字符串)。 在后台,对每一个请求,这个变量都调用 request.user.get_and_delete_messages() 方法。 这个方法收集用户的消息然后把它们从数据库中删除。
  •     perms : django.core.context_processors.PermWrapper 的一个实例,包含了当前登录用户有哪些权限。

关于users、permissions和messages的更多内容请参考第14章。
django.core.context_processors.debug

这个处理器把调试信息发送到模板层。 如果TEMPLATE_CONTEXT_PROCESSORS包含这个处理器,每一个RequestContext将包含这些变量:

  •     debug :你设置的 DEBUG 的值( True 或 False )。你可以在模板里面用这个变量测试是否处在debug模式下。
  •     sql_queries :包含类似于 ``{‘sql': …, ‘time': `` 的字典的一个列表, 记录了这个请求期间的每个SQL查询以及查询所耗费的时间。 这个列表是按照请求顺序进行排列的。
  •     System Message: WARNING/2 (<string>, line 315); backlink
  •     Inline literal start-string without end-string.
  • 由于调试信息比较敏感,所以这个context处理器只有当同时满足下面两个条件的时候才有效:
  •     DEBUG 参数设置为 True 。
  •     请求的ip应该包含在 INTERNAL_IPS 的设置里面。

细心的读者可能会注意到debug模板变量的值永远不可能为False,因为如果DEBUG是False,那么debug模板变量一开始就不会被RequestContext所包含。
django.core.context_processors.i18n

如果这个处理器启用,每个 RequestContext 将包含下面的变量:

  •     LANGUAGES : LANGUAGES 选项的值。
  •     LANGUAGE_CODE :如果 request.LANGUAGE_CODE 存在,就等于它;否则,等同于 LANGUAGE_CODE 设置。

django.core.context_processors.request

如果启用这个处理器,每个 RequestContext 将包含变量 request , 也就是当前的 HttpRequest 对象。 注意这个处理器默认是不启用的,你需要激活它。

如果你发现你的模板需要访问当前的HttpRequest你就需要使用它:

{{ request.REMOTE_ADDR }}

Python 相关文章推荐
python列表生成式与列表生成器的使用
Feb 23 Python
python实现遍历文件夹修改文件后缀
Aug 28 Python
利用Python正则表达式过滤敏感词的方法
Jan 21 Python
详解Python3 对象组合zip()和回退方式*zip
May 15 Python
Tensorflow模型实现预测或识别单张图片
Jul 19 Python
python3.7 的新特性详解
Jul 25 Python
flask/django 动态查询表结构相同表名不同数据的Model实现方法
Aug 29 Python
python+Django实现防止SQL注入的办法
Oct 31 Python
python实现QQ邮箱发送邮件
Mar 06 Python
Windows 平台做 Python 开发的最佳组合(推荐)
Jul 27 Python
python如何遍历指定路径下所有文件(按按照时间区间检索)
Sep 14 Python
Pandas实现批量拆分与合并Excel的示例代码
May 30 Python
Django中URLconf和include()的协同工作方法
Jul 20 #Python
在Python的Django框架中包装视图函数
Jul 20 #Python
Django中URL视图函数的一些高级概念介绍
Jul 20 #Python
Python的Django框架中从url中捕捉文本的方法
Jul 20 #Python
Django框架中处理URLconf中特定的URL的方法
Jul 20 #Python
在Django中创建URLconf相关的通用视图的方法
Jul 20 #Python
python通过socket查询whois的方法
Jul 18 #Python
You might like
PHP实现网上点歌(二)
2006/10/09 PHP
php报表之jpgraph柱状图实例代码
2011/08/22 PHP
Window下PHP三种运行方式图文详解
2013/06/11 PHP
PHP缓存机制Output Control详解
2014/07/14 PHP
jQuery基础知识filter()和find()实例说明
2010/07/06 Javascript
JsDom 编程小结
2011/08/09 Javascript
Js制作简单弹出层DIV在页面居中 中间显示遮罩的具体方法
2013/08/08 Javascript
jquery防止重复执行动画避免页面混乱
2014/04/22 Javascript
分享2个jQuery插件--jquery.fileupload与artdialog
2014/12/26 Javascript
JS实现文档加载完成后执行代码
2015/07/09 Javascript
基于ajax实现文件上传并显示进度条
2015/08/03 Javascript
JavaScript实现动态删除列表框值的方法
2015/08/12 Javascript
js实现超简单的展开、折叠目录代码
2015/08/28 Javascript
每天一篇javascript学习小结(Date对象)
2015/11/13 Javascript
jQuery配合coin-slider插件制作幻灯片效果的流程解析
2016/05/13 Javascript
Ajax分页插件Pagination从前台jQuery到后端java总结
2016/07/22 Javascript
详解获取jq ul第一个li定位的四种解决方案
2016/11/23 Javascript
JavaScript中Math对象的方法介绍
2017/01/05 Javascript
tablesorter.js表格排序使用方法(支持中文排序)
2017/02/10 Javascript
js实现截图保存图片功能的代码示例
2017/02/16 Javascript
vue-cli+webpack在生成的项目中使用bootstrap实例代码
2017/05/26 Javascript
5 种JavaScript编码规范
2018/01/30 Javascript
jQuery实现消息弹出框效果
2019/12/10 jQuery
关于引入vue.js 文件的知识点总结
2020/01/28 Javascript
python网络编程之TCP通信实例和socketserver框架使用例子
2014/04/25 Python
编程语言Python的发展史
2014/09/26 Python
Python内置函数——__import__ 的使用方法
2017/11/24 Python
浅谈Python基础—判断和循环
2019/03/22 Python
Python通过fnmatch模块实现文件名匹配
2020/09/30 Python
CSS3 filter(滤镜)实现网页灰色或者黑色模式的示例代码
2021/02/24 HTML / CSS
Ejb技术面试题
2015/04/29 面试题
致共产党员倡议书
2014/04/16 职场文书
教师业务培训方案
2014/05/01 职场文书
2015年街道除四害工作总结
2015/05/15 职场文书
公司环境卫生管理制度
2015/08/05 职场文书
Win11如何查看显卡型号 Win11查看显卡型号的方法
2022/08/14 数码科技