Django中Template进阶

r囧r小猫 2022-05-27 10:53 195阅读 0赞

在上一节中，了解[Template的基础][Template]

现在对Template进行深入了解

## 在试图中使用模板 ##

视图代码：

from django.http import HttpResponse
    import datetime
    
    def current_datetime(request):
        now = datetime.datetime.now()
        html = "<html><body>It is now %s.</body></html>" % now
        return HttpResponse(html)

用Django模板系统来修改视图。首先想到这样子

from django.template import Template, Context
    from django.http import HttpResponse
    import datetime
    
    def current_datetime(request):
        now = datetime.datetime.now()
        t = Template("<html><body>It is now {
       { current_date }}.</body></html>")
        html = t.render(Context({'current_date': now}))
        return HttpResponse(html)

它确实使用了模板系统，但是模板仍然嵌入在Python代码中，并未实现数据和表现的分离。我们现在将模板放置一个单独的文件，并让视图加载来解决该问题。

你可能考虑将模板保存在文件系统的某个位置并用Python内建的文件操作函数来读取文件内容。类似这样子：

from django.template import Template,Context
    from django.http import HttpResponse
    import datetime
    
    def current_datetime(request):
        now = datetime.datetime.now()
        # Simple way of using templates from the filesystem.
        # This is BAD because it doesn't account for missing files!
        fp = open('/home/lyh/mycode/question_generate/question/templates/question/mytemplate.html')
        t = Template(fp.read())
        fp.close()
        html = t.render(Context({'current_date':now})
        return HttpResponse(html)

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

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

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

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

为了解决这样的问题，我们采用***模板自加载***和***模板目录***的技巧

### 模板加载 ###

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

要使用次模板加载API，首先你必须将模板的保存位置告诉框架。设置的保存文件是ROOT\_URLCONF配置的settings.py。

打开settings.py配置文件，找到TEMPLATE\_DIRS这项设置，默认是一个空元祖（tuple)。

