Django模板系统详解

标签：

你可能已经注意到我们在例子视图中返回文本的方式有点特别。也就是说，HTML被硬性地直接写入 Python代码之中。

这种处理会导致一些问题：

§ 对页面设计的进行任何改变都必须对 Python代码进行相应的修改。站点设计的修改往往比底层Python 代码的修改要频繁得多，因此如果可以在不进行 Python代码修改的情况下变更设计，那将会方便得多。

§ Python代码编写和 HTML 设计是两项不同的工作，大多数专业的网站开发环境都将他们分配给不同的人员（甚至不同部门）来完成。设计人员和 HTML/CSS编写人员都不应该通过编辑 Python代码来完成自己的工作；他们应该处理的是 HTML。

§ 同理，程序员编写 Python代码和设计人员制作模板同时进行的工作方式效率是最高的，远胜于让一个人等待另一个人完成对某个既包含 Python又包含 HTML 的文件的编辑工作。

基于这些原因，将页面的设计和Python的代码分离开会更干净简洁更容易维护。我们可以使用 Django的模板系统(Template System)来实现这种模式，这就是本章要具体讨论的问题。

模板系统基本知识

Django 模板是用于分割文档的表示(presentation)和数据(data)的字符串文本。模板定义了占位符(placeholders)和各种定义文档应该如何显示的基本逻辑（即模板标签，template tag）。通常，模板用来生成 HTML，但是 Ddjango模板同样能够生成任何基于文本的格式。

让我们深入分析一个简单的例子模板。该模板描述了一个向某个与公司签单人员致谢 HTML页面。可将其视为一个格式信函：

该模板是一段添加了些许变量和模板标签的基础 HTML。让我们逐句过一遍：

用两个大括号括起来的文字（例如{{ person_name }}）是变量(variable)。这意味着将按照给定的名字插入变量的值。如何指定变量的值呢？稍后就会说明。

被大括号和百分号包围的文本(例如{% if ordered_warranty %})是模板标签(template tag)。标签(tag)定义比较明确，即：仅通知模板系统完成某些工作的标签。

这个示例模板包含两个标签(tag):{% for item in item_list %}标签(一个for标签)和{% if ordered_warranty %}标签 (一个if标签)。

for标签用于构建简单的循环，允许你遍历循环中的每一项。if标签，正如你所料，是用来执行逻辑判断的。在这个例子中标签检测ordered_warranty变量值是否为True。如果是，模板系统将显示{% if ordered_warranty %}与{% endif %}之间的所有内容。如果不是模板系统不会显示它。它当然也支持{% else %}以及其他多种逻辑判断方式。

最后，这个模板的第二段落有一个filter 过滤器的例子,它能让你用来转换变量的输出，在这个例子中,{{ship_date|date:"F j, Y" }}将变量ship_date用date过滤器来转换,转换的参数是"F j, Y".date过滤器根据指定的参数进行格式输出.过滤器是用管道字符(|)来调用的,就和Unix管道一样.

Django 模板含有很多内置的tags和filters,我们将陆续进行学习.附录F列出了很多的tags和filters的列表,熟悉这些列表对你来说是个好建议.学习完第十章，你就明白怎么去创建自己的filters和tags了.

如何使用模板系统

想要在Python代码中使用模板系统，只需遵循下面两个步骤：

1. 可以用原始的模板代码字符串创建一个Template对象， Django同样支持用指定模板文件路径的方式创建来Template对象;

2. 调用Template对象的render()方法并提供给他变量(i.e.,内容). 它将返回一个完整的模板字符串内容,包含了所有标签块与变量解析后的内容.

以下部分逐步的详细介绍

创建模板对象

创建一个Template对象最简单的方法就是直接实例化它。Template类就在django.template模块中，构造函数接受一个参数，原始模板代码。让我们深入挖掘一下 Python的解释器看看它是怎么工作的。

交互式示例

在本书中，我们喜欢用和Python解释器的交互来举例。你可以通过三个> (>>>)识别它们，它们相当于Python解释器的提示符。如果你要拷贝例子，请不要拷贝这3个>字符。

多行语句则在前面加了3个小数点(...)，例如：

这3个点是Python解释器自动加入的，不需要你的输入。我们包含它们是为了忠实呈现解释器的真实输出。同样道理，拷贝时不要拷贝这3个小数点符号。

转到project目录（在第二章用django-admin.py startproject命令创建），输入命令python manage.py shell启动交互界面。下面是一些基本操作：

如果你跟我们一起做，你将会看到下面的内容：

0xb7d5f24c每次都会不一样，这没什么关系；这只是Python运行时Template对象的ID。

Django 设置

当你使用Django时，你需要告诉Django使用哪个配置。在交互模式下，通常运行命令python manage.py shell来做这个，附录E里还有一些其他的一些选项。

