|
ySJ
|
2.0/chapter12/#79 |
2010-04-20 10:18:44
|
默认情况下它被设置为<literal>'[Django] '</literal>。
|
|
|
ySJ
|
2.0/chapter12/#78 |
2010-04-20 10:17:42
|
你还可以设置EMAIL_SUBJECT_PREFIX以控制Django使用的通知错误的e-mail的前缀。
|
|
|
ySJ
|
2.0/chapter12/#75 |
2010-04-20 10:16:44
|
它默认设置为'localhost'，这个设置对大多数的共享主机系统环境适用.
|
|
|
ySJ
|
2.0/chapter12/#74 |
2010-04-20 10:07:14
|
配置postfix,sendmail或其他邮件服务器超出了本书的范围，但与Django设置相关的是，你需要确保将EMAIL_HOST设置为你的邮件服务器的正确的主机名。
|
|
|
ySJ
|
2.0/chapter12/#74 |
2010-04-20 10:07:04
|
配置postfix,sendmail或其他邮件服务器超出了本书的范围，但与Django设置相关的是，你需要确保将EMAIL_HOST设置为你的邮件服务器的正确的主机名.
|
|
|
ySJ
|
2.0/chapter12/#73 |
2010-04-20 10:05:26
|
第二，确保你的服务器配置为可以发送电子邮件。
|
|
|
ySJ
|
2.0/chapter12/#70 |
2010-04-20 10:04:59
|
这个设置使用了类似于<literal>(姓名, Email)</literal>的元组，像这样：
|
|
|
ySJ
|
2.0/chapter12/#69 |
2010-04-20 09:54:10
|
首先，改变你的<literal>ADMINS</literal>设置用来引入你的E-mail地址，还有那些任何需要被通知出现异常的联系人的E-mail地址。
|
|
|
ySJ
|
2.0/chapter12/#67 |
2010-04-20 09:53:14
|
默认情况下，Django在你的代码引发未处理的异常时，将会给开发团队发送一封Email。但你需要做两件事来设置这种行为。
|
|
|
ySJ
|
2.0/chapter12/#66 |
2010-04-20 09:49:36
|
当你使用Django制作的网站运行中出现了异常，你会希望去了解它以便于修正它。
|
|
|
ySJ
|
2.0/chapter12/#50 |
2010-04-20 09:46:50
|
（它在<literal> sunserver</literal> 上也能工作，和在产品服务器上一样。）
|
|
|
ySJ
|
2.0/chapter12/#46 |
2010-04-20 09:44:36
|
假定你使用模板继承并定义了一个 <literal> base.html</literal>，该页面包含<literal>title</literal>和<literal>content</literal>两部分。
|
|
|
ySJ
|
2.0/chapter12/#43 |
2010-04-20 09:43:23
|
所以，当你准备部署你的应用时，你会需要创建这个模版并在里面放一些有意义的“页面未找到”的信息。
|
|
|
ySJ
|
2.0/chapter12/#42 |
2010-04-20 09:42:54
|
它会显示一个在你的模版根目录中名字叫<literal> 404.html</literal> 的模版。
|
|
|
ySJ
|
2.0/chapter12/#35 |
2010-04-20 09:37:21
|
类似地，你应该在生产环境中把<literal>TEMPLATE_DEBUG</literal>设为<literal>False</literal>。
|
|
|
ySJ
|
2.0/chapter12/#33 |
2010-04-20 09:36:03
|
关闭模板Debug模式
|
|
|
ySJ
|
2.0/chapter12/#27 |
2010-04-20 09:33:58
|
你的应用中任何未捕获的异常，从基本的Python语法错误到数据库错误以及模板语法错误都会返回漂亮的Django错误页面。
|
|
|
ySJ
|
2.0/chapter12/#25 |
2010-04-20 09:23:17
|
这个页面包含潜在的敏感信息，<emphasis>不</emphasis>应该暴露在公共互联网上。
|
|
|
ySJ
|
2.0/chapter12/#24 |
2010-04-20 09:22:24
|
任何404错误都将呈现Django的特殊的404页面(第3章有)而不是普通的404页面。
|
|
|
ySJ
|
2.0/chapter12/#22 |
2010-04-20 09:21:49
|
所有的数据库查询将以<literal>django.db.connection.queries</literal>的形式保存在内存中，你可以想象，它消耗内存！
|
|
|
ySJ
|
2.0/chapter12/#19 |
2010-04-20 09:18:32
|
我们在第2章，用命令 <literal>django-admin.py startproject</literal>创建了一个项目 , 其中创建的 <literal>settings.py</literal> 文件的 <literal>DEBUG</literal> 设置默认为 <literal>True</literal>。许多Django内部模块会检查这个设置， 如果 <literal>DEBUG</literal> 模式被开启的话会改变它们的行为。
|
|
|
ySJ
|
2.0/chapter12/#17 |
2010-04-20 09:16:35
|
关闭Debug模式
|
|
|
ySJ
|
2.0/chapter12/#15 |
2010-04-20 09:16:09
|
但是，有一些<emphasis>必要的事情</emphasis>你需要在发布之前完成。
|
|
|
ySJ
|
2.0/chapter12/#14 |
2010-04-20 09:13:39
|
很幸运，<literal>runserver</literal>非常接近于真实的Web服务器，所以我们不需要对Django应用做太多改动。
|
|
|
ySJ
|
2.0/chapter12/#10 |
2010-04-20 09:09:37
|
在本章，我们将展示如何部署，但我们首先要给你一个(要做的事的)清单.。
|
|
|
ySJ
|
2.0/chapter12/#9 |
2010-04-20 09:01:08
|
要部署你的Django应用，你需要把它挂接到工业强度的服务器上，如：Apache。
|
|
|
残阳似血
|
2.0/chapter10/#273 |
2010-04-20 09:00:18
|
下一章，我们将讲解Django的通用视图框架，使用它创建常见的网站可以节省时间。
|
错别字
|
|
ySJ
|
2.0/chapter12/#8 |
2010-04-20 09:00:16
|
但是<literal>runserver</literal>只是用来协助你进行本地开发的，并不适合发布到公网。
|
|
|
ySJ
|
2.0/chapter12/#7 |
2010-04-20 08:55:18
|
如果你一直跟着我们的例子做，你可能正在用<literal>runserver</literal>。使用这个命令确实很简单，你不必担心服务器的安装。
|
|
|
ySJ
|
2.0/chapter12/#5 |
2010-04-20 08:48:12
|
在服务器上部署它。
|
|
|
ySJ
|
2.0/chapter12/#4 |
2010-04-20 08:46:47
|
本章包含创建Django程序的最后一个必不可少的步骤：
|
|
|
wangnaide@gmail.com
|
2.0/chapter09/#212 |
2010-04-19 18:26:24
|
<literal>&</literal> 被转换为“ ”（分隔符）<literal>&</literal> |
|
|
ySJ
|
2.0/chapter11/#225 |
2010-04-19 16:36:42
|
在<reference name="next chapter" refuri="../chapter12/">下一章</reference>, 我们讲解了Django应用的部署。
|
|
|
ySJ
|
2.0/chapter11/#225 |
2010-04-19 16:36:20
|
在<reference name="next chapter" refuri="../chapter12/"></reference>, 我们讲解了Django应用的部署。
|
|
|
ySJ
|
2.0/chapter11/#222 |
2010-04-19 16:35:20
|
附录C详细地介绍了所有可用的视图，如果你想了解这些强大的特性，推荐你阅读一下。
|
|
|
ySJ
|
2.0/chapter11/#208 |
2010-04-19 16:32:29
|
注意
|
|
|
ySJ
|
2.0/chapter11/#200 |
2010-04-19 16:31:36
|
当然通用视图 <literal>object_detail</literal> 并不能处理这个问题，但是我们仍然可以很容易地编写一个自定义的视图来更新这个字段。
|
|
|
ySJ
|
2.0/chapter11/#199 |
2010-04-19 16:28:03
|
想象一下我们在 <literal>Author</literal> 对象里有一个 <literal>last_accessed</literal> 字段，我们用这个字段来记录最近一次对author的访问。
|
|
|
ySJ
|
2.0/chapter11/#193 |
2010-04-19 16:26:37
|
注意在前面这个例子中我们在 <literal>extra_context</literal>中传递了当前出版商这个参数。
|
|
|
ySJ
|
2.0/chapter11/#191 |
2010-04-19 16:20:18
|
注意
|
|
|
ySJ
|
2.0/chapter11/#187 |
2010-04-19 16:19:25
|
这样写没问题，因为通用视图就是Python函数。
|
|
|
ySJ
|
2.0/chapter11/#179 |
2010-04-19 16:17:49
|
之前，我们在URLconf中硬编码了出版商的名字，但是如果我们想用一个视图就显示某个任意指定的出版商的所有书籍，那该怎么办呢？
|
|
|
ySJ
|
2.0/chapter11/#169 |
2010-04-19 16:14:17
|
注意 在使用一个过滤的 <literal>queryset</literal> 的同时，我们还使用了一个自定义的模板名称。
|
|
|
ySJ
|
2.0/chapter11/#159 |
2010-04-19 16:11:55
|
大多数通用视图有一个<literal>queryset</literal>参数，这个参数告诉视图要显示对象的集合 （有关QuerySet的解释请看第五章的 “选择对象”章节，详细资料请参看附录B）。
|
|
|
ySJ
|
2.0/chapter11/#158 |
2010-04-19 16:11:13
|
现在让我们来仔细看看这个 <literal>queryset</literal> 。
|
|
|
ySJ
|
2.0/chapter11/#154 |
2010-04-19 16:10:18
|
注意 <literal>Book.objects.all</literal> 后面没有括号；这表示这是一个函数的引用，并没有真正调用它（通用视图将会在渲染时调用它）。
|
|
|
ySJ
|
2.0/chapter11/#147 |
2010-04-19 16:08:32
|
任何传递给<literal>extra_context</literal>的可调用对象（例如一个函数）都会在每次视图渲染前执行（而不是只执行一次）。
|
|
|
ySJ
|
2.0/chapter11/#146 |
2010-04-19 16:07:08
|
解决这个问题的办法是在 <emphasis>extra_context</emphasis> 中用一个回调（callback）来代替使用一个变量。
|
|
|
ySJ
|
2.0/chapter11/#139 |
2010-04-19 16:05:55
|
当你添加或删除出版商，你会发现在重启Web服务器之前，通用视图不会反映出这些修改（有关QuerySet何时被缓存和赋值的更多信息请参考附录C中“缓存与查询集”一节）。
|
|
|
ySJ
|
2.0/chapter11/#128 |
2010-04-19 15:54:29
|
所以要给视图提供所有出版商的列表，我们就用这样的info字典：
|
|
