|
ySJ
|
2.0/chapter12/#284 |
2010-04-20 17:29:42
|
尽管使用Apache和mod_python搭建Django环境是最具健壮性的，但在很多虚拟主机平台上，往往只能使用FastCGI。
|
|
|
ySJ
|
2.0/chapter12/#217 |
2010-04-20 16:23:38
|
因为 mod_python 缓存了载入的Python 的代码，所以当在 mod_python上发布 Django 站点时，你每改动一次代码就需要重启 Apache 一次。
|
|
|
ySJ
|
2.0/chapter12/#210 |
2010-04-20 16:20:26
|
使用 <literal>PythonInterpreter</literal> 指令来为不同的 <literal>location</literal>指定不同的解释器：
|
|
|
ySJ
|
2.0/chapter12/#206 |
2010-04-20 16:18:38
|
想实现这个，只要像下面这样使用 <literal>VirtualHost</literal>：
|
|
|
ySJ
|
2.0/chapter12/#144 |
2010-04-20 13:59:05
|
DJANGO_SETTINGS_MODULE是你的配置文件的Python的路径。
|
|
|
ySJ
|
2.0/chapter12/#152 |
2010-04-20 14:05:18
|
代码在Apache进程的整个生命周期内驻留在内存中，这对服务器调度有着非常积极的意义。
|
|
|
ySJ
|
2.0/chapter12/#159 |
2010-04-20 14:06:06
|
幸运的是，如果需要进一步学习Apache的相关知识，你可以找到相当多的绝佳资源。
|
|
|
ySJ
|
2.0/chapter12/#176 |
2010-04-20 14:27:07
|
然后，更改Apache配置文件，增加一个<literal></literal>命令指出Django的安装路径。
|
|
|
ySJ
|
2.0/chapter12/#176 |
2010-04-20 14:27:28
|
然后，更改Apache配置文件，增加一个<literal>Location</literal>命令指出Django的安装路径。
|
|
|
ySJ
|
2.0/chapter12/#185 |
2010-04-20 15:18:25
|
注意这里使用 <literal>Location</literal> 指令而不是 <literal>Directory</literal> 。
|
|
|
ySJ
|
2.0/chapter12/#187 |
2010-04-20 15:19:44
|
在这里使用<literal>Directory</literal>没有意义。
|
|
|
ySJ
|
2.0/chapter12/#196 |
2010-04-20 15:21:09
|
注意，你应该在产品服务器上设置 <literal>PythonDebug Off</literal> 。
|
|
|
ySJ
|
2.0/chapter12/#197 |
2010-04-20 15:22:07
|
如果你使用PythonDebug On的话，在程序产生错误时，你的用户会看到难看的（并且是暴露的）Python对错误的追踪信息。
|
|
|
ySJ
|
2.0/chapter12/#204 |
2010-04-20 15:36:13
|
如果你是一个独立的 Web 开发人员，只有一台服务器并有多个不同的客户时，你可能会想这么做。
|
|
|
ySJ
|
2.0/chapter12/#199 |
2010-04-20 16:11:58
|
重启 Apache 之后所有对你的站点的请求（或者是当你用了 <literal></literal> 指令后则是虚拟主机）都会由 Django 来处理。
|
|
|
ySJ
|
2.0/chapter12/#291 |
2010-04-20 17:32:35
|
借助于FastCGI，外部应用程序可以解释WEB服务器上的动态页面请求呢？
|
|
|
ySJ
|
2.0/chapter12/#69 |
2010-04-20 09:54:10
|
首先，改变你的<literal>ADMINS</literal>设置用来引入你的E-mail地址，还有那些任何需要被通知出现异常的联系人的E-mail地址。
|
|
|
ySJ
|
2.0/chapter11/#68 |
2010-04-19 15:11:27
|
<literal>direct_to_template</literal> 毫无疑问是非常有用的，但Django通用视图最有用的地方是呈现数据库中的数据。
|
|
|
ySJ
|
2.0/chapter11/#139 |
2010-04-19 16:05:55
|
当你添加或删除出版商，你会发现在重启Web服务器之前，通用视图不会反映出这些修改（有关QuerySet何时被缓存和赋值的更多信息请参考附录C中“缓存与查询集”一节）。
|
|
|
ySJ
|
2.0/chapter11/#146 |
2010-04-19 16:07:08
|
解决这个问题的办法是在 <emphasis>extra_context</emphasis> 中用一个回调（callback）来代替使用一个变量。
|
|
|
ySJ
|
2.0/chapter11/#147 |
2010-04-19 16:08:32
|
任何传递给<literal>extra_context</literal>的可调用对象（例如一个函数）都会在每次视图渲染前执行（而不是只执行一次）。
|
|
|
ySJ
|
2.0/chapter11/#154 |
2010-04-19 16:10:18
|
注意 <literal>Book.objects.all</literal> 后面没有括号；这表示这是一个函数的引用，并没有真正调用它（通用视图将会在渲染时调用它）。
|
|
|
ySJ
|
2.0/chapter11/#158 |
2010-04-19 16:11:13
|
现在让我们来仔细看看这个 <literal>queryset</literal> 。
|
|
|
ySJ
|
2.0/chapter11/#159 |
2010-04-19 16:11:55
|
大多数通用视图有一个<literal>queryset</literal>参数，这个参数告诉视图要显示对象的集合 （有关QuerySet的解释请看第五章的 “选择对象”章节，详细资料请参看附录B）。
|
|
|
ySJ
|
2.0/chapter11/#169 |
2010-04-19 16:14:17
|
注意 在使用一个过滤的 <literal>queryset</literal> 的同时，我们还使用了一个自定义的模板名称。
|
|
|
ySJ
|
2.0/chapter11/#179 |
2010-04-19 16:17:49
|
之前，我们在URLconf中硬编码了出版商的名字，但是如果我们想用一个视图就显示某个任意指定的出版商的所有书籍，那该怎么办呢？
|
|
|
ySJ
|
2.0/chapter11/#187 |
2010-04-19 16:19:25
|
这样写没问题，因为通用视图就是Python函数。
|
|
|
ySJ
|
2.0/chapter11/#191 |
2010-04-19 16:20:18
|
注意
|
|
|
ySJ
|
2.0/chapter11/#193 |
2010-04-19 16:26:37
|
注意在前面这个例子中我们在 <literal>extra_context</literal>中传递了当前出版商这个参数。
|
|
|
ySJ
|
2.0/chapter11/#128 |
2010-04-19 15:54:29
|
所以要给视图提供所有出版商的列表，我们就用这样的info字典：
|
|
|
ySJ
|
2.0/chapter11/#124 |
2010-04-19 15:51:05
|
<literal>object_detail</literal> 通用视图为context提供了出版商信息，但是看起来没有办法在模板中 获取 <emphasis>所有</emphasis> 出版商列表。
|
|
|
ySJ
|
2.0/chapter11/#123 |
2010-04-19 15:49:44
|
例如，考虑一下在每个出版商的详细页面显示所有其他出版商列表。
|
|
|
ySJ
|
2.0/chapter11/#69 |
2010-04-19 15:12:15
|
因为这个应用实在太普遍了，Django带有很多内建的通用视图来帮助你很容易 地生成对象的列表和明细视图。
|
|
|
ySJ
|
2.0/chapter11/#76 |
2010-04-19 15:12:45
|
要为所有的出版商创建一个列表页面，我们使用下面的URL配置：
|
|
|
ySJ
|
2.0/chapter11/#81 |
2010-04-19 15:15:19
|
我们可以通过在额外参数字典中包含一个<literal>template_name</literal>键来显式地告诉<literal>object_list</literal>视图使用哪个模板：
|
|
|
ySJ
|
2.0/chapter11/#84 |
2010-04-19 15:17:27
|
在缺少<literal>template_name</literal>的情况下，<literal>object_list</literal>通用视图将自动使用一个对象名称。
|
|
|
ySJ
|
2.0/chapter11/#85 |
2010-04-19 15:18:10
|
在这个例子中，这个推导出的模板名称将是 <literal>"books/publisher_list.html"</literal> ，其中books部分是定义这个模型的app的名称， publisher部分是这个模型名称的小写。
|
|
|
ySJ
|
2.0/chapter11/#103 |
2010-04-19 15:29:55
|
幸运的是，几乎每种情况都有相应的方法来简易地扩展通用视图以处理这些情况。
|
|
|
ySJ
|
2.0/chapter11/#108 |
2010-04-19 15:37:47
|
你也许已经注意到范例中的出版商列表模板在变量 <literal>object_list</literal> 里保存所有的书籍。这个方法工作的很好，只是对编写模板的人不太友好。
|
|
|
ySJ
|
2.0/chapter11/#109 |
2010-04-19 15:38:20
|
他们必须知道这里正在处理的是书籍。
|
|
|
ySJ
|
2.0/chapter11/#110 |
2010-04-19 15:38:36
|
更好的变量名应该是<literal>publisher_list</literal>，这样变量所代表的内容就显而易见了。
|
|
|
ySJ
|
2.0/chapter11/#112 |
2010-04-19 15:39:18
|
我们可以很容易地像下面这样修改 <literal>template_object_name</literal> 参数的名称：
|
|
|
ySJ
|
2.0/chapter11/#115 |
2010-04-19 15:43:36
|
在模板中，通用视图会通过在<literal>template_object_name</literal>后追加一个<literal>_list</literal>的方式来创建一个表示列表项目的变量名。
|
|
|
ySJ
|
2.0/chapter11/#199 |
2010-04-19 16:28:03
|
想象一下我们在 <literal>Author</literal> 对象里有一个 <literal>last_accessed</literal> 字段，我们用这个字段来记录最近一次对author的访问。
|
|
|
ySJ
|
2.0/chapter11/#200 |
2010-04-19 16:31:36
|
当然通用视图 <literal>object_detail</literal> 并不能处理这个问题，但是我们仍然可以很容易地编写一个自定义的视图来更新这个字段。
|
|
|
ySJ
|
2.0/chapter12/#22 |
2010-04-20 09:21:49
|
所有的数据库查询将以<literal>django.db.connection.queries</literal>的形式保存在内存中，你可以想象，它消耗内存！
|
|
|
ySJ
|
2.0/chapter12/#24 |
2010-04-20 09:22:24
|
任何404错误都将呈现Django的特殊的404页面(第3章有)而不是普通的404页面。
|
|
|
ySJ
|
2.0/chapter12/#25 |
2010-04-20 09:23:17
|
这个页面包含潜在的敏感信息，<emphasis>不</emphasis>应该暴露在公共互联网上。
|
|
|
ySJ
|
2.0/chapter12/#27 |
2010-04-20 09:33:58
|
你的应用中任何未捕获的异常，从基本的Python语法错误到数据库错误以及模板语法错误都会返回漂亮的Django错误页面。
|
|
|
ySJ
|
2.0/chapter12/#33 |
2010-04-20 09:36:03
|
关闭模板Debug模式
|
|