TEMPLATE_DIRS = (
        # Put strings here, like "/home/django/django_templates".
        # Always use forward slashes, even on Windows.
        # Don't forget to use absolute paths, not relative paths.)

该设置告诉 Django 的模板加载机制在哪里查找模板。 选择一个目录用于存放模板并将其添加到 TEMPLATE\_DIRS 中：

TEMPLATE_DIRS = (
        '/home/lyh/mycode/mysite/polls/templates',
    )

注意：

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

如果你的 TEMPLATE\_DIRS只包含一个目录，别忘了在该目录后加上个逗号。

Python要求单价元素元组必须使用逗号，以此消除与圆括号表达式之间的歧义。

最省事的方法是使用绝对路径（即从文件系统根目录开始的目录途径）。但是如果你想要灵活点并减少负面干扰，可以用Django配置文件就是PYthon代码这一点来动态构建TEMPLATE\_DIRS的内容，例如：

import os.path
    
    TEMPLATE_DIRS = (
        os.path.join(os.path.dirname(__file__), 'templates').replace('\\','/'),
    )

这里使用了Python的内部变量\_\_file\_\_，该变量被自动为代码所在的Python模板文件名。‘os.path.dirname(\_\_file\_\_)’将获取自身所在的文件夹，即settings.py所在的目录，然后由os.path.join这个方法将此目录与templates进行链接。若在windows下，它会只能的选择正确的反斜杠进行链接，不是有正斜杠。

完成TEMPLATE\_DIRS设置后，下一步修改视图代码，让它使用Django模板加载功能而不是对模板路径编码。返回current\_datetime视图，如下修改：

from django.template.loader import get_template
    from django.template import Context
    from django.http import HttpResponse
    import datetime
    
    def current_datetime(request):
        now = datetime.datetime.now()
        t = get_template('current_datetime.html')
        html = t.render(Context({'current_date': now}))
        return HttpResponse(html)

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

在这个例子里，我们选择的模板文件是current\_datetime.html，但这个与.html后缀没有直接的联系。 你可以选择任意后缀的任意文件，只要是符合逻辑的都行。甚至选择没有后缀的文件也不会有问题。

要确定某个模板文件在你的系统里的位置， get\_template()方法会自动为你连接已经设置的 TEMPLATE\_DIRS目录和你传入该法的模板名称参数。比如，你的 TEMPLATE\_DIRS目录设置为 '/home/lyh/mycode/mysite/polls/templates'，上面的 get\_template()调用就会为你找到 /home/lyh/mycode/mysite/polls/templates/current\_datetime.html 这样一个位置。

如果 get\_template() 找不到给定名称的模板，将会引发一个 TemplateDoesNotExist 异常。 要了解究竟会发生什么，在 Django 项目目录中运行 python manage.py runserver 命令，再次启动Django开发服务器。 接着，告诉你的浏览器，使其定位到指定页面以激活current\_datetime视图（如 http://127.0.0.1:8000/time/ ）。假设你的 DEBUG项设置为 True，而你有没有建立current\_datetime.html 这个模板文件，你会看到Django的错误提示网页，告诉你发生了 TemplateDoesNotExist 错误。

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

<html><body>It is now {
       { current_date }}.</body></html>

刷新网页，发现新大陆咯

## render\_to\_response() ##

好，已经说了如何加载一个模板文件，然后用Context渲染它，之后返回这个处理好的HttpResponse对象给用户。我们已经采用了优化方案，使用get\_template()来代替繁华用代码来处理模板及其路径的工作。但这仍然需要一定量的时间来敲代码。Django为此提供了一个捷径，让你一次性的载入某个模板文件，渲染它，然后将此作为HttpResponse返回

下面是使用render\_to\_response()重新编写过的current\_datetime例子：

from django.shortcuts import render_to_response
    import datetime
    
    def current_datetime(request):
        now = datetime.datetime.now()
        return render_to_response('current_datetime.html', {'current_date':now})

（1）我们不在需要导入get\_template、Template、Context和HttpResponse。相反，我们导入django.shortcuts.render\_to\_response。

（2）在current\_datetime函数中，我们任然进行now计算，但模板加载，上下文创建、模板解析和HttpResponse创建工作均对render\_to\_response()的调用中完成了。由于render\_to\_response()返回HttpResponse对象，因此我们仅需在试图中return该值

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

## locals()技巧 ##

很多时候，我们像上一个例子一行，发现自己一直在计算某一个变量，保存结果到变量中（比如前面代码中的now），然后将这些变量发送给模板。我们会发现，不断地为***临时变量***和***临时模板***命名有那么一点儿冗余，不仅多余，还需要额外的输入。

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

def current_datetime(request):
        current_date = datetime.datetime.now()
        return render_to_response('current_datetime.html', locals())

我们没有像之前那样手工指定context字典，而是传入了locals()的值，它囊括了函数执行到该时间点时所定义的一切变量。因此，我们将now变量重命名为current\_date，因为那才是模板所预期的变量名称。

使用locals()时要注意它将包括***所有***的局部变。

## get\_template()中使用子目录 ##

把所有的模板都存放在一个目录下可能会让事情变得难以掌控。根据[Miller法则][Miller]，一个层级下的文件数量在7±2个为好。考虑把模板放在你模板目录的子目录中，这样会很好，而且也推荐这样做。

把模板放在模板目录的子目录中是件非常轻松的事情。只需要在调用get\_template()是，把子目录名和一条斜杠添加到模板名称之前，for example:

t = get_template("dateapp/current_datetime.html")

由于render\_to\_response()只是对get\_template()简单封装，你可以对render\_to\_response()的第一个参数做同样的处理。

return render_to_response('dateapp/current_datetime.html',{'current_date':now})

## include模板标签 ##

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

例子：

{% include 'nav.html' %}

{% include 'include/nav.html' %}

{% include template_name %}

第三个包含了以变量template\_name的值为名称的模板内容。

所包含的模板执行时的 context 和包含它们的模板是一样的。 举例说，考虑下面两个模板文件：

# mypage.html
    
    <html>
    <body>
    {% include "includes/nav.html" %}
    <h1>{
       { title }}</h1>
    </body>
    </html>
    
    # includes/nav.html
    
    <div id="nav">
        You are in: {
       { current_section }}
    </div>

如果你用一个包含current\_section的上下文去渲染mypage.html这个模板文件，这个变量将存在于它所包含（include）的模板里

如果\{% include %\}标签指定的模板没找到，Django将会在下面两个处理方法中选择一个：

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

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

## 模板继承 ##

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

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

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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
    <html lang="en">
    <head>
        <title>The current time</title>
    </head>
    <body>
        <h1>My helpful timestamp site</h1>
        <p>It is now {
       { current_date }}.</p>
    
        <hr>
        <p>Thanks for visiting my site.</p>
    </body>
    </html>

如果有一个更加典型的网站，有导航条、样式表，可能还有一些JavaScript代码，必须给每个模板填充各种冗余的HTML。

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
    <html lang="en">
    <head>

把底部保存到文件footer.html：

<hr>
        <p>Thanks for visiting my site.</p>
    </body>
    </html>

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

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

第一步是定义***基础模板*** ，该框架之后将由***子模板***所继承。 以下是示例的基础模板

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
    <html lang="en">
    <head>
        <title>{% block title %}{% endblock %}</title>
    </head>
    <body>
        <h1>My helpful timestamp site</h1>
        {% block content %}{% endblock %}
        {% block footer %}
        <hr>
        <p>Thanks for visiting my site.</p>
        {% endblock %}
    </body>
    </html>

这个叫做 base.html 的模板定义了一个简单的 HTML 框架文档， 子模板的作用就是重载、添加或保留那些块的内容。

我们使用模板标签： \{% block %\} 。 所有的 \{% block %\} 标签告诉模板引擎，子模板可以重载这些部分。 每个\{% block %\}标签所要做的是告诉模板引擎，该模板下的这一块内容将有可能被子模板覆盖。

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

{% extends "base.html" %}
    
    {% block title %}The current time{% endblock %}
    
    {% block content %}
    <p>It is now {
       { current_date }}.</p>
    {% endblock %}

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

{% extends "base.html" %}
    
    {% block title %} Future time{% endblock %}
    
    {% block content %}
    <p>In {
       { hour_offset }} hour(s), it will be {
       { next_time }}.</p>
    {% endblock %}

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

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

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

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

继承并不会影响到模板的上下文。 换句话说，任何处在继承树上的模板都可以访问到你传到模板中的每一个模板变量。

你可以根据需要使用任意多的继承次数。 使用继承的一种常见方式是下面的三层法：

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

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

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

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

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

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

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

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

（4）如果你需要访问父模板中的块的内容，使用 \{ \{ block.super \}\}这个标签吧，这一个魔法变量将会表现出父模板中的内容。 如果只想在上级代码块基础上添加内容，而不是全部重载，该变量就显得非常有用了。

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

（6）\{% extends %\} 对所传入模板名称使用的加载方法和 get\_template() 相同。 也就是说，会将模板名称被添加到 TEMPLATE\_DIRS 设置之后。（7）

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

[Template]: https://blog.csdn.net/hang916/article/details/79964015
[Miller]: https://blog.csdn.net/hang916/article/details/79692790