当你创建一个Template对象，模板系统在内部编译这个模板到内部格式，并做优化，做好渲染的准备。如果你的模板语法有错误，那么在调用Template()时就会抛出TemplateSyntaxError异常：

系统会在下面的情形抛出TemplateSyntaxError异常：

§ 无效的块标签

§ 无效的参数

§ 无效的过滤器

§ 过滤器的参数无效

§ 无效的模板语法

§ 未封闭的块标签（针对需要封闭的块标签）

模板渲染

一旦你创建一个Template对象，你可以用context 来传递数据给它。一个context是一系列变量和它们值的集合。模板使用它来赋值模板变量标签和执行块标签。

context在Django里表现为Context类，在django.template模块里。它构造是有一个可选参数：一个字典映射变量和它们的值。调用Template对象的render()方法并传递context来填充模板：

字典和Contexts

Python的字典数据类型就是关键字和它们值的一个映射。Context和字典很类似，Conetxt还提供更多的功能，请看第十章。

变量名必须由英文字符开始（A-Z或a-z）并可以包含数字字符、下划线和小数点。（小数点在这里有特别的用途，稍后我们会讲到）变量是大小写敏感的。

下面是编写模板并渲染的示例：

让我们逐句看看这段代码：

首先我们导入（import）类Template和Context，它们都在模块django.template里。

我们把模板原始文本保存到变量raw_template。注意到我们使用了三个引号来标识这些文本，因为这样可以包含多行。这是Python的一个语法。

接下来，我们创建了一个模板对象t，把raw_template作为Template类的构造的参数。

我们从Python的标准库导入datetime模块，以后我们将会使用它。

然后，我们创建一个Context对象，c。Context构造的参数是Python字典数据类型，在这里，我们给的参数是person_name值为‘John Smith‘,product值为‘Super Lawn Mower‘，等等。

最后，我们在模板对象上调用render()方法，传递 context参数给它。这是返回渲染后的模板的方法，它会替换模板变量为真实的值和执行块标签。

注意，warranty paragraph显示是因为ordered_warranty的值为True.注意时间的显示，April 2, 2009,它是按‘F j, Y‘格式显示的。（我们很快就会在date过滤器解释这些格式）

如果你是Python初学者，你可能在想为什么输出里有回车换行的字符(‘\n‘)而不是显示回车换行？因为这是Python交互解释器的缘故：调用t.render(c)返回字符串，解释器缺省显示这些字符串的真实内容呈现，而不是打印这个变量的值。要显示换行而不是‘\n‘，使用print语句：print t.render(c)。

这就是使用Django模板系统的基本规则：写模板，创建Template对象，创建Context，调用render()方法。

同一模板，多个上下文

一旦有了模板对象，你就可以通过它渲染多个背景（context），例如：

无论何时像这样使用同一模板源渲染多个背景，只创建一次模板对象，然后对它多次调用render()将会更加高效。

Django 模板解析非常快捷。大部分的解析工作都是在后台通过对简短正则表达式一次性调用来完成。这和基于 XML的模板引擎形成鲜明对比，那些引擎承担了 XML解析器的开销，且往往比 Django模板渲染引擎要慢上几个数量级。

背景变量的查找

在到目前为止的例子中，我们通过 context传递的简单参数值主要是字符串，还有一个datetime.date范例。然而，模板系统能够非常简洁地处理更加复杂的数据结构，例如list、dictionary和自定义的对象。

在 Django模板中遍历复杂数据结构的关键是句点字符 (.)。使用句点可以访问字典的键值、属性、索引和对象的方法。

最好是用几个例子来说明一下。比如，假设你要向模板传递一个 Python字典。要通过字典键访问该字典的值，可使用一个句点：

同样，也可以通过句点来访问对象的属性。比方说，Python 的datetime.date对象有year、month和day几个属性，你同样可以在模板中使用句点来访问这些属性：

下例使用了一个自定义类：

句点还用于调用对象的方法。例如，每个 Python字符串都有upper()和isdigit()方法，你在模板中可以使用同样的句点语法来调用它们：

注意你不能在方法调用中使用圆括号。而且也无法给该方法传递参数；你只能调用不需参数的方法。（我们将在本章稍后部分解释该设计观。）

最后，句点也可用于访问列表索引，例如：

不允许使用负数列表索引。像{{ items.-1 }}这样的模板变量将会引发

TemplateSyntaxError异常。

Python 列表类型

Python列表类型的索引是从0开始的，第一个元素的索引是0，第二个是1，以此类推。

句点查找规则可概括为：当模板系统在变量名中遇到点时，按照以下顺序尝试进行查找：

§ 字典类型查找（比如foo["bar"])

