|
ySJ
|
2.0/chapter09/#132 |
2010-04-15 17:30:14
|
细心的读者可能会注意到<literal>debug</literal>模板变量的值永远不可能为<literal>False</literal>，因为如果<literal>DEBUG</literal>是<literal>False</literal>，那么<literal>debug</literal>模板变量一开始就不会被RequestContext所包含。
|
|
|
ySJ
|
2.0/chapter09/#117 |
2010-04-15 17:18:05
|
如果<literal>TEMPLATE_CONTEXT_PROCESSORS</literal>包含这个处理器，每一个<literal>RequestContext</literal>将包含这些变量：
|
|
|
ySJ
|
2.0/chapter09/#112 |
2010-04-15 17:02:02
|
关于users、permissions和messages的更多内容请参考第14章。
|
|
|
ySJ
|
2.0/chapter09/#107 |
2010-04-15 17:01:25
|
在后台，对每一个请求，这个变量都调用 <literal>request.user.get_and_delete_messages()</literal> 方法。
|
|
|
ySJ
|
2.0/chapter09/#92 |
2010-04-15 16:57:41
|
这个设置项是一个可调用函数的元组，其中的每个函数使用了和上文中我们的 <literal>custom_proc</literal> 相同的接口，它们以request对象作为参数，返回一个会被合并传给context的字典：
|
|
|
ySJ
|
2.0/chapter09/#87 |
2010-04-15 16:50:48
|
<literal>TEMPLATE_CONTEXT_PROCESSORS</literal> 指定了哪些<literal>context processors</literal><emphasis>总是</emphasis>默认被使用。这样就省去了每次使用 <literal>RequestContext</literal> 都指定 <literal>processors</literal> 的麻烦。
|
|
|
ySJ
|
2.0/chapter09/#84 |
2010-04-15 13:59:03
|
由于你不得不一直键入 <literal>processors</literal> ，所以使用context处理器并没有减少太多的输入量。
|
|
|
ySJ
|
2.0/chapter09/#77 |
2010-04-15 13:56:13
|
为了讲解context处理器底层是如何工作的，在上面的例子中我们没有使用 <literal>render_to_response()</literal> 。但是建议选择 <literal>render_to_response()</literal> 作为context的处理器。这就需要用到<literal>context_instance</literal>参数：
|
|
|
ySJ
|
2.0/chapter09/#76 |
2010-04-15 13:52:57
|
在第四章，我们介绍了 <literal>render_to_response()</literal> 这个快捷方式，它可以简化调用 <literal>loader.get_template()</literal> ,然后创建一个 <literal>Context</literal> 对象，最后再调用模板对象的 <literal>render()</literal>过程。
|
|
|
ySJ
|
2.0/chapter09/#69 |
2010-04-15 13:51:16
|
在这里，我们传递了我们之前定义的处理器函数 <literal>curstom_proc</literal> 。
|
|
|
ySJ
|
2.0/chapter09/#68 |
2010-04-15 13:50:37
|
一， <literal>RequestContext</literal> 的第一个参数需要传递一个 <literal>HttpRequest</literal> 对象，就是传递给视图函数的第一个参数（ <literal>request</literal> ）。二， <literal>RequestContext</literal> 有一个可选的参数 <literal>processors</literal> ，这是一个包含context处理器函数的列表或者元组。
|
|
|
ySJ
|
2.0/chapter09/#67 |
2010-04-15 13:48:02
|
我们在这两个视图函数中用 <literal>RequestContext</literal> 代替了 <literal>Context</literal> 。在context对象的构建上有两个不同点。
|
|
|
ySJ
|
2.0/chapter09/#52 |
2010-04-15 13:41:38
|
每个视图都给模板传入了三个相同的变量：<literal>app</literal>、<literal>user</literal>和<literal>ip_address</literal>。
|
|
|
ySJ
|
2.0/chapter09/#52 |
2010-04-15 13:41:27
|
每个视图都给模板传入了三个相同的变量：<literal>app</literal>、<literal>user</literal>和<literal>ip_address</literal> |
|
|
ySJ
|
2.0/chapter09/#53 |
2010-04-15 13:40:52
|
如果我们把这些冗余去掉会不会更好？
|
|
|
ySJ
|
2.0/chapter09/#53 |
2010-04-15 13:40:44
|
如果我们能把这些冗余去掉会不会更好？
|
|
|
ySJ
|
2.0/chapter09/#50 |
2010-04-15 13:39:43
|
是为了能够清晰的说明所有步骤。）
|
|
|
ySJ
|
2.0/chapter09/#45 |
2010-04-15 13:39:00
|
当你不想在一系例模板中都明确指定一些相同的变量时，你应该使用 <literal>RequestContext</literal> 。
|
|
|
ySJ
|
2.0/chapter09/#42 |
2010-04-15 13:25:56
|
一般情况下，这是一个 <literal>django.template.Context</literal> 的实例，不过在Django中还可以用一个特殊的子类， <literal>django.template.RequestContext</literal> ，这个用起来稍微有些不同。
|
|
|
ySJ
|
2.0/chapter09/#32 |
2010-04-15 13:24:50
|
模板 <emphasis>渲染</emphasis> 就是是通过从context获取值来替换模板中变量并执行所有的模板标签。
|
|
|
ySJ
|
2.0/chapter09/#27 |
2010-04-15 12:49:40
|
变量标签被 <literal>{{</literal> 和 <literal>}}</literal> 包围：
|
|
|
ySJ
|
2.0/chapter09/#22 |
2010-04-15 11:12:07
|
区块标签被 <literal>{%</literal> 和 <literal>%}</literal> 包围：
|
|
|
ySJ
|
2.0/chapter09/#20 |
2010-04-15 11:11:44
|
例如，一个模版标签能够产生作为控制结构的内容（一个 <literal>if</literal>语句或<literal>for</literal> 循环), 可以获取数据库内容，或者访问其他的模板标签。
|
|
|
ySJ
|
2.0/chapter09/#18 |
2010-04-15 11:10:12
|
<emphasis>模板标签</emphasis> 是在一个模板里面起作用的的标记。
|
|
|
ySJ
|
2.0/chapter09/#15 |
2010-04-15 11:09:31
|
<emphasis>模板</emphasis> 是一个纯文本文件，或是一个用Django模板语言标记过的普通的Python字符串。
|
|
|
ySJ
|
2.0/chapter09/#13 |
2010-04-15 11:08:54
|
首先，让我们快速回顾一下第四章介绍的若干专业术语：
|
|
|
ySJ
|
2.0/chapter09/#9 |
2010-04-15 11:08:35
|
如果你想把Django的模版系统作为另外一个应用程序的一部分（就是说，仅使用Django的模板系统而不使用Django框架的其他部分），那你一定要读一下“配置独立模式下的模版系统”这一节。
|
|
|
ySJ
|
2.0/chapter09/#7 |
2010-04-15 11:05:03
|
它也包含一个自动转意特征，如果你继续使用django，随着时间的推移你一定会注意这个安全考虑。
|
|
|
ySJ
|
2.0/chapter09/#3 |
2010-04-15 11:03:32
|
虽然大多数和Django模板语言的交互都是模板作者的工作，但你可能想定制和扩展模板引擎，让它做一些它不能做的事情，或者是以其他方式让你的工作更轻松。
|
|
|
ySJ
|
2.0/chapter08/#480 |
2010-04-14 17:50:40
|
Hosting公司谨奉
|
|
|
ySJ
|
2.0/chapter08/#477 |
2010-04-14 17:49:46
|
接下来，在<reference name="Chapter 9" refuri="../chapter09/">第九章</reference>,我们将会把这个先进的处理方案应用到Django的模板系统。
|
|
|
ySJ
|
2.0/chapter08/#476 |
2010-04-14 17:48:45
|
这一章提供了很多关于视图和URLconfs的高级提示技巧。
|
|
|
ySJ
|
2.0/chapter08/#476 |
2010-04-14 17:48:33
|
这一章提供了很多关于视图和URLconfs的高级提示和技巧。
|
|
|
ySJ
|
2.0/chapter08/#476 |
2010-04-14 17:48:19
|
这一章提供了很多视图和URLconfs的高级提示和技巧。
|
|
|
ySJ
|
2.0/chapter08/#472 |
2010-04-14 17:47:28
|
因此，这个技术只有在你确定被包含指向的每个视图都正确接收这些额外选项的时候才有用。
|
|
|
ySJ
|
2.0/chapter08/#471 |
2010-04-14 17:46:15
|
这个例子和前面关于被捕获的参数一样（在上一节就解释过这一点），额外的选项将 <emphasis>总是</emphasis> 被传递到被包含的URLconf中的 <emphasis>每一</emphasis> 行，不管那一行对应的视图是否确实作为有效参数接收这些选项。
|
|
|
ySJ
|
2.0/chapter08/#463 |
2010-04-14 17:45:13
|
比如，下面的两个URLconf在功能上是一样的。
|
|
|
ySJ
|
2.0/chapter08/#456 |
2010-04-14 17:44:14
|
因此，这个技术只有在你确定被包含只向的每个视图都需要那个被传递的参数的时候才有用。
|
|
|
ySJ
|
2.0/chapter08/#450 |
2010-04-14 17:40:46
|
一个被包含(included)的URLconf接收任何来自父URLconfs的被捕获的参数，比如:
|
|
|
ySJ
|
2.0/chapter08/#446 |
2010-04-14 17:39:03
|
<literal>/about/</literal> : 这个匹配第一个URLconf中的 <literal>mysite.views.about</literal> 视图。这说明你可以混合使用<literal>include()</literal>和<literal>非include()</literal>模式。
|
|
|
ySJ
|
2.0/chapter08/#439 |
2010-04-14 17:32:28
|
URL仍存在的部分为 <literal>2007/</literal> ,与第一行的 <literal>mysite.blog.urls</literal>URL设置相匹配。
|
|
|
ySJ
|
2.0/chapter08/#438 |
2010-04-14 17:31:55
|
因为它是一个 <literal>include()</literal> ，Django将截掉所有匹配的文本，在这里是 <literal>'weblog/'</literal> 。
|
|
|
ySJ
|
2.0/chapter08/#426 |
2010-04-14 17:27:12
|
admin模块有他自己的URLconf,你仅仅只需要在你自己的代码中加入include就可以了。）
|
|
|
ySJ
|
2.0/chapter08/#425 |
2010-04-14 17:26:57
|
（之前在第6章介绍Django的admin模块时我们曾经见过include。
|
|
|
ySJ
|
2.0/chapter08/#421 |
2010-04-14 17:26:02
|
本质上这是把URL连接成树。
|
|
|
ySJ
|
2.0/chapter08/#418 |
2010-04-14 17:24:07
|
如果你试图让你的代码用在多个基于Django的站点上，你应该考虑以能被包含的方式来处理你的URLconf。
|
|
|
ySJ
|
2.0/chapter08/#414 |
2010-04-14 17:21:15
|
现在我们创建了一个漂亮而通用的函数requires_login()来帮助我们包装所有需要验证是否登录的视图。
|
|
|
ySJ
|
2.0/chapter08/#408 |
2010-04-14 17:16:23
|
它处理request.user.is_authenticated()这个验证,从而决定是否执行原来的view函数。
|
|
|
ySJ
|
2.0/chapter08/#407 |
2010-04-14 17:15:43
|
函数requires_login,传入一个视图函数view,然后返回一个新的视图函数new_view.这个新的视图函数new_view在函数requires_login内定义，
|
|
|
ySJ
|
2.0/chapter08/#413 |
2010-04-14 17:13:14
|
优化后的代码和前面的功能一样,但是减少了代码冗余。
|
|
