Changelog

全名 (Ascending) Unsort 页面 提交时间 (Descending) Unsort 内容 注释 ...
2.0/chapter09/#261 2010-01-02 13:24:32 就像我们前面提到的,过滤器也可以是字符串.
2.0/chapter09/#179 2010-01-02 13:12:11 类似的,如果name包含一个 <literal>'<'</literal> 字符,就会变成这样?
2.0/chapter08/#378 2010-01-01 18:35:37 这里,我们重构method_splitter(),去掉了GET和POST两个关键字参数,改而支持使用*args和和**kwargs(注意*号)
2.0/chapter08/#391 2010-01-01 18:30:05 (我们通过指定pop的缺省值为None,来避免由于一个或者多个关键字缺失带来的KeyError)
2.0/chapter08/#381 2010-01-01 18:26:19 如果你在函数定义时,在参数前面加两个*号,所有传递给函数的关键字参数,将会保存为一个字典
2.0/chapter08/#380 2010-01-01 18:25:08 如果你在函数定义时,只在参数前面加一个*号,所有传递给函数的参数将会保存为一个元组.
2.0/chapter08/#439 2010-01-01 18:18:31 .
2.0/chapter08/#400 2010-01-01 18:16:19 (注意,虽然我们还没有讲到request.user,但是14章将要讲到它.就如你所想像的,request.user描述当前用户是登陆的还是匿名)
2.0/chapter08/#426 2010-01-01 18:01:51 admin模块有他自己的URLconf,你仅仅只需要在你自己的代码中加入include就可以了.
2.0/chapter08/#425 2010-01-01 18:00:43 在前面第6章介绍Django的admin模块时我们曾经见过include.
2.0/chapter08/#441 2010-01-01 17:57:53 /weblog//2007/(包含两个斜杠)
2.0/chapter08/#444 2010-01-01 17:56:58 剩下的部分是/2007/ (最前面有一个斜杠),不匹配mysite.blog.urls中的任何一行.
2.0/chapter08/#443 2010-01-01 17:55:23 因为它有一个include(),django去掉了匹配的部,在这个例子中匹配的部分是'weblog/'
2.0/chapter08/#442 2010-01-01 17:53:54 在第一个URLconf中,r'^weblog/'匹配
2.0/chapter08/#408 2010-01-01 17:41:26 处理request.user.is_authenticated()这个验证,从而决定是否执行原来的view函数
2.0/chapter08/#408 2010-01-01 17:40:14 处理request.user.is_authenticated()这个验证,从而决定是否授权原来的view函数
2.0/chapter08/#407 2010-01-01 17:34:53 函数requires_login,传入一个视图函数view,然后返回一个新的视图函数new_view.这个新的视图函数new_view在函数requires_login内定义
2.0/chapter08/#410 2010-01-01 17:29:08 现在,我们可以从views中去掉if not request.user.is_authenticated()验证.我们可以在URLconf中很容易的用requires_login来包装实现.
2.0/chapter08/#414 2010-01-01 17:25:09 现在我们建立了一个漂亮,通用的函数requires_login()来帮助我们修饰所有需要它来验证的视图
2.0/chapter08/#413 2010-01-01 17:22:14 优化后的代码和前面的功能一样,但是减少了代码冗余
2.0/chapter09/#165 2009-12-31 10:29:11 html自动转意
2.0/chapter10/#95 2009-12-31 00:43:45 比如让我们看看如何添加一个num_pages域到第五章中Book模型。首先,我们会把开发环境中的模型改成如下形式:
2.0/chapter16/#0 2009-12-30 15:06:13 第十六章:集成的子框架
2.0/chapter07/#20 2009-12-28 22:06:47
2.0/chapter08/#479 2009-12-28 22:02:10 GNU Free Document License.
2.0/chapter08/#480 2009-12-28 22:01:39 Hosting公司殷勤提供
2.0/chapter08/#305 2009-12-28 21:57:53 (这是短路逻辑。)
2.0/chapter08/#254 2009-12-28 21:57:06 额外的选项
2.0/chapter11/#115 2009-12-26 23:17:50 在模板内部,通用视图使用在<3>template_object_name<4> 后面添加<1>_list<2>的方法来创建变量表示项目集合。
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/#1 2009-12-26 21:07:59 通用视图
2.0/chapter14/#12 2009-12-24 09:11:18 要开发一个真正令人心动的网站,我们必须面对浏览器后面活生生的人。
2.0/chapter04/#525 2009-12-14 11:46:31 <emphasis>假定设计师不是 Python 程序员</emphasis> 。模板系统开发人员认为:模板通常由设计师来编写而非程序员,因此不应被假定拥有Python开发知识。
2.0/chapter08/#369 2009-12-07 15:59:58 现在我们就拥有了一个不错的,可以通用的视图函数了,里边封装着由<literal> request.method</literal> 的返回值来分派不同的视图的程序。关于<literal> method_splitter()</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/#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/#366 2009-12-07 15:28:20 注意,在技术上这些视图函数就不用再去检查<literal> request.method</literal> 了,因为<literal> method_splitter()</literal> 已经替它们做了。
2.0/chapter08/#366 2009-12-07 15:28:00 注意,在技术上这些试图函数就不用再去检查<literal> request.method</literal> 了,因为<literal> method_splitter()</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/#362 2009-12-07 15:10:43 在URLconf中,我们把<literal> /somepage/</literal> 指到<literal> method_splitter()</literal> 函数,并把视图函数额外需要用到的<literal> GET</literal><literal> POST</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/#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/#359 2009-12-07 12:43:07 如果<literal> request.method</literal> 返回的是<literal> POST</literal> ,那它调用的就是<literal> POST</literal> 视图。
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/#356 2009-12-07 12:29:21 让我们从头看一下代码是如何工作的:
2.0/chapter08/#353 2009-12-07 12:27:31 下边的示例展示了这个技术是如何帮我们改进前边那个简单的<literal> some_page()</literal> 视图的:
2.0/chapter08/#353 2009-12-07 12:27:15 下边的示例展示了这个技术是如何帮我们改进前边那个简单的<literal> some_page()</literal> 视图函数的:
2.0/chapter08/#352 2009-12-07 12:22:57 我们可以像这样做:先写一个视图函数然后由它来具体分派其它的视图,在之前或之后可以执行一些我们自定的程序逻辑。
2.0/chapter08/#352 2009-12-07 12:19:00 我们可以像这样做:先写一个视图函数然后由它来具体分派其它的视图。
2.0/chapter08/#350 2009-12-07 12:08:57 一个比较好的设计习惯应该是,用两个分开的视图函数——一个处理<literal> POST</literal> 请求,另一个处理<literal> GET</literal> 请求,然后在相应的地方分别进行调用。
< 1 2 3 4 5 6 7 > » 96 pages