|
ySJ
|
2.0/chapter08/#438 |
2010-04-14 17:31:55
|
因为它是一个 <literal>include()</literal> ，Django将截掉所有匹配的文本，在这里是 <literal>'weblog/'</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/#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/#450 |
2010-04-14 17:40:46
|
一个被包含(included)的URLconf接收任何来自父URLconfs的被捕获的参数，比如:
|
|
|
ySJ
|
2.0/chapter09/#18 |
2010-04-15 11:10:12
|
<emphasis>模板标签</emphasis> 是在一个模板里面起作用的的标记。
|
|
|
ySJ
|
2.0/chapter09/#20 |
2010-04-15 11:11:44
|
例如，一个模版标签能够产生作为控制结构的内容（一个 <literal>if</literal>语句或<literal>for</literal> 循环), 可以获取数据库内容，或者访问其他的模板标签。
|
|
|
ySJ
|
2.0/chapter09/#22 |
2010-04-15 11:12:07
|
区块标签被 <literal>{%</literal> 和 <literal>%}</literal> 包围：
|
|
|
ySJ
|
2.0/chapter09/#84 |
2010-04-15 13:59:03
|
由于你不得不一直键入 <literal>processors</literal> ，所以使用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/#92 |
2010-04-15 16:57:41
|
这个设置项是一个可调用函数的元组，其中的每个函数使用了和上文中我们的 <literal>custom_proc</literal> 相同的接口，它们以request对象作为参数，返回一个会被合并传给context的字典：
|
|
|
ySJ
|
2.0/chapter09/#107 |
2010-04-15 17:01:25
|
在后台，对每一个请求，这个变量都调用 <literal>request.user.get_and_delete_messages()</literal> 方法。
|
|
|
ySJ
|
2.0/chapter09/#112 |
2010-04-15 17:02:02
|
关于users、permissions和messages的更多内容请参考第14章。
|
|
|
ySJ
|
2.0/chapter09/#117 |
2010-04-15 17:18:05
|
如果<literal>TEMPLATE_CONTEXT_PROCESSORS</literal>包含这个处理器，每一个<literal>RequestContext</literal>将包含这些变量：
|
|
|
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/#157 |
2010-04-15 18:26:48
|
使用多个处理器是很容易的，所以你可以根据逻辑块来分解功能以便将来复用。
|
|
|
ySJ
|
2.0/chapter09/#159 |
2010-04-15 18:31:32
|
要注意 <literal>TEMPLATE_CONTEXT_PROCESSORS</literal> 里的context processor 将会在基于这个settings.py的<emphasis>每个</emphasis> 模板中有效，所以变量的命名不要和模板的变量冲突。
|
|
|
ySJ
|
2.0/chapter09/#162 |
2010-04-15 18:34:01
|
不论它们存放在哪个物理路径下，只要在你的Python搜索路径中，你就可以在 <literal>TEMPLATE_CONTEXT_PROCESSORS</literal> 设置里指向它们。
|
|
|
ySJ
|
2.0/chapter09/#163 |
2010-04-15 18:35:51
|
建议你把它们放在应用或者工程目录下名为 <literal>context_processors.py</literal> 的文件里。
|
|
|
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/#27 |
2010-04-15 12:49:40
|
变量标签被 <literal>{{</literal> 和 <literal>}}</literal> 包围：
|
|
|
ySJ
|
2.0/chapter09/#32 |
2010-04-15 13:24:50
|
模板 <emphasis>渲染</emphasis> 就是是通过从context获取值来替换模板中变量并执行所有的模板标签。
|
|
|
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/#45 |
2010-04-15 13:39:00
|
当你不想在一系例模板中都明确指定一些相同的变量时，你应该使用 <literal>RequestContext</literal> 。
|
|
|
ySJ
|
2.0/chapter09/#50 |
2010-04-15 13:39:43
|
是为了能够清晰的说明所有步骤。）
|
|
|
ySJ
|
2.0/chapter09/#53 |
2010-04-15 13:40:44
|
如果我们能把这些冗余去掉会不会更好？
|
|
|
ySJ
|
2.0/chapter09/#53 |
2010-04-15 13:40:52
|
如果我们把这些冗余去掉会不会更好？
|
|
|
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/#52 |
2010-04-15 13:41:38
|
每个视图都给模板传入了三个相同的变量：<literal>app</literal>、<literal>user</literal>和<literal>ip_address</literal>。
|
|
|
ySJ
|
2.0/chapter09/#67 |
2010-04-15 13:48:02
|
我们在这两个视图函数中用 <literal>RequestContext</literal> 代替了 <literal>Context</literal> 。在context对象的构建上有两个不同点。
|
|
|
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/#171 |
2010-04-15 18:38:04
|
一开始，这看起来是显示用户名的一个无害的途径，但是考虑如果用户输入如下的名字将会发生什么：
|
|
|
ySJ
|
2.0/chapter09/#296 |
2010-04-15 19:53:24
|
<literal>django.template.loaders.filesystem.load_template_source</literal> : 这个加载器根据 <literal>TEMPLATE_DIRS</literal> 的设置从文件系统加载模板。它默认是可用的。
|
|
|
ySJ
|
2.0/chapter09/#475 |
2010-04-16 14:57:51
|
应该避免使用 <literal>token.contents.split()</literal> （仅使用Python的标准字符串拆分）。
|
|
|
ySJ
|
2.0/chapter09/#557 |
2010-04-16 16:26:43
|
它返回一个<literal>django.template.NodeList</literal>实例，它是一个包含了所有<emphasis>Node</emphasis>对象的列表，这些对象是解析器在解析到任一元组中指定的标签之前遇到的内容.
|
|
|
ySJ
|
2.0/chapter09/#566 |
2010-04-16 16:28:16
|
分析直至另外一个模板标签并保存内容
|
|
|
ySJ
|
2.0/chapter09/#568 |
2010-04-16 16:30:36
|
在前一个例子中， <literal>do_comment()</literal> 抛弃了<literal>{% comment %}</literal> 和 <literal>{% endcomment %}</literal> 之间的所有内容。当然也可以修改和利用下标签之间的这些内容。
|
|
|
ySJ
|
2.0/chapter09/#570 |
2010-04-16 16:32:13
|
例如，这个自定义模板标签<literal>{% upper %}</literal>，它会把它自己和<literal>{% endupper %}</literal>之间的内容首字母大写：
|
|
|
ySJ
|
2.0/chapter09/#570 |
2010-04-16 16:34:33
|
例如，这个自定义模板标签<literal>{% upper %}</literal>，它会把它自己和<literal>{% endupper %}</literal>之间的内容编程大写：
|
|
|
ySJ
|
2.0/chapter09/#570 |
2010-04-16 16:34:42
|
例如，这个自定义模板标签<literal>{% upper %}</literal>，它会把它自己和<literal>{% endupper %}</literal>之间的内容变成大写：
|
|
|
ySJ
|
2.0/chapter09/#582 |
2010-04-16 16:36:16
|
许多模板标签接收单一的字符串参数或者一个模板变量引用，然后独立地根据输入变量和一些其它外部信息进行处理并返回一个字符串。
|
|
|
ySJ
|
2.0/chapter09/#583 |
2010-04-16 16:36:47
|
例如，我们先前写的<literal>current_time</literal>标签就是这样一个例子。
|
|
|
ySJ
|
2.0/chapter09/#584 |
2010-04-16 16:37:20
|
我们给定了一个格式化字符串，然后它返回一个字符串形式的时间。
|
|
|
ySJ
|
2.0/chapter09/#586 |
2010-04-16 16:45:47
|
为了简化这类标签，Django提供了一个帮助函数<literal>simple_tag</literal>。这个函数是<literal>django.template.Library</literal>的一个方法，它接受一个只有一个参数的函数作参数，把它包装在render函数和之前提及过的其他的必要单位中，然后通过模板系统注册标签。
|
|
|
ySJ
|
2.0/chapter09/#591 |
2010-04-16 16:46:20
|
在Python 2.4中，也可以使用装饰器语法：
|
|
|
ySJ
|
2.0/chapter09/#600 |
2010-04-16 16:47:21
|
参数两边的引号（如果有的话）已经被截掉了，所以我们会接收到一个普通Unicode字符串。
|
|
|
ySJ
|
2.0/chapter09/#556 |
2010-04-16 16:22:35
|
<literal>parser.parse()</literal> 接收一个包含了需要分析的模板标签名的元组作为参数。
|
|
|
ySJ
|
2.0/chapter09/#548 |
2010-04-16 16:19:31
|
分析直至另一个模板标签
|
|
|
ySJ
|
2.0/chapter09/#476 |
2010-04-16 14:58:24
|
它不够健壮，因为它只是简单的按照所有空格进行拆分，包括那些引号引起来的字符串中的空格。
|
|