§ 属性查找 (比如foo.bar)

§ 方法调用（比如foo.bar())

§ 列表类型索引查找 (比如foo[bar])

系统使用所找到的第一个有效类型。这是一种短路逻辑。

句点查找可以多级深度嵌套。例如在下面这个例子中{{person.name.upper}}会转换成字典类型查找（person[‘name‘])然后是方法调用（upper()):

方法调用行为

方法调用比其他类型的查找略为复杂一点。以下是一些注意事项：

在方法查找过程中，如果某方法抛出一个异常，除非该异常有一个silent_variable_failure属性并且值为True，否则的话它将被传播。如果该异常确有属性silent_variable_failure，那么（所查找）变量将被渲染为空字符串，例如：

仅在方法无需传入参数时，其调用才有效。否则，系统将会转移到下一个查找类型（列表索引查找）。

显然，有些方法是有副作用的，好的情况下允许模板系统访问它们可能只是干件蠢事，坏的情况下甚至会引发安全漏洞。

例如，你的一个BankAccount对象有一个delete()方法。不应该允许模板包含像{{account.delete}}这样的方法调用。

要防止这样的事情发生，必须设置该方法的alters_data函数属性：

模板系统不会执行任何以该方式进行标记的方法。也就是说，如果模板包含了{{account.delete}},该标签不会调用delete()方法。它只会安静地失败（并不会引发异常）。

如何处理无效变量

默认情况下，如果一个变量不存在，模板系统会把它展示为空字符串，不做任何事情地表示失败，例如：

系统静悄悄地表示失败，而不是引发一个异常，因为这通常是人为错误造成的。这种情况下，因为变量名有错误的状况或名称，所有的查询都会失败。现实世界中，对于一个web站点来说，如果仅仅因为一个小的模板语法错误而造成无法访问，这是不可接受的。

注意，我们是可以有机会通过更改Django的配置以在这点上改变Django的默认行为的。我们会在第10章进行进一步的讨论的。

玩一玩上下文(context)对象

多数时间，你可以通过传递一个完全填充(full populated)的字典给Context()来初始化上下文(Context)。但是初始化以后，你也可以从``上下文(Context)``对象添加或者删除条目，使用标准的Python字典语法(syntax):

基本的模板标签和过滤器

像我们以前提到过的，模板系统带有内置的标签和过滤器。下面的章节提供了一个多数通用标签和过滤器的简要说明。

标签

if/else

{% if %}标签检查(evaluate)一个变量，如果这个变量为真（即，变量存在，非空，不是布尔值假），系统会显示在{% if %}和{% endif %}之间的任何内容，例如：

{% else %}标签是可选的：

Python 的“真值”

在python中空的列表 ([])，tuple(())，字典({})，字符串(‘‘)，零(0)，还有None对象，在逻辑判断中都为假，其他的情况都为真。

{% if %}标签接受and，or或者not关键字来对多个变量做判断，或者对变量取反（not)，例如：

{% if %}标签不允许在同一个标签中同时使用and和or，因为逻辑上可能模糊的，例如，如下示例是错误的：

系统不支持用圆括号来组合比较操作。如果你发现需要组合操作，你可以考虑用逻辑语句来简化模板的处理。例如，你需要组合and和or做些复杂逻辑判断，可以使用嵌套的{% if %}标签，示例如下：

多次使用同一个逻辑操作符是没有问题的，但是我们不能把不同的操作符组合起来。比如这样的代码是没问题的：

并没有{% elif %}标签，请使用嵌套的{% if %}标签来达成同样的效果：

一定要用{% endif %}关闭每一个{% if %}标签。否则Django会抛出TemplateSyntaxError。

for

{% for %}允许我们在一个序列上迭代。与Python的for语句的情形类似，循环语法是for X in Y，Y是要迭代的序列而X是在每一个特定的循环中使用的变量名称。每一次循环中，模板系统会渲染在{% for %}and{% endfor %}中的所有内容。

例如，给定一个运动员列表athlete_list变量，我们可以使用下面的代码来显示这个列表：

给标签增加一个reversed使得该列表被反向迭代：

可以嵌套使用{% for %}标签：

Django不支持退出循环操作。如果我们想退出循环，可以改变正在迭代的变量，让其仅仅包含需要迭代的项目。同理，Django也不支持continue语句，我们无法让当前迭代操作跳回到循环头部。（请参看本章稍后的理念和限制小节，了解下决定这个设计的背后原因）

{% for %}标签在循环中设置了一个特殊的forloop模板变量。这个变量能提供一些当前循环进展的信息：

forloop.counter总是一个表示当前循环的执行次数的整数计数器。这个计数器是从1开始的，所以在第一次循环时forloop.counter将会被设置为1。例子如下：

