在前一章中，你可能已经注意到我们在例子视图中返回文本的方式有点特别。也就是说，HTML被硬性地直接写入 Python 代码之中。
这种处理会导致一些问题：
§                     对页面设计的进行任何改变都必须对 Python 代码进行相应的修改。站点设计的修改往往比底层 Python 代码的修改要频繁得多，因此如果可以在不进行 Python 代码修改的情况下变更设计，那将会方便得多。
§                     Python 代码编写和 HTML 设计是两项不同的工作，大多数专业的网站开发环境都将他们分配给不同的人员（甚至不同部门）来完成。设计人员和 HTML/CSS 编写人员都不应该通过编辑 Python 代码来完成自己的工作；他们应该处理的是 HTML。
1
§                     同理，程序员编写 Python 代码和设计人员制作模板同时进行的工作方式效率是最高的，远胜于让一个人等待另一个人完成对某个既包含 Python 又包含 HTML 的文件的编辑工作。
基于这些原因，将页面的设计和Python的代码分离开会更干净简洁更容易维护。我们可以使用 Django的 模板系统 (Template System)来实现这种模式，这就是本章要具体讨论的问题。
模板系统基本知识
Django 模板是用于分割文档的表示(presentation)和数据(data)的字符串文本。模板定义了占位符(placeholders)和各种定义文档应该如何显示的基本逻辑（即模板标签，template tag）。通常，模板用来生成 HTML，但是 Ddjango 模板同样能够生成任何基于文本的格式。
python基础教程让我们深入分析一个简单的例子模板。该模板描述了一个向某个与公司签单人员致谢 HTML 页面。可将其视为一个格式信函：
1
python基础教程该模板是一段添加了些许变量和模板标签的基础 HTML 。让我们逐句过一遍：
用两个大括号括起来的文字（例如 {{ person_name }} ）是 变量(variable) 。这意味着将按照给定的名字插入变量的值。如何指定变量的值呢？稍后就会说明。
被大括号和百分号包围的文本(例如 {% if ordered_warranty %} )是 模板标签(template tag) 。标签(tag)定义比较明确，即：仅通知模板系统完成某些工作的标签。
3
这个示例模板包含两个标签(tag): {% for item in item_list %} 标签(一个 for 标签) 和{% if ordered_warranty %} 标签 (一个 if 标签)。
for 标签用于构建简单的循环，允许你遍历循环中的每一项。 if 标签，正如你所料，是用来执行逻辑判断的。在这个例子中标签检测 ordered_warranty 变量值是否为 True 。 如果是，模板系统将显示 {% if ordered_warranty %} 与 {% endif %} 之间的所有内容。 如果不是模板系统不会显示它。它当然也支持 {% else %} 以及其他多种逻辑判断方式。
1
最后，这个模板的第二段落有一个 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 还提供更多的功能，请看第十章。
1
变量名必须由英文字符开始 （A-Z或a-z）并可以包含数字字符、下划线和小数点。 （小数点在这里有特别的用途，稍后我们会讲到）变量是大小写敏感的。
下面是编写模板并渲染的示例：
让我们逐句看看这段代码：
首先我们导入 （import）类 Template 和 Context ，它们都在模块 django.template 里。
1
我们把模板原始文本保存到变量 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初学者，你可能在想为什么输出里有回车换行的字符(' ' )而不是 显示回车换行？因为这是Python交互解释器的缘故：调用 t.render(c) 返回字符串， 解释器缺省显示这些字符串的 真实内容呈现 ，而不是打印这个变量的值。 要显示换行而不是 ' ' ，使用 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] )
1
系统使用所找到的第一个有效类型。这是一种短路逻辑。
句点查找可以多级深度嵌套。例如在下面这个例子中 {{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):
基本的模板标签和过滤器
像我们以前提到过的，模板系统带有内置的标签和过滤器。 下面的章节提供了一个多数通用标签和过滤器的简要说明。
1
标签
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 :
参数可以是硬编码的字符串，随便用单引号或这双引号引起来，所以下列代码都是正确的：
1
和 {% 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__() 方法的对象）。
理念与局限
1
现在你已经对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 模板标签做不到。
1
在视图中使用模板
在学习了模板系统的基础之后，现在让我们使用相关知识来创建视图。重新打开我们在前一章在 mysite.views 中创建的current_datetime 视图。以下是其内容：
让我们用 Django 模板系统来修改该视图。第一步，你可能已经想到了要做下面这样的修改：
没错，它确实使用了模板系统，但是并没有解决我们在本章开头所指出的问题。也就是说，模板依燃内嵌在 Python 代码之中。让我们将模板置于一个 单独的文件 中，并且让视图加载该文件来解决此问题。
1
你可能首先考虑把模板保存在文件系统的某个位置并用 Python 内建的文件操作函数来读取文件内容。假设文件保存在/home/djangouser/templates/mytemplate.html 中的话，代码就会像下面这样:
然而，基于以下几个原因，该方法还算不上简洁：
1
§                     它没有对文件丢失的情况做出处理。如果文件 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 要求单元素元组中必须使用逗号，以此消除与圆括号表达式之间的歧义。这是新手常犯的错误。
2
想避免此错误的话，你可以将列表而不是元组用作 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() 并没有带来多大 的改进，但是如果有多个模板变量要界定而你又想偷懒，这种技术可以减少一些键盘输入。
1
使用 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 视图创建一个模板，看起来是这样的：
python基础教程看起来很漂亮是不是？每个模板只包含对自己而言 独一无二 的代码。无需多余的部分。如果想进行站点级的设计修改，仅需修改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 %} 标签越多越好。记住，子模板不必定义父模板中所有的代码块，因此你可以用合理的缺省值对一些代码块进行填充，然后只对子模板所需的代码块进行（重）定义。俗话说，钩子越多越好。
1
§                     如果发觉自己在多个模板之间拷贝代码，你应该考虑将该代码段放置到父模板的某个 {% block %} 中。
§                     如果需要获得父模板中代码块的内容，可以使用 {{ block.super }} 变量。如果只想在上级代码块基础上添加内容，而不是全部重载，该变量就显得非常有用了。
§                     不可同一个模板中定义多个同名的 {% block %} 。存在这样的限制是因为block 标签的工作方式是双向的。也就是说，block 标签不仅挖了一个要填的坑，也定义了在 父 模板中这个坑所填充的内容。如果模板中出现了两个相同名称的{% block %} 标签，父模板将无从得知要使用哪个块的内容。
§                     {% extends %} 对所传入模板名称使用的加载方法和 get_template() 相同。也就数说，会将模板名称被添加到TEMPLATE_DIRS 设置之后。
§                     多数情况下， {% extends %} 的参数应该是字符串，但是如果直到运行时方能确定父模板名，这个参数也可以是个变量。这使得你能够实现一些很酷的动态功能。