python和django的一些小技巧(locals()...)

python和django的一些小技巧(locals()...)
locals() 技巧:

思考一下我们对 current_datetime 的最后一次赋值:
```
1 >>> import datetime
2 >>> def current_datetime(request):
3 ...     now = datetime.datetime.now()
4 ...     return render_to_response('current_datetime.html':now)
```
很多时候，就像在这个范例中那样，你发现自己一直在计算某个变量，保存结果到变量中（比如前面代码中的 now ），然后将这些变量发送给模板。尤其喜欢偷懒的程序员应该注意到了，不断地为临时变量和临时模板命名有那么一点点多余。不仅多余，而且需要额外的输入。

如果你是个喜欢偷懒的程序员并想让代码看起来更加简明，可以利用 Python 的内建函数 locals() 。它返回的字典对所有局部变量的名称与值进行映射。因此，前面的视图可以重写成下面这个样子：
```
1 def current_datetime(request):
2     current_date = datetime.datetime.now()
3     return render_to_response('current_datetime.html', locals())
```
在此，我们没有像之前那样手工指定 context 字典，而是传入了 locals() 的值，它囊括了函数执行到该时间点时所定义的一切变量。因此，我们将 now 变量重命名为 current_date ，因为那才是模板所预期的变量名称。在本例中， locals() 并没有带来多大的改进，但是如果有多个模板变量要界定而你又想偷懒，这种技术可以减少一些键盘输入。

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

get_template()中使用子目录:

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

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

1 t = get_template('dateapp/current_datetime.html')

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

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

对子目录树的深度没有限制，你想要多少层都可以。只要你喜欢，用多少层的子目录都无所谓。

注意

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

include 模板标签：

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

1 {% include 'nav.html' %}

2 {% include "nav.html" %}

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

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

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

1 {% include template_name %}

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

所包含的模板执行时的 context 和包含它们的模板是一样的。举例说，考虑下面两个模板文件：
```
 1 # mypage.html
 2 
 3 <html>
 4 <body>
 5 {% include "includes/nav.html" %}
 6 <h1>{{ title }}</h1>
 7 </body>
 8 </html>
 9 
10 # includes/nav.html
11 
12 <div id="nav">
13     You are in: {{ current_section }}
14 </div>
```
如果你用一个包含 current_section的上下文去渲染 mypage.html这个模板文件，这个变量将存在于它所包含（include）的模板里，就像你想象的那样。

如果{% include %}标签指定的模板没找到，Django将会在下面两个处理方法中选择一个：
- 如果 DEBUG 设置为 True ，你将会在 Django 错误信息页面看到 TemplateDoesNotExist 异常。
- 如果 DEBUG 设置为 False ，该标签不会引发错误信息，在标签位置不显示任何东西。
模板继承：

但在实际应用中，你将用 Django 模板系统来创建整个 HTML 页面。这就带来一个常见的 Web 开发问题：在整个网站中，如何减少共用页面区域（比如站点导航）所引起的重复和冗余代码？

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

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

让我们通过修改 current_datetime.html 文件，为 current_datetime 创建一个更加完整的模板来体会一下这种做法：
```
 1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
 2 <html lang="en">
 3 <head>
 4     <title>The current time</title>
 5 </head>
 6 <body>
 7     <h1>My helpful timestamp site</h1>
 8     <p>It is now {{ current_date }}.</p>
 9 
10     <hr>
11     <p>Thanks for visiting my site.</p>
12 </body>
13 </html>
```
这看起来很棒，但如果我们要为第三章的 hours_ahead 视图创建另一个模板会发生什么事情呢？
```
 1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
 2 <html lang="en">
 3 <head>
 4     <title>Future time</title>
 5 </head>
 6 <body>
 7     <h1>My helpful timestamp site</h1>
 8     <p>In {{ hour_offset }} hour(s), it will be {{ next_time }}.</p>
 9 
10     <hr>
11     <p>Thanks for visiting my site.</p>
12 </body>
13 </html>
```
很明显，我们刚才重复了大量的 HTML 代码。想象一下，如果有一个更典型的网站，它有导航条、样式表，可能还有一些 JavaScript 代码，事情必将以向每个模板填充各种冗余的 HTML 而告终。

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

1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">

2 <html lang="en">

3 <head>

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