forloop.counter0类似于forloop.counter，但是它是从0计数的。第一次执行循环时这个变量会被设置为0。

forloop.revcounter是表示循环中剩余项的整型变量。在循环初次执行时forloop.revcounter将被设置为序列中项的总数。最后一次循环执行中，这个变量将被置1。

forloop.revcounter0类似于forloop.revcounter，但它是以0为起始坐标的。在第一次执行循环时，该变量会被置为序列的项的个数减1。在最后一次迭代时，该变量为0。

forloop.first是一个布尔值。在第一次执行循环时该变量为True，在下面的情形中这个变量是很有用的。

forloop.last是一个布尔值；在最后一次执行循环时被置为True。一个常见的用法是在一系列的链接之间放置管道符（|）

forloop.parentloop是一个指向当前循环的上一级循环的forloop对象的引用（在嵌套循环的情况下）。例子在此：

forloop变量仅仅能够在循环中使用，在模板解析器碰到{% endfor %}标签时，forloop就不可访问了。

Context和forloop变量

在一个{% for %}块中，已存在的变量会被移除，以避免forloop变量被覆盖。Django会把这个变量移动到forloop.parentloop中。通常我们不用担心这个问题，但是一旦我们在模板中定义了forloop这个变量（当然我们反对这样做），在{% for %}块中它会在forloop.parentloop被重新命名。

ifequal/ifnotequal

Django模板系统压根儿就没想过实现一个全功能的编程语言，所以它不允许我们在模板中执行Python的语句（还是那句话，要了解更多请参看理念和限制小节）。但是比较两个变量的值并且显示一些结果实在是个太常见的需求了，所以Django提供了{% ifequal %}标签供我们使用。

{% ifequal %}标签比较两个值，当他们相同时，显示在{% ifequal %}和{% endifequal %}之中所有的值。

下面的例子比较两个模板变量user和currentuser:

参数可以是硬编码的字符串，随便用单引号或这双引号引起来，所以下列代码都是正确的：

和{% if %}类似，{% ifequal %}支持可选的{% else%}标签：

只有模板变量，字符串，整数和小数可以作为{% ifequal %}标签的参数。这些是正确的例子：

其他的一些类型，例如Python的字典类型、列表类型、布尔类型，不能用在{% ifequal %}中。下面是些错误的例子：

如果你需要判断变量是真还是假，请使用{% if %}来替代{% ifequal %}。

注释

