|
ySJ
|
2.0/chapter09/#285 |
2010-04-15 19:49:47
|
<literal>django.template.loader.select_template(template_name_list)</literal> ： <literal>select_template</literal> 很像 <literal>get_template</literal> ，不过它是以模板名称的列表作为参数的。
|
|
|
ySJ
|
2.0/chapter09/#273 |
2010-04-15 19:47:47
|
这点对来自变量本身的数据不起作用。
|
|
|
ySJ
|
2.0/chapter09/#274 |
2010-04-15 19:46:46
|
如果必要,变量内容会自动转义,因为它们不在模板作者的控制下。
|
|
|
ySJ
|
2.0/chapter09/#273 |
2010-04-15 19:44:38
|
来源于变量本身的数据不受影响。
|
|
|
ySJ
|
2.0/chapter09/#222 |
2010-04-15 19:15:11
|
因为有时候模板变量包含了一些原始html数据，在这种情况下我们不想它们的内容被转意。
|
|
|
ySJ
|
2.0/chapter12/#250 |
2010-04-20 17:14:17
|
当然，这些信息是难看且难以阅读的，不过mod_python就是这么工作的。
|
|
|
ySJ
|
2.0/chapter12/#152 |
2010-04-20 14:05:18
|
代码在Apache进程的整个生命周期内驻留在内存中，这对服务器调度有着非常积极的意义。
|
|
|
ySJ
|
2.0/chapter12/#144 |
2010-04-20 13:59:05
|
DJANGO_SETTINGS_MODULE是你的配置文件的Python的路径。
|
|
|
ySJ
|
2.0/chapter12/#142 |
2010-04-20 13:38:34
|
DJANGO_SETTINGS_MODULE指向你的配置文件，而你的配置文件指向你的ROOT_URLCONF，在ROOT_URLCONF中指向了你的视图以及其他的部分。
|
|
|
ySJ
|
2.0/chapter12/#141 |
2010-04-20 13:36:36
|
在每一种环境中，你都需要告诉Web服务器你的DJANGO_SETTINGS_MODULE是什么,这是你的Django应用程序的入口。
|
|
|
ySJ
|
2.0/chapter12/#135 |
2010-04-20 13:26:31
|
那是由于它尝试从这个文件中导入一个叫做settings的模块，你可以通过修改manage.py 文件，将 import settings 语句改为导入你自己的模块，或者使用django-admin.py而不是使用manage.py，在后一种方式中你需要设置 DJANGO_SETTINGS_MODULE 环境变量为你的配置文件所在的Python 路径(比如'mysite.settings'）。
|
|
|
ySJ
|
2.0/chapter12/#132 |
2010-04-20 13:23:33
|
随便将你的settings.py重命名为settings_dev.py或settings/dev.py或foobar.py，Django 并不在乎你的配置文件叫什么名字，只要告诉它你使用哪个配置文件就可以了。
|
|
|
ySJ
|
2.0/chapter12/#128 |
2010-04-20 13:20:25
|
如果这个配置文件抛出任何异常，Django有可能发生很严重的崩溃。
|
|
|
ySJ
|
2.0/chapter12/#128 |
2010-04-20 13:20:07
|
如果这个配置文件抛出任何异常，Django有可能会发生很严重的崩溃。
|
|
|
ySJ
|
2.0/chapter12/#128 |
2010-04-20 13:19:56
|
如果这个配置文件抛出任何的异常，Django有可能会发生很严重的崩溃。
|
|
|
ySJ
|
2.0/chapter12/#127 |
2010-04-20 13:19:36
|
如果你打算采用这种方案，请确定这些配置文件中的代码是足够安全（防弹)的。
|
|
|
ySJ
|
2.0/chapter12/#126 |
2010-04-20 13:18:43
|
关键是配置文件仅仅是包含Python代码的文件。你可以从其他文件导入这些Python代码，可以通过这些代码执行任意的逻辑判断等操作。
|
|
|
ySJ
|
2.0/chapter12/#123 |
2010-04-20 13:14:44
|
在这里，我们从Python标准库导入了<literal>socket</literal>模块，使用它来检查当前系统的主机名。
|
|
|
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/#241 |
2010-04-20 16:41:03
|
在所有这些例子中，你必须设置 <literal>DocumentRoot</literal> ，这样Apache才能知道你存放静态文件的位置。
|
|
|
ySJ
|
2.0/chapter12/#232 |
2010-04-20 16:39:25
|
不过，如果你没有其他选择，只能在Django所在的Apache <literal>VirtualHost</literal> 上服务media文件，这里你可以针对这个站点的特定部分关闭mod_python：
|
|
|
ySJ
|
2.0/chapter12/#224 |
2010-04-20 16:37:12
|
更多的信息请参见 <reference name="http://docs.python.org/lib/module-logging.html" refuri="http://docs.python.org/lib/module-logging.html">http://docs.python.org/lib/module-logging.html</reference> 。
|
|
|
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/#199 |
2010-04-20 16:11:58
|
重启 Apache 之后所有对你的站点的请求（或者是当你用了 <literal></literal> 指令后则是虚拟主机）都会由 Django 来处理。
|
|
|
ySJ
|
2.0/chapter12/#204 |
2010-04-20 15:36:13
|
如果你是一个独立的 Web 开发人员，只有一台服务器并有多个不同的客户时，你可能会想这么做。
|
|
|
ySJ
|
2.0/chapter12/#197 |
2010-04-20 15:22:07
|
如果你使用PythonDebug On的话，在程序产生错误时，你的用户会看到难看的（并且是暴露的）Python对错误的追踪信息。
|
|
|
ySJ
|
2.0/chapter12/#196 |
2010-04-20 15:21:09
|
注意，你应该在产品服务器上设置 <literal>PythonDebug Off</literal> 。
|
|
|
ySJ
|
2.0/chapter12/#187 |
2010-04-20 15:19:44
|
在这里使用<literal>Directory</literal>没有意义。
|
|
|
ySJ
|
2.0/chapter12/#185 |
2010-04-20 15:18:25
|
注意这里使用 <literal>Location</literal> 指令而不是 <literal>Directory</literal> 。
|
|
|
ySJ
|
2.0/chapter12/#119 |
2010-04-20 13:12:59
|
达到这个目的，一个方法是检查当前的主机名。
|
|
|
ySJ
|
2.0/chapter12/#118 |
2010-04-20 13:12:34
|
最后，最精简的达到两个配置环境设定的方案是使用一个配置文件，在此配置文件中根据不同的环境进行设置。
|
|
|
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/#73 |
2010-04-20 10:05:26
|
第二，确保你的服务器配置为可以发送电子邮件。
|
|
|
ySJ
|
2.0/chapter12/#74 |
2010-04-20 10:07:04
|
配置postfix,sendmail或其他邮件服务器超出了本书的范围，但与Django设置相关的是，你需要确保将EMAIL_HOST设置为你的邮件服务器的正确的主机名.
|
|
|
ySJ
|
2.0/chapter12/#74 |
2010-04-20 10:07:14
|
配置postfix,sendmail或其他邮件服务器超出了本书的范围，但与Django设置相关的是，你需要确保将EMAIL_HOST设置为你的邮件服务器的正确的主机名。
|
|
