Django 模版高级进阶

plate1.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查询以及查询所耗费的时间。 这个列表是按照请求顺序进行排列的。由于调试信息比较敏感，所以这个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 设置。附录E提供了有关这两个设置的更多的信息。django.core.context_processors.request如果启用这个处理器，每个 RequestContext 将包含变量 request ， 也就是当前的 HttpRequest 对象。 注意这个处理器默认是不启用的，你需要激活它。如果你发现你的模板需要访问当前的HttpRequest你就需要使用它:{{ request.REMOTE_ADDR }}写Context处理器的一些建议编写处理器的一些建议：使每个context处理器完成尽可能小的功能。 使用多个处理器是很容易的，所以你可以根据逻辑块来分解功能以便将来复用。要注意 TEMPLATE_CONTEXT_PROCESSORS 里的context processor 将会在基于这个settings.py的每个 模板中有效，所以变量的命名不要和模板的变量冲突。 变量名是大小写敏感的，所以processor的变量全用大写是个不错的主意。不论它们存放在哪个物理路径下，只要在你的Python搜索路径中，你就可以在TEMPLATE_CONTEXT_PROCESSORS 设置里指向它们。 建议你把它们放在应用或者工程目录下名为context_processors.py 的文件里。html自动转义从模板生成html的时候，总是有一个风险——变量包了含会影响结果html的字符。 例如，考虑这个模板片段：Hello, {{ name }}.一开始，这看起来是显示用户名的一个无害的途径，但是考虑如果用户输入如下的名字将会发生什么：<script>alert('hello')</script>用这个用户名，模板将被渲染成：Hello, <script>alert('hello')</script>这意味着浏览器将弹出JavaScript警告框！类似的，如果用户名包含小于符号，就像这样：<b>username那样的话模板结果被翻译成这样：Hello, <b>username页面的剩余部分变成了粗体！显然，用户提交的数据不应该被盲目信任，直接插入到你的页面中。因为一个潜在的恶意的用户能够利用这类漏洞做坏事。 这类漏洞称为被跨域脚本 (XSS) 攻击。 关于安全的更多内容，请看20章为了避免这个问题，你有两个选择：一是你可以确保每一个不被信任的变量都被escape过滤器处理一遍，把潜在有害的html字符转换为无害的。 这是最初几年Django的默认方案，但是这样做的问题是它把责任推给你（开发者、模版作者）自己，来确保把所有东西转意。 很容易就忘记转意数据。二是，你可以利用Django的自动html转意。 这一章的剩余部分描述自动转意是如何工作的。在django里默认情况下，每一个模板自动转意每一个变量标签的输出。 尤其是这五个字符。< 自动转换为 <自动转换为 >' (单引号) 自动转换为 '" (双引号) 自动转换为 "& 自动转换为 &另外，我强调一下这个行为默认是开启的。 如果你正在使用django的模板系统，那么你是被保护的。如何关闭它如果你不