|
2.0/chapter08/#343 |
2009-11-29 04:17:13
|
考虑这个 URLconf/view 设计:
|
|
|
2.0/chapter14/#74 |
2009-12-02 11:40:38
|
cookie需要延续的时间（以秒为单位）
|
|
|
2.0/chapter14/#75 |
2009-12-02 11:42:14
|
如果参数是<literal></literal> |
|
|
2.0/chapter14/#75 |
2009-12-02 11:43:37
|
如果参数是<literal> None</literal> ，这个cookie会延续到浏览器关闭为止。
|
|
|
2.0/chapter14/#81 |
2009-12-02 11:44:55
|
cookie失效的实际日期/时间。
|
|
|
2.0/chapter14/#41 |
2009-12-02 11:48:52
|
Google会（以及目前）使用它在网页上显示你账号的用户名。
|
|
|
2.0/chapter14/#50 |
2009-12-02 11:52:30
|
每一个<literal> HttpRequest</literal> 对象都有一个<literal> COOKIES</literal> 对象，该对象的行为类似一个字典，你可以使用它读取任何浏览器发送给视图（view）的cookies。
|
|
|
2.0/chapter05/#445 |
2009-12-03 18:15:22
|
一旦你创建了模型，Django自动为这些模型提供了高级的Python API。
|
|
|
2.0/chapter08/#340 |
2009-12-07 10:45:56
|
视图函数的高级概念
|
|
|
2.0/chapter08/#342 |
2009-12-07 11:34:36
|
说到关于请求方法的分支，让我们来看一下可以用什么好方法来实现它。
|
|
|
2.0/chapter08/#342 |
2009-12-07 11:35:41
|
说到关于请求方法的分支，让我们来看一下可以用什么好的方法来实现它。
|
|
|
2.0/chapter08/#346 |
2009-12-07 11:40:02
|
在这个示例中，<literal> some_page</literal> 视图函数对<literal> POST</literal> |
|
|
2.0/chapter08/#346 |
2009-12-07 11:41:16
|
在这个示例中，<literal> some_page()</literal> 视图函数对<literal> POST</literal> |
|
|
2.0/chapter08/#347 |
2009-12-07 11:42:22
|
和<literal> GET</literal> 请求方法的处理完全不同。
|
|
|
2.0/chapter08/#347 |
2009-12-07 11:43:33
|
和<literal> GET</literal> 这两种请求方法的处理完全不同。
|
|
|
2.0/chapter08/#348 |
2009-12-07 11:44:41
|
它们唯一的共同点是共享一个URL地址：
|
|
|
2.0/chapter08/#349 |
2009-12-07 11:57:56
|
<literal></literal> .从这点来看，在同一个视图函数中对<literal> POST</literal> 和<literal></literal> 进行处理是一种很初级也很粗糙的做法。
|
|
|
2.0/chapter08/#349 |
2009-12-07 11:58:28
|
<literal></literal> .从这点来看，在同一个视图函数中对<literal> POST</literal> 和<literal></literal> 进行处理是一种很初级也很粗糙的做法。
|
|
|
2.0/chapter08/#349 |
2009-12-07 11:59:57
|
<literal></literal> .从这点来看，在同一个视图函数中对<literal> POST</literal> 和<literal> GET</literal> 进行处理是一种很初级也很粗糙的做法。
|
|
|
2.0/chapter08/#349 |
2009-12-07 12:01:42
|
<literal></literal> .正如大家所看到的，在同一个视图函数中对<literal> POST</literal> 和<literal> GET</literal> 进行处理是一种很初级也很粗糙的做法。
|
|
|
2.0/chapter08/#349 |
2009-12-07 12:02:51
|
<literal> /somepage/.</literal>正如大家所看到的，在同一个视图函数中对<literal> POST</literal> 和<literal> GET</literal> 进行处理是一种很初级也很粗糙的做法。
|
|
|
2.0/chapter08/#350 |
2009-12-07 12:08:57
|
一个比较好的设计习惯应该是，用两个分开的视图函数——一个处理<literal> POST</literal> 请求，另一个处理<literal> GET</literal> 请求，然后在相应的地方分别进行调用。
|
|
|
2.0/chapter08/#352 |
2009-12-07 12:19:00
|
我们可以像这样做：先写一个视图函数然后由它来具体分派其它的视图。
|
|
|
2.0/chapter08/#352 |
2009-12-07 12:22:57
|
我们可以像这样做：先写一个视图函数然后由它来具体分派其它的视图，在之前或之后可以执行一些我们自定的程序逻辑。
|
|
|
2.0/chapter08/#353 |
2009-12-07 12:27:15
|
下边的示例展示了这个技术是如何帮我们改进前边那个简单的<literal> some_page()</literal> 视图函数的：
|
|
|
2.0/chapter08/#353 |
2009-12-07 12:27:31
|
下边的示例展示了这个技术是如何帮我们改进前边那个简单的<literal> some_page()</literal> 视图的：
|
|
|
2.0/chapter08/#356 |
2009-12-07 12:29:21
|
让我们从头看一下代码是如何工作的：
|
|
|
2.0/chapter08/#358 |
2009-12-07 12:42:06
|
我们写了一个新的视图，<literal> method_splitter()</literal> ，它根据<literal> request.method</literal> 返回的值来调用相应的视图。可以看到它带有两个关键参数，<literal> GET</literal> 和<literal> POST</literal> ，也许应该是<emphasis> 视图函数</emphasis> 。如果<literal> request.method</literal> 返回<literal> GET</literal> ，那它就会自动调用<literal> GET</literal> 视图。
|
|
|
2.0/chapter08/#359 |
2009-12-07 12:43:07
|
如果<literal> request.method</literal> 返回的是<literal> POST</literal> ，那它调用的就是<literal> POST</literal> 视图。
|
|
|
2.0/chapter08/#360 |
2009-12-07 14:58:49
|
如果<literal> request.method</literal> 返回的是其它值（如：<literal> HEAD</literal> ），或者是没有把<literal> GET</literal> 或<literal> POST</literal> 提交给此函数，那它就会抛出一个<literal> Http404</literal> 错误。
|
|
|
2.0/chapter08/#362 |
2009-12-07 15:08:24
|
在URLconf中，我们把<literal> /somepage/</literal> 指到<literal> method_splitter()</literal> 函数，并把视图函数需要用到的<literal> GET</literal> 和<literal> POST</literal> 参数传递给它。
|
|
|
2.0/chapter08/#362 |
2009-12-07 15:10:43
|
在URLconf中，我们把<literal> /somepage/</literal> 指到<literal> method_splitter()</literal> 函数，并把视图函数额外需要用到的<literal> GET</literal> 和<literal> POST</literal> 参数传递给它。
|
|
|
2.0/chapter08/#364 |
2009-12-07 15:17:46
|
最终，我们把<literal> some_page()</literal> 视图分解到两个视图函数中<literal> some_page_get()</literal> 和<literal> some_page_post()</literal> 。这比把所有逻辑都挤到一个单一视图的做法要优雅得多。
|
|
|
2.0/chapter08/#366 |
2009-12-07 15:28:00
|
注意，在技术上这些试图函数就不用再去检查<literal> request.method</literal> 了，因为<literal> method_splitter()</literal> 已经替它们做了。
|
|
|
2.0/chapter08/#366 |
2009-12-07 15:28:20
|
注意，在技术上这些视图函数就不用再去检查<literal> request.method</literal> 了，因为<literal> method_splitter()</literal> 已经替它们做了。
|
|
|
2.0/chapter08/#367 |
2009-12-07 15:44:31
|
（比如，<literal> some_page_post()</literal> 被调用的时候，我们可以确信<literal> request.method</literal> 返回的值是<literal> post</literal> 。）当然，这样做不止更安全也能更好的将代码文档化，这里我们做了一个假定，就是<literal> request.method</literal> 会象我们所期望的那样工作。
|
|
|
2.0/chapter08/#367 |
2009-12-07 15:47:50
|
（比如，<literal> some_page_post()</literal> 被调用的时候，我们可以确信<literal> request.method</literal> 返回的值是<literal> post</literal> 。）当然，这样做不止更安全也能更好的将代码文档化，这里我们做了一个假定，就是<literal> request.method</literal> 能象我们所期望的那样工作。
|
|
|
2.0/chapter08/#369 |
2009-12-07 15:59:58
|
现在我们就拥有了一个不错的，可以通用的视图函数了，里边封装着由<literal> request.method</literal> 的返回值来分派不同的视图的程序。关于<literal> method_splitter()</literal> 就不说什么了，当然，我们可以把它们重用到其它项目中。
|
|
|
2.0/chapter04/#525 |
2009-12-14 11:46:31
|
<emphasis>假定设计师不是 Python 程序员</emphasis> 。模板系统开发人员认为：模板通常由设计师来编写而非程序员，因此不应被假定拥有Python开发知识。
|
|
|
2.0/chapter14/#12 |
2009-12-24 09:11:18
|
要开发一个真正令人心动的网站，我们必须面对浏览器后面活生生的人。
|
|
|
2.0/chapter11/#1 |
2009-12-26 21:07:59
|
通用视图
|
|
|
2.0/chapter08/#378 |
2009-12-26 21:55:29
|
这里我们已经重构了<1>method_splitter()<2>移除了 关键字参数<3>GET<4> 和<5>POST<6>，用<7>*args<8>和<9>**kwargs<10>取而代之。
|
|
|
2.0/chapter11/#115 |
2009-12-26 23:17:50
|
在模板内部，通用视图使用在<3>template_object_name<4> 后面添加<1>_list<2>的方法来创建变量表示项目集合。
|
|
|
2.0/chapter08/#254 |
2009-12-28 21:57:06
|
额外的选项
|
|
|
2.0/chapter08/#305 |
2009-12-28 21:57:53
|
（这是短路逻辑。）
|
|
|
2.0/chapter08/#480 |
2009-12-28 22:01:39
|
Hosting公司殷勤提供
|
|
|
2.0/chapter08/#479 |
2009-12-28 22:02:10
|
GNU Free Document License.
|
|
|
2.0/chapter07/#20 |
2009-12-28 22:06:47
|
|
