|
ySJ
|
2.0/chapter08/#179 |
2010-04-14 11:09:56
|
比如说你有匹配某个模式的一堆视图，以及一个并不匹配这个模式但视图逻辑是一样的URL。
|
|
|
ySJ
|
2.0/chapter08/#179 |
2010-04-14 11:09:41
|
比如说你有匹配某个模式的一堆视图，以及一个并不匹配这个模式的视图逻辑是一样的URL。
|
|
|
ySJ
|
2.0/chapter08/#173 |
2010-04-14 11:07:42
|
正因如此，这技术已被很多Django的捆绑应用使用，其中以我们将在第11章讨论的通用视图系统最为明显。
|
|
|
ySJ
|
2.0/chapter08/#172 |
2010-04-14 11:06:57
|
这种使用额外的URLconf参数的技术以最小的代价给你提供了向视图函数传递额外信息的一个好方法。
|
|
|
ySJ
|
2.0/chapter08/#170 |
2010-04-14 11:05:03
|
而视图函数会把它当成另一个参数。
|
|
|
ySJ
|
2.0/chapter08/#170 |
2010-04-14 11:04:53
|
而视图函数会把它处理成另一个参数。
|
|
|
ySJ
|
2.0/chapter08/#169 |
2010-04-14 11:04:32
|
如你所见，这个例子中，URLconf指定了 <literal>template_name</literal> 。
|
|
|
ySJ
|
2.0/chapter08/#164 |
2010-04-14 11:03:54
|
一个关键字参数的字典：
|
|
|
ySJ
|
2.0/chapter08/#163 |
2010-04-14 11:03:29
|
URLconf里面的每一个模式都可以包含第三个数据：
|
|
|
ySJ
|
2.0/chapter08/#156 |
2010-04-14 11:01:50
|
起初你可能会想，通过对两个URL都使用同样的视图，在URL中使用括号捕捉请求，然后在视图中检查并决定使用哪个模板来去除代码的冗余，就像这样：
|
|
|
ySJ
|
2.0/chapter08/#133 |
2010-04-14 10:57:50
|
命名组的另一个好处就是可读性强。
|
|
|
ySJ
|
2.0/chapter08/#127 |
2010-04-14 10:56:02
|
使用命名组可以让你的URLconfs更加清晰，减少搞混参数次序的潜在BUG，还可以让你在函数定义中对参数重新排序。
|
|
|
ySJ
|
2.0/chapter08/#124 |
2010-04-14 10:54:55
|
而带命名组，同样的请求就会变成这样的函数调用：
|
|
|
ySJ
|
2.0/chapter08/#121 |
2010-04-14 10:54:20
|
例如，如果不带命名组，请求 <literal>/articles/2006/03/</literal> 将会等同于这样的函数调用：
|
|
|
ySJ
|
2.0/chapter08/#119 |
2010-04-14 10:43:34
|
取的值是以关键字参数的方式而不是以位置参数的方式传递给视图函数的。
|
|
|
ySJ
|
2.0/chapter08/#86 |
2010-04-14 10:17:12
|
在目前为止的所有 URLconf 例子中，我们使用简单的<emphasis>无命名</emphasis> 正则表达式组，即，在我们想要捕获的URL部分上加上小括号，Django 会将捕获的文本作为位置参数传递给视图函数。
|
|
|
ySJ
|
2.0/chapter08/#82 |
2010-04-14 09:55:25
|
在这个例子中，URL链接<literal>/debuginfo/</literal> 只在你的 <literal>DEBUG</literal> 配置项设为 <literal>True</literal> 时才有效。
|
|
|
ySJ
|
2.0/chapter08/#78 |
2010-04-14 09:51:57
|
说到动态构建 <literal>urlpatterns</literal>，你可能想利用这一技术，在 Django 的调试模式下修改 URLconf 的行为。
|
|
|
ySJ
|
2.0/chapter08/#56 |
2010-04-14 09:46:54
|
更 Pythonic，就是说，更符合 Python 的传统，如把函数当成对象传递。
|
|
|
ySJ
|
2.0/chapter08/#47 |
2010-04-14 09:43:10
|
更紧凑，因为不需要你导入视图函数。
|
|
|
ySJ
|
2.0/chapter08/#36 |
2010-04-14 09:38:45
|
我们可以把公共的前缀提取出来，作为第一个参数传给<literal></literal>函数：
|
|
|
ySJ
|
2.0/chapter08/#35 |
2010-04-14 09:26:53
|
在我们的URLconf例子中，每个视图字符串的开始部分都是<literal></literal>，造成重复输入。
|
|
|
ySJ
|
2.0/chapter08/#35 |
2010-04-14 09:26:35
|
在我们的URLconf例子中，每个视图字符串的开始部分都是<literal></literal>，需要重复输入。
|
|
|
ySJ
|
2.0/chapter08/#34 |
2010-04-14 09:24:35
|
当使用字符串技术时，你可以采用更简化的方式：提取出一个公共视图前缀。
|
|
|
ySJ
|
2.0/chapter08/#32 |
2010-04-14 09:20:31
|
使用这个技术，就不必导入视图函数了；Django 会在第一次需要它时根据字符串所描述的视图函数的名字和路径，导入合适的视图函数。
|
|
|
ySJ
|
2.0/chapter08/#21 |
2010-04-14 09:17:46
|
下面例子的URLconf与前一个等价：
|
|
|
ySJ
|
2.0/chapter08/#20 |
2010-04-14 09:00:56
|
(对每个新的view函数，你不得不记住要导入它，并且采用这种方法会使导入语句将变得相当长。)可以通过导入 views 模块本身来避免这个麻烦。
|
|
|
ySJ
|
2.0/chapter08/#16 |
2010-04-14 08:50:03
|
正如第三章中所解释的，在 URLconf 中的每一个入口包括了它所关联的视图函数，直接传入了一个函数对象。
|
|
|
ySJ
|
2.0/chapter07/#514 |
2010-04-13 18:27:51
|
第八章我们将回头并深入地讲解 视图和URLconfs（第三章已简单介绍）。
|
|
|
ySJ
|
2.0/chapter07/#511 |
2010-04-13 18:27:12
|
在学习本书的前面七章后，我们终于对于使用Django构建自己的网站足够了解了。
|
|
|
ySJ
|
2.0/chapter07/#511 |
2010-04-13 18:27:05
|
在学习本书的前面七章后，我们终于对于使用Django构建自己的网站足够了解了，
|
|
|
ySJ
|
2.0/chapter07/#509 |
2010-04-13 18:26:30
|
后面部分，从第八章到第十二章，将详细讲述高级（进阶）使用，包括如何部署一个Django应用程序（第十二章）。
|
|
|
ySJ
|
2.0/chapter07/#504 |
2010-04-13 18:25:11
|
在校验失败的情况下, 这段代码会在包含错误字段的div的class属性中增加一个"errors"，在一个无序列表中显示错误信息。
|
|
|
ySJ
|
2.0/chapter07/#465 |
2010-04-13 18:16:46
|
有一点很明确，<literal>clean_message()</literal>方法将在指定字段的默认校验逻辑执行<emphasis> 之后</emphasis> 被调用。（本例中，在必填<literal>CharField</literal>这个校验逻辑之后。）因为字段数据已经被部分处理，所以它被从<literal>self.cleaned_data</literal>中提取出来了。同样，我们不必担心数据是否为空，因为它已经被校验过了。
|
|
|
ySJ
|
2.0/chapter07/#414 |
2010-04-13 18:06:04
|
（当然，根据你邮件服务器的设置，当<literal>send_mail()</literal>被调用时，你可能会得到一个错误提示，这是另外一个问题了。）
|
|
|
ySJ
|
2.0/chapter07/#406 |
2010-04-13 18:04:11
|
以下示例说明了我们如何用forms框架重写<literal>contact()</literal>：
|
|
|
ySJ
|
2.0/chapter07/#401 |
2010-04-13 18:00:42
|
我们的contact form只涉及字符串类型，它们会被清理成Unicode对象。如果我们使用整数型或日期型，form框架会确保从cleaned_data使用合适的Python整数型或<literal>datetime.date</literal>型对象。
|
|
|
ySJ
|
2.0/chapter07/#393 |
2010-04-13 17:58:29
|
每一个绑定<literal>Form</literal>实体都有一个<literal>errors</literal>属性，它为你提供了一个字段与错误消息相映射的字典表。
|
|
|
ySJ
|
2.0/chapter07/#384 |
2010-04-13 17:56:33
|
如果我们不传入<literal>email</literal>值，它依然是合法的。因为我们指定这个字段的属性为<literal>required=False</literal>：
|
|
|
ySJ
|
2.0/chapter07/#374 |
2010-04-13 17:55:31
|
为了校验数据，我们创建一个新的<literal>Form</literal>对象，并且传入一个与定义匹配的字典类型数据：
|
|
|
ySJ
|
2.0/chapter07/#364 |
2010-04-13 17:50:36
|
默认输出按照HTML的<literal></literal>格式，另外有一些其它格式的输出：
|
|
ySJ
|
2.0/chapter07/#364 |
2010-04-13 17:49:35
|
默认输出按照HTML的<literal></literal>格式，另外有一些其它格式的输出：
|
|
ySJ
|
2.0/chapter07/#358 |
2010-04-13 17:47:39
|
它做的第一件事是将自己展示成HTML：
|
|
|
ySJ
|
2.0/chapter07/#357 |
2010-04-13 17:46:13
|
让我们深入Python解释器里面看看这个类做了些什么。
|
|
|
ySJ
|
2.0/chapter07/#353 |
2010-04-13 17:44:34
|
这看上去简单易懂，并且很像在模型中使用的语法。
|
|
|
ySJ
|
2.0/chapter07/#345 |
2010-04-13 17:40:21
|
当Django一次向公众发行时，它有一个复杂难懂的表单系统：<literal>django.forms</literal>。后来它被完全重写了，新的版本改叫作：<literal>django.newforms</literal>，这样人们还可以使用旧版本。
|
|
|
ySJ
|
2.0/chapter07/#337 |
2010-04-13 17:38:59
|
Django带有一个form库，称为django.forms，这个库可以处理我们本章所提到的包括HTML表单显示以及验证的问题。
|
|
|
ySJ
|
2.0/chapter07/#329 |
2010-04-13 17:37:29
|
我们可以手动地将原来提交的数据返回给模板，并且必须编辑HTML里的各字段来填充原来的值。
|
|
|
ySJ
|
2.0/chapter07/#325 |
2010-04-13 17:34:52
|
contact()视图可以正常工作，但是它的验证功能有些复杂。
|
|
|
ySJ
|
2.0/chapter07/#323 |
2010-04-13 17:34:04
|
这就是Web开发的最佳实践。
|
|
| |