1 <hr> 2 <p>Thanks for visiting my site.</p>

3 </body>

4 </html>

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

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

第一步是定义 基础模板 ，该框架之后将由 子模板 所继承。以下是我们目前所讲述范例的基础模板：
```
 1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
 2 <html lang="en">
 3 <head>
 4     <title>{% block title %}{% endblock %}</title>
 5 </head>
 6 <body>
 7     <h1>My helpful timestamp site</h1>
 8     {% block content %}{% endblock %}
 9     {% block footer %}
10     <hr>
11     <p>Thanks for visiting my site.</p>
12     {% endblock %}
13 </body>
14 </html>
```
这个叫做 base.html 的模板定义了一个简单的 HTML 框架文档，我们将在本站点的所有页面中使用。子模板的作用就是重载、添加或保留那些块的内容。

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

现在我们已经有了一个基本模板，我们可以修改 current_datetime.html 模板来使用它：
```
1 {% extends "base.html" %}
2 
3 {% block title %}The current time{% endblock %}
4 
5 {% block content %}
6 <p>It is now {{ current_date }}.</p>
7 {% endblock %}
```
再为 hours_ahead 视图创建一个模板，看起来是这样的：
```
1 {% extends "base.html" %}
2 
3 {% block title %}Future time{% endblock %}
4 
5 {% block content %}
6 <p>In {{ hour_offset }} hour(s), it will be {{ next_time }}.</p>
7 {% 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 模板，在其中定义站点的主要外观感受。这些都是不常修改甚至从不修改的部分。
1. 为网站的每个区域创建 base_SECTION.html 模板(例如, base_photos.html 和 base_forum.html )。这些模板对 base.html 进行拓展，并包含区域特定的风格与设计。
1. 为每种类型的页面创建独立的模板，例如论坛页面或者图片库。这些模板拓展相应的区域模板。
这个方法可最大限度地重用代码，并使得向公共区域（如区域级的导航）添加内容成为一件轻松的工作。

以下是使用模板继承的一些诀窍：
- 如果在模板中使用 {% extends %} ，必须保证其为模板中的第一个模板标记。否则，模板继承将不起作用。
- 一般来说，基础模板中的 {% block %} 标签越多越好。记住，子模板不必定义父模板中所有的代码块，因此你可以用合理的缺省值对一些代码块进行填充，然后只对子模板所需的代码块进行（重）定义。俗话说，钩子越多越好。
- 如果发觉自己在多个模板之间拷贝代码，你应该考虑将该代码段放置到父模板的某个 {% block %} 中。
- 如果你需要访问父模板中的块的内容，使用 {{ block.super }}这个标签吧，这一个魔法变量将会表现出父模板中的内容。如果只想在上级代码块基础上添加内容，而不是全部重载，该变量就显得非常有用了。
- 不允许在同一个模板中定义多个同名的 {% block %} 。存在这样的限制是因为block 标签的工作方式是双向的。也就是说，block 标签不仅挖了一个要填的坑，也定义了在父模板中这个坑所填充的内容。如果模板中出现了两个相同名称的 {% block %} 标签，父模板将无从得知要使用哪个块的内容。
- {% extends %} 对所传入模板名称使用的加载方法和 get_template() 相同。也就是说，会将模板名称被添加到 TEMPLATE_DIRS 设置之后。
- 多数情况下， {% extends %} 的参数应该是字符串，但是如果直到运行时方能确定父模板名，这个参数也可以是个变量。这使得你能够实现一些很酷的动态功能。
```
此文内容引用自：http://docs.30c.org/djangobook2/chapter04/
```
相关阅读:
10.22 比赛总结修剪草坪(mowlawn)、玉米迷宫(cornmaze)
QProcess怎么实时的读到output的信息
 Qt Visual Studio Add-in 导出的 .pri 怎么用?
Qt写Activex插件总结
 osg中内嵌QtBrowser
解决使用osgModeling的Loft生成管子时的bug(续)
lua中的中文乱码
 std::string的split函数
 解决使用osgModeling的Loft生成管子时的bug
Qt里的slot
原文地址：https://www.cnblogs.com/blogofwyl/p/4294289.html

python和django的一些小技巧(locals()...)

locals() 技巧:

get_template()中使用子目录:

include 模板标签：

模板继承：

`include` 模板标签：