Django 模版高级进阶

想数据被自动转意，在每一站点级别、每一模板级别或者每一变量级别你都有几种方法来关闭它。为什么要关闭它？ 因为有时候模板变量包含了一些原始html数据，在这种情况下我们不想它们的内容被转意。 例如，你可能在数据库里存储了一段被信任的html代码，并且你想直接把它嵌入到你的模板里。 或者，你可能正在使用Django的模板系统生成非html文本，比如一封e-mail。对于单独的变量用safe过滤器为单独的变量关闭自动转意：This will be escaped: {{ data }}This will not be escaped: {{ data|safe }}你可以把_safe_当做_safe from further escaping_的简写，或者当做可以被直接译成HTML的内容。在这个例子里，如果数据包含''，那么输出会变成：This will be escaped: <b>This will not be escaped: 对于模板块为了控制模板的自动转意,用标签autoescape来包装整个模板(或者模板中常用的部分),就像这样：{% autoescape off %} Hello {{ name }}{% endautoescape %}autoescape 标签有两个参数on和off 有时,你可能想阻止一部分自动转意,对另一部分自动转意。 这是一个模板的例子：Auto-escaping is on by default. Hello {{ name }}{% autoescape off %} This will not be auto-escaped: {{ data }}. Nor this: {{ other_data }} {% autoescape on %} Auto-escaping applies again: {{ name }} {% endautoescape %}{% endautoescape %}auto-escaping 标签的作用域不仅可以影响到当前模板还可以通过include标签作用到其他标签,就像block标签一样。 例如：# base.html{% autoescape off %}<h1>{% block title %}{% endblock %}</h1>{% block content %}{% endblock %}{% endautoescape %}# child.html{% extends "base.html" %}{% block title %}This & that{% endblock %}{% block content %}{{ greeting }}{% endblock %}由于在base模板中自动转意被关闭,所以在child模板中自动转意也会关闭.因此,在下面一段HTML被提交时,变量greeting的值就为字符串Hello!<h1>This & that</h1><b>Hello!</b>备注通常,模板作者没必要为自动转意担心. 基于Pyhton的开发者(编写VIEWS视图和自定义过滤器)只需要考虑哪些数据不需要被转意,适时的标记数据,就可以让它们在模板中工作。如果你正在编写一个模板而不知道是否要关闭自动转意,那就为所有需要转意的变量添加一个escape过滤器。 当自动转意开启时，使用escape过滤器似乎会两次转意数据，但其实没有任何危险。因为escape过滤器不作用于被转意过的变量。过滤器参数里的字符串常量的自动转义就像我们前面提到的,过滤器也可以是字符串.{{ data|default:"This is a string literal." }}所有字符常量没有经过转义就被插入模板,就如同它们都经过了safe过滤。 这是由于字符常量完全由模板作者决定,因此编写模板的时候他们会确保文本的正确性。这意味着你必须这样写{{ data|default:"3 < 2" }}而不是这样{{ data|default:"3 < 2" }} <-- Bad! Don't do this.这点对来自变量本身的数据不起作用。 如果必要,变量内容会自动转义,因为它们不在模板作者的控制下。模板加载的内幕一般说来，你会把模板以文件的方式存储在文件系统中，但是你也可以使用自定义的 template loaders 从其他来源加载模板。Django有两种方法加载模板django.template.loader.get_template(template_name) ： get_template 根据给定的模板名称返回一个已编译的模板（一个 Template 对象）。 如果模板不存在，就触发 TemplateDoesNotExist 的异常。django.template.loader.select_template(template_name_list) ： select_template 很像get_template ，不过它是以模板名称的列表作为参数的。 它会返回列表中存在的第一个模板。 如果模板都不存在，将会触发TemplateDoesNotExist异常。正如在第四章中所提到的，默认情况下这些函数使用 TEMPLATE_DIRS 的设置来载入模板。 但是，在内部这些函数可以指定一个模板加载器来完成这些繁重的任务。一些加载器默认被禁用，但是你可以通过编辑 TEMPLATE_LOADERS 设置来激活它们。 TEMPLATE_LOADERS 应当是一个字符串的元组，其中每个字符串都表示一个模板加载器。 这些模板加载器随Django一起发布。django.template.loaders.filesystem.load_template_source : 这个加载器根据 TEMPLATE_DIRS 的设置从文件系统加载模板。它默认是可用的。django.template.loaders.app_directories.load_template_source : 这个加 载器从文件系统上的Django应用中加载模板。 对 INSTALLED_APPS 中的每个应用，这个加载器会查找templates 子目录。 如果这个目录存在，Django就在那里寻找模板。这意味着你可以把模板和你的应用一起保存，从而使得Django应用更容易和默认模板一起发布。 例如，如果 INSTALLED_APPS 包含 ('myproject.polls','myproject.music') ，那么 get_template('foo.html') 会按这个顺序查找模板：/path/to/myproject/polls/templates/foo.html/path/to/myproject/music/templates/foo.html请注意加载器在首次被导入的时候会执行一个优化： 它会缓存一个列表，这个列表包含了 INSTALLED_APPS中带有 templates 子目录的包。这个加载器默认启用。django.template.loaders.eggs.load_template_source : 这个加载器类似 app_directories ，只不过它从Python eggs而不是文件系统中加载模板。 这个加载器默认被禁用；如果你使用eggs来发布你的应用，那么你就需要启用它。 Python eggs可以将Python代码压缩到一个文件中。Django按照 TEMPLATE_LOADERS 设置中的顺序使用模板加载器。 它逐个使用每个加载器直至找到一个匹配的模板。扩展模板系统既然你已经对模板系统的内幕多了一些了解，让我们来看看如何使用自定义的代码来扩展这个系统吧。绝大部分的模板定制是以自定义标签/过滤器的方式来完成的。 尽管Django模板语言自带了许多内建标签和过滤器，但是你可能还是需要组建你自己的标签和过滤器库来满足你的需要。 幸运的是，定义你自己的功能非常容易。创建一个模板库不管是写自定义标签还是过滤器，第一件要做的事是创建模板库（Django能够导入的基本结构）。创建一个模板库分两步走：第一，决定模板库应该放在哪个Django应用下。 如果你通过 manage.py startapp 创建了一个应用，你可以把它放在那里，或者你可以为模