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

你需要一段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 }}

(0)

相关推荐

  • 在Django的通用视图中处理Context的方法

    制作友好的模板Context 你也许已经注意到范例中的出版商列表模板在变量 object_list 里保存所有的书籍.这个方法工作的很好,只是对编写模板的人不太友好. 他们必须知道这里正在处理的是书籍. 更好的变量名应该是publisher_list,这样变量所代表的内容就显而易见了. 我们可以很容易地像下面这样修改 template_object_name 参数的名称: from django.conf.urls.defaults import * from django.views.gene

  • Python的Django框架中的Context使用

    一旦你创建一个 Template 对象,你可以用 context 来传递数据给它. 一个context是一系列变量和它们值的集合. context在Django里表现为 Context 类,在 django.template 模块里. 她的构造函数带有一个可选的参数: 一个字典映射变量和它们的值. 调用 Template 对象 的 render() 方法并传递context来填充模板: >>> from django.template import Context, Template &

  • 在Django框架中编写Context处理器的方法

    写Context处理器的一些建议 编写处理器的一些建议: 使每个context处理器完成尽可能小的功能. 使用多个处理器是很容易的,所以你可以根据逻辑块来分解功能以便将来复用. 要注意 TEMPLATE_CONTEXT_PROCESSORS 里的context processor 将会在基于这个settings.py的每个 模板中有效,所以变量的命名不要和模板的变量冲突. 变量名是大小写敏感的,所以processor的变量全用大写是个不错的主意. 不论它们存放在哪个物理路径下,只要在你的Pyth

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

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

  • 详解Django模版中加载静态文件配置方法

    1.settings.INSTALLED_APPS下添加:django.contrib.staticfiles 2.settings.py下添加:STATIC_URL = '/static/' 3. (1)在APP下新建文件夹static,然后在这个static文件夹下创建一个当前APP的名字的文件夹,再把静态文件放到这个文件夹下:(类似于Templates配置) 在模板中这样调用: {% load static %} <img src="{% static 'front/logo.jpg

  • 详解django使用include无法跳转的解决方法

    一般的django项目我都喜欢采用以下的文件结构,使用include的方式,实现从总的url分配给apps里面的url Example: -projtect ---apps -----user -------urls.py -urls.py 但突然发现无法跳转,竟然是总url的这个错误! 以下是错误做法 urlpatterns = [ url(r'^admin/', admin.site.urls), url(r'^', views.Index.as_view(), name='index'),

  • 详解Django框架中用户的登录和退出的实现

    Django 提供内置的视图(view)函数用于处理登录和退出 (以及其他奇技淫巧),但在开始前,我们来看看如何手工登录和退出. Django提供两个函数来执行django.contrib.auth\中的动作 : authenticate()和login(). 认证给出的用户名和密码,使用 authenticate() 函数.它接受两个参数,用户名 username 和 密码 password ,并在密码对给出的用户名合法的情况下返回一个 User 对象. 如果密码不合法,authenticat

  • 详解Django框架中的视图级缓存

    更加颗粒级的缓存框架使用方法是对单个视图的输出进行缓存. django.views.decorators.cache定义了一个自动缓存视图响应的cache_page装饰器. 他是很容易使用的: from django.views.decorators.cache import cache_page def my_view(request): # ... my_view = cache_page(my_view, 60 * 15) 也可以使用Python2.4的装饰器语法: @cache_page

  • 详解C++编程中用数组名作函数参数的方法

    C++数组的概念 概括地说:数组是有序数据的集合.要寻找一个数组中的某一个元素必须给出两个要素,即数组名和下标.数组名和下标惟一地标识一个数组中的一个元素. 数组是有类型属性的.同一数组中的每一个元素都必须属于同一数据类型.一个数组在内存中占一片连续的存储单元.如果有一个整型数组a,假设数组的起始地址为2000,则该数组在内存中的存储情况如图所示. 引入数组就不需要在程序中定义大量的变量,大大减少程序中变量的数量,使程序精炼,而且数组含义清楚,使用方便,明确地反映了数据间的联系.许多好的算法都与

  • 详解Django中views数据查询使用locals()函数进行优化

    优化场景 利用视图函数(views)查询数据之后可以通过上下文context.字典.列表等方式将数据传递给HTML模板,由template引擎接收数据并完成解析.但是通过context传递数据可能就存在在不同的视图函数中使用重复的查询语句,所以可以通过将重复查询语句设置全局变量,配合locals()函数进行数据查询与传递. 优化前 def index(request): threatname = '威胁情报展示' url = 'www.testtip.com' allthreat = Threa

  • 详解Laravel框架的依赖注入功能

    概述 任何时候,你在一个控制器类中请求一个依赖,这个服务容器负责: 1.自动地在构造函数中检测依赖关系 2.如果需要构建这个依赖关系 3.通过构造函数创建对象形成依赖关系 来看一个非常简单的例子. <?php namespace App\Http\Controllers; use App\User; use App\Repositories\UserRepository; use App\Http\Controllers\Controller; class UserController exte

  • 详解Android框架MVVM分析以及使用

    Android MVVM 分析以及使用 首先我们需要知道什么是MVVM,他的功能和优点,以及他的缺点. MVVM是Model-View-ViewModel的简写.它本质上就是MVC 的改进版.MVVM 就是将其中的View 的状态和行为抽象化,让我们将视图 UI 和业务逻辑分开.当然这些事 ViewModel 已经帮我们做了,它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑.微软的WPF带来了新的技术体验,如Silverlight.音频.视频.3D.动画-

  • 详解Spring框架入门

    一.什么是Spring Spring框架是由于软件开发的复杂性而创建的.Spring使用的是基本的JavaBean来完成以前只可能由EJB完成的事情.然而,Spring的用途不仅仅限于服务器端的开发.从简单性.可测试性和松耦合性角度而言,绝大部分Java应用都可以从Spring中受益.Spring是一个轻量级控制反转(IoC)和面向切面(AOP)的容器框架. ◆目的:解决企业应用开发的复杂性 ◆功能:使用基本的JavaBean代替EJB,并提供了更多的企业应用功能 ◆范围:任何Java应用 二.

随机推荐