象HTML和其他的语言例如python一样，Django模板系统也允许注释。注释使用{# #}：

注释的内容不会在模板渲染时输出。

注释不能跨多行。这个限制是为了提高模板解析的性能。在下面这个模板中，输出结果和模板本身是完全一样的（也就是说，注释标签并没有被解析为注释）：

过滤器

就象本章前面提到的一样，模板过滤器是在变量被显示前修改它的值的一个简单方法。过滤器看起来是这样的：

显示的内容是变量{{ name }}被过滤器lower处理后的结果，它功能是转换文本为小写。使用|来应用过滤器。

过滤器可以被串联,就是说一个过滤器的输出可以被输入到下一个过滤器。这里有一个常用的需求，先转义文本到HTML，再转换每行到<p>标签：

有些过滤器有参数。过滤器参数看起来是这样的：

这个将显示变量bio的前30个词。过滤器参数总是使用双引号标识。

下面是一些最重要的过滤器；附录F有完整的过滤器列表。

addslashes:添加反斜杠到任何反斜杠、单引号或者双引号前面。这在处理包含JavaScript的文本时是非常有用的。

date:按指定的格式字符串参数格式化date或者datetime对象，范例：

格式参数的定义在附录F中。

escape:转义 &符号，引号，<，>符号。这在确保用户提交的数据是有效的XML或XHTML时是非常有用的。具体上，escape做下面这些转换:

§ 转换&到&amp;

§ 转换<到&lt;

§ 转换>到&gt;

§ 转换"(双引号)到&quot;

§ 转换‘(单引号)到&#39;

length:返回变量的长度。你可以对列表或者字符串，或者任何知道怎么测定长度的Python对象使用这个方法（也就是说，有__len__()方法的对象）。

理念与局限

现在你已经对Django的模板语言有一些认识了，我们将指出一些特意设置的限制和为什么要这样做背后的一些设计哲学。

相对Web应用中的其他组件，程序员们对模板系统的分歧是最大的。事实上，Python有成十上百的开放源码的模板语言实现。每个实现都是因为开发者认为现存的模板语言不够用。（事实上，对一个 Python开发者来说，写一个自己的模板语言就象是某种“成人礼”一样！如果你还没有完成一个自己的模板语言，好好考虑写一个，这是一个非常有趣的锻炼。）

明白了这个，你也许有兴趣知道事实上Django并不强制要求你必须使用它的模板语言。因为Django虽然被设计成一个FULL-Stack的Web框架，它提供了开发者所必需的所有组件，而且在大多数情况使用Django模板系统会比其他的Python模板库要更方便一点，但是并不是严格要求你必须使用它。就象你将在后续的章节中看到的一样，你也可以非常容易的在Django中使用其他的模板语言。

虽然如此，很明显，我们对Django模板语言的工作方式有着强烈的偏爱。这个模板语言来源于Worl Online的开发经验和Django创造者们集体智慧的结晶。下面是关于它的一些设计哲学理念：

业务逻辑应该和表现逻辑相对分开。我们将模板系统视为控制表现及表现相关逻辑的工具，仅此而已。模板系统不应提供超出此基本目标的功能。

出于这个原因，在 Django模板中是不可能直接调用 Python代码的。所有的编程工作基本上都被局限于模板标签的能力范围。当然，是有可能写出自定义的模板标签来完成任意工作，但这些“超范围”的 Django 模板标签有意地不允许执行任何 Python代码。

语法不应受到 HTML/XML的束缚。尽管 Django模板系统主要用于生成 HTML，它还是被有意地设计为可生成非 HTML格式，如纯文本。一些其它的模板语言是基于 XML的，将所有的模板逻辑置于 XML标签与属性之中，而 Django有意地避开了这种限制。强制要求使用有效 XML编写模板将会引发大量的人为错误和难以理解的错误信息，而且使用 XML引擎解析模板也会导致令人无法容忍的模板处理开销。

假定设计师精通 HTML编码。模板系统的设计意图并不是为了让模板一定能够很好地显示在 Dreamweaver这样的所见即所得编辑器中。这种限制过于苛刻，而且会使得语法不能像目前这样的完美。Django要求模板创作人员对直接编辑 HTML非常熟悉。

假定设计师不是 Python程序员。模板系统开发人员认为：网页模板通常由设计师而不是程序员编写，因而假定这些人并不掌握 Python 相关知识。

当然，系统同样也特意地提供了对那些由Python程序员进行模板制作的小型团队的支持。它提供了一种工作模式，允许通过编写原生 Python代码进行系统语法拓展。（详见第十章）

目标并不是要发明一种编程语言。目标是恰到好处地提供如分支和循环这一类编程式功能，这是进行与表现相关判断的基础。

采用这些设计理念的结果是导致 Django模板语言有以下几点限制：

§ 模板中不能设置变量和改变变量的值。可以通过编写自定义模板标签做到这一点（参见第十章），但正宗的 Django模板标签做不到。

§ 模板中不能调用任何的Python代码。不存在转入 Python模式或使用原生 Python 数据结构的方法。和前面一样，可以编写自定义模板标签来实现这个目标，但正宗的 Django模板标签做不到。

在视图中使用模板

在学习了模板系统的基础之后，现在让我们使用相关知识来创建视图。重新打开我们在前一章在mysite.views中创建的current_datetime视图。以下是其内容：

让我们用 Django模板系统来修改该视图。第一步，你可能已经想到了要做下面这样的修改：

没错，它确实使用了模板系统，但是并没有解决我们在本章开头所指出的问题。也就是说，模板依燃内嵌在 Python代码之中。让我们将模板置于一个单独的文件中，并且让视图加载该文件来解决此问题。

你可能首先考虑把模板保存在文件系统的某个位置并用 Python内建的文件操作函数来读取文件内容。假设文件保存在/home/djangouser/templates/mytemplate.html中的话，代码就会像下面这样:

然而，基于以下几个原因，该方法还算不上简洁：

§ 它没有对文件丢失的情况做出处理。如果文件mytemplate.html不存在或者不可读，open()函数调用将会引发IOError异常。

§ 这里对模板文件的位置进行了硬编码。如果你在每个视图函数都用该技术，就要不断复制这些模板的位置。更不用说还要带来大量的输入工作！

§ 它包含了大量令人生厌的重复代码。与其在每次加载模板时都调用open()、fp.read()和fp.close()，还不如做出更佳选择。

要解决此问题，我们将使用模板加载和模板目录，这是我们在接下来的章节中要讨论的两个话题。

模板加载

为了减少模板加载调用过程及模板本身的冗余代码，Django提供了一种使用方便且功能强大的 API，用于从磁盘中加载模板，

要使用此模板加载API，首先你必须将模板的保存位置告诉框架。该项工作在设置文件中完成。

Django 设置文件是存放 Django实例（也就是 Django 项目）配置的地方。它是一个简单的 Python模块，其中包含了一些模块级变量，每个都是一项设置。

第二章中执行django-admin.py startproject mysite命令时，它为你创建了一个的缺省配置文件，并恰如其分地将其名为settings.py。查看一下该文件内容。其中包含如下变量（但并不一定是这个顺序）：

这里无需更多诠释；设置项与值均为简单的 Python变量。同时由于配置文件只不过是纯 Python模块，你可以完成一些动态工作，比如在设置某变量之前检查另一变量的值。（这也意味着你必须避免配置文件出现 Python语法错误。）

我们将在附录 E中详述配置文件，目前而言，仅需关注TEMPLATE_DIRS设置。该设置告诉 Django的模板加载机制在哪里查找模板。缺省情况下，该设置的值是一个空的元组。选择一个目录用于存放模板并将其添加到TEMPLATE_DIRS中：

下面是一些注意事项：

你可以任意指定想要的目录，只要运行 Web服务器的用户账号可以读取该目录的子目录和模板文件。如果实在想不出合适的位置来放置模板，我们建议在 Django项目中创建一个templates目录（也就是说，如果你一直都按本书的范例操作的话，在第二章创建的mysite目录中）。

不要忘记模板目录字符串尾部的逗号！Python要求单元素元组中必须使用逗号，以此消除与圆括号表达式之间的歧义。这是新手常犯的错误。

想避免此错误的话，你可以将列表而不是元组用作TEMPLATE_DIRS，因为单元素列表并不强制要求以逗号收尾：

从语义上看，元组比列表略显合适（元组在创建之后就不能修改，而配置被读取以后就不应该有任何修改）。因此，我们推荐对TEMPLATE_DIRS设置使用元组。

如果使用的是 Windows平台，请包含驱动器符号并使用Unix风格的斜杠（/）而不是反斜杠（\）,就像下面这样：

最省事的方式是使用绝对路径（即从文件系统根目录开始的目录路径）。如果想要更灵活一点并减少一些负面干扰，可利用 Django配置文件就是 Python代码这一点来动态构建TEMPLATE_DIRS的内容，如：

这个例子使用了神奇的 Python内部变量__file__，该变量被自动设置为代码所在的 Python模块文件名。

完成TEMPLATE_DIRS设置后，下一步就是修改视图代码，让它使用 Django模板加载功能而不是对模板路径硬编码。返回current_datetime视图，进行如下修改：

此范例中，我们使用了函数django.template.loader.get_template()，而不是手动从文件系统加载模板。该get_template()函数以模板名称为参数，在文件系统中找出模块的位置，打开文件并返回一个编译好的Template对象。

如果get_template()找不到给定名称的模板，将会引发一个TemplateDoesNotExist异常。要了解究竟会发生什么，让我们按照第三章内容，在 Django 项目目录中运行python manage.py runserver命令，再次启动Django开发服务器。。然后，用浏览器访问页面（如：http://127.0.0.1:8000/time/)激活current_datetime视图。假如DEBUG设置为True而又未创建current_datetime.html模板，你将会看到TemplateDoesNotExist错误信息页面。

图 4-1:无法找到模板时的出错页面

该页面与我们在第三章解释过的错误页面相似，只不过多了一块调试信息区：模板加载器事后检查区。该区域显示 Django要加载哪个模板、每次尝试出错的原因（如：文件不存在等）。在调试模板加载错误时，这些信息的价值是不可估量的。

正如你从图 4-1中的错误信息中所看到，Django尝试通过组合TEMPLATE_DIRS设置以及传递给get_template()的模板名称来查找模板。因此如果TEMPLATE_DIRS为‘/home/django/templates‘，Django将会查找‘/home/django/templates/current_datetime.html‘。如果TEMPLATE_DIRS包含多个目录，它将会查找每个目录直至找到模板或找遍所有目录。

接下来，在模板目录中创建包括以下模板代码current_datetime.html文件：

在网页浏览器中刷新该页，你将会看到完整解析后的页面。

render_to_response()

由于加载模板、填充context、将经解析的模板结果返回为HttpResponse对象这一系列操作实在太常用了，Django提供了一条仅用一行代码就完成所有这些工作的捷径。该捷径就是位于django.shortcuts模块中名为render_to_response()的函数。大多数时候，你将使用render_to_response()，而不是手动加载模板、创建Context和HttpResponse对象。

下面就是使用render_to_response()重新编写过的current_datetime范例。

大变样了！让我们逐句看看代码发生的变化：

§ 我们不再需要导入get_template、Template、Context和HttpResponse。相反，我们导入django.shortcuts.render_to_response。import datetime继续保留.

§ 在current_datetime函数中，我们仍然进行now计算，但模板加载、上下文创建、模板解析和HttpResponse创建工作均在对render_to_response()的调用中完成了。由于render_to_response()返回HttpResponse对象，因此我们仅需在视图中return该值。

render_to_response()的第一个参数必须是要使用的模板名称。如果要给定第二个参数，那么该参数必须是为该模板创建Context时所使用的字典。如果不提供第二个参数，render_to_response()使用一个空字典。

locals() 技巧

思考一下我们对current_datetime的最后一次赋值:

很多时候，就像在这个范例中那样，你发现自己一直在计算某个变量，保存结果到变量中（比如：前面代码中的now），然后将这些变量发送给模板。特别懒的程序员可能注意到给这些临时变量和模板变量命名显得有点多余。不但多余，而且还要进行额外的键盘输入。

如果你是个喜欢偷懒的程序员并想让代码看起来更加简明，可以利用 Python的内建函数locals()。它返回的字典对所有局部变量的名称与值进行映射。因此，前面的视图可以重写成下面这个样子：

在此，我们没有像之前那样手工指定 context字典，而是传入了locals()的值，它囊括了函数执行到该时间点时所定义的一切变量。因此，我们将current_date变量重命名为now，因为那才是模板所预期的变量名称。在本例中，locals()并没有带来多大的改进，但是如果有多个模板变量要界定而你又想偷懒，这种技术可以减少一些键盘输入。

使用locals()时要注意是它将包括所有的局部变量，组成它的变量可能比你想让模板访问的要多。在前例中，locals()还包含了request。对此如何取舍取决你的应用程序。

最后要考虑的是在你调用locals()时，Python必须得动态创建字典，因此它会带来一点额外的开销。如果手动指定 context字典，则可以避免这种开销。

get_template()中使用子目录

把所有的模板都存放在一个目录下可能会让事情变得难以掌控。你可能会考虑把模板存放在你模板目录的子目录中，这非常好。事实上，我们推荐这样做；一些Django的高级特性（例如将在第九章讲到的通用视图系统）的缺省约定就是期望使用这种模板布局。

把模板存放于模板目录的子目录中是件很轻松的事情。只需在调用get_template()时，把子目录名和一条斜杠添加到模板名称之前，如：

由于render_to_response()只是对get_template()的简单封装，你可以对render_to_response()的第一个参数做相同处理。

对子目录树的深度没有限制，你想要多少层都可以。

注意

Windows用户必须使用斜杠而不是反斜杠。get_template()假定的是 Unix风格的文件名符号约定。

include模板标签

在讲解了模板加载机制之后，我们再介绍一个利用该机制的内建模板标签：{% include %}。该标签允许在（模板中）包含其它的模板的内容。标签的参数是所要包含的模板名称，可以是一个变量，也可以是用单/双引号硬编码的字符串。每当在多个模板中出现相同的代码时，就应该考虑是否要使用{% include %}来减少重复。

下面这两个例子都包含了nav.html模板。两个例子的作用完全相同，只不过是为了说明单、双引号都可以通用。

下面的例子包含了includes/nav.html模板的内容:

下面的例子包含了以变量template_name的值为名称的模板内容：

和在get_template()中一样，对模板的文件名进行判断时会在所调取的模板名称之前加上来自TEMPLATE_DIRS的模板目录。

所包含的模板执行时的 context和包含它们的模板是一样的。

如果未找到给定名称的模板文件，Django会从以下两件事情中择一而为之：

§ 如果DEBUG设置为True，你将会在 Django 错误信息页面看到TemplateDoesNotExist异常。

§ 如果DEBUG设置为False，该标签不会引发错误信息，在标签位置不显示任何东西。

模板继承

到目前为止，我们的模板范例都只是些零星的 HTML片段，但在实际应用中，你将用 Django模板系统来创建整个 HTML 页面。这就带来一个常见的 Web 开发问题：在整个网站中，如何减少共用页面区域（比如站点导航）所引起的重复和冗余代码？

解决该问题的传统做法是使用服务器端的 includes，你可以在 HTML页面中使用该指令将一个网页嵌入到另一个中。事实上， Django通过刚才讲述的{% include %}支持了这种方法。但是用 Django解决此类问题的首选方法是使用更加简洁的策略——模板继承。

本质上来说，模板继承就是先构造一个基础框架模板，而后在其子模板中对它所包含站点公用部分和定义块进行重载。

让我们通过修改current_datetime.html文件，为current_datetime创建一个更加完整的模板来体会一下这种做法：

这看起来很棒，但如果我们要为第三章的hours_ahead视图创建另一个模板会发生什么事情呢？如果我们再次创建一个漂亮、有效且完整的 HTML模板，我们可能会创建出下面这样的东西：

很明显，我们刚才重复了大量的 HTML代码。想象一下，如果有一个更典型的网站，它有导航条、样式表，可能还有一些 JavaScript代码，事情必将以向每个模板填充各种冗余的 HTML而告终。

解决这个问题的服务器端 include方案是找出两个模板中的共同部分，将其保存为不同的模板片段，然后在每个模板中进行 include。也许你会把模板头部的一些代码保存为header.html文件：

你可能会把底部保存到文件footer.html:

对基于 include的策略，头部和底部的包含很简单。麻烦的是中间部分。在此范例中，每个页面都有一个<h1>My helpful timestamp site</h1>标题，但是这个标题不能放在header.html中，因为每个页面的<title>是不同的。如果我们将<h1>包含在头部，我们就不得不包含<title>，但这样又不允许在每个页面对它进行定制。何去何从呢？

Django 的模板继承系统解决了这些问题。你可以将其视为服务器端 include的逆向思维版本。你可以对那些不同的代码段进行定义，而不是共同代码段。

第一步是定义基础模板，该框架之后将由子模板所继承。以下是我们目前所讲述范例的基础模板：

这个叫做base.html的模板定义了一个简单的 HTML框架文档，我们将在本站点的所有页面中使用。子模板的作用就是重载、添加或保留那些块的内容。（如果一直按我们的范例做话，请将此文件保存到模板目录。）

我们使用一个以前已经见过的模板标签：{% block %}。所有的{% block %}标签告诉模板引擎，子模板可以重载这些部分。

现在我们已经有了一个基本模板，我们可以修改current_datetime.html模板来使用它：

再为hours_ahead视图创建一个模板，看起来是这样的：

看起来很漂亮是不是？每个模板只包含对自己而言独一无二的代码。无需多余的部分。如果想进行站点级的设计修改，仅需修改base.html，所有其它模板会立即反映出所作修改。

以下是其工作方式。在加载current_datetime.html模板时，模板引擎发现了{% extends %}标签，注意到该模板是一个子模板。模板引擎立即装载其父模板，即本例中的base.html。

此时，模板引擎注意到base.html中的三个{% block %}标签，并用子模板的内容替换这些 block 。因此，引擎将会使用我们在{ block title %}中定义的标题，对{% block content %}也是如此。

注意由于子模板并没有定义footer块，模板系统将使用在父模板中定义的值。父模板{% block %}标签中的内容总是被当作一条退路。

继承并不改变 context的工作方式，而且你可以按照需要使用多层继承。使用继承的一种常见方式是下面的三层法：

1. 创建base.html模板，在其中定义站点的主要外观感受。这些都是不常修改甚至从不修改的部分。

2. 为网站的每个区域创建base_SECTION.html模板(例如,base_photos.html和base_forum.html)。这些模板对base.html进行拓展，并包含区域特定的风格与设计。

3. 为每种类型的页面创建独立的模板，例如论坛页面或者图片库。这些模板拓展相应的区域模板。

这个方法可最大限度地重用代码，并使得向公共区域（如区域级的导航）添加内容成为一件轻松的工作。

以下是使用模板继承的一些诀窍：

§ 如果在模板中使用{% extends %}，必须保证其为模板中的第一个模板标记。否则，模板继承将不起作用。

§ 一般来说，基础模板中的{% block %}标签越多越好。记住，子模板不必定义父模板中所有的代码块，因此你可以用合理的缺省值对一些代码块进行填充，然后只对子模板所需的代码块进行（重）定义。俗话说，钩子越多越好。

§ 如果发觉自己在多个模板之间拷贝代码，你应该考虑将该代码段放置到父模板的某个{% block %}中。

§ 如果需要获得父模板中代码块的内容，可以使用{{ block.super }}变量。如果只想在上级代码块基础上添加内容，而不是全部重载，该变量就显得非常有用了。

§ 不可同一个模板中定义多个同名的{% block %}。存在这样的限制是因为block标签的工作方式是双向的。也就是说，block标签不仅挖了一个要填的坑，也定义了在父模板中这个坑所填充的内容。如果模板中出现了两个相同名称的{% block %}标签，父模板将无从得知要使用哪个块的内容。

§ {% extends %}对所传入模板名称使用的加载方法和get_template()相同。也就数说，会将模板名称被添加到TEMPLATE_DIRS设置之后。

§ 多数情况下，{% extends %}的参数应该是字符串，但是如果直到运行时方能确定父模板名，这个参数也可以是个变量。这使得你能够实现一些很酷的动态功能。

接下来？

时下大多数网站都是数据库驱动的：网站的内容都是存储在关系型数据库中。这使得数据和逻辑能够彻底地分开（视图和模板也以同样方式对逻辑和显示进行了分隔。）

转载请注明本文出处：http://blog.csdn.net/wolaiye320/article/details/51833030

Django模板系统详解

标签：

原文地址：http://blog.csdn.net/wolaiye320/article/details/51833030