django2.0中文版本.docVIP

第十二章： 部署Django 5 1 本章包含创建一个django程序最必不可少的步骤 在服务器上部署它 1 如果你一直跟着我们的例子做，你可能正在用runserver 但是runserver 要部署你的django程序，你需要挂接到工业用的服务器 如：Apache 在本章，我们将展示如何做，但是，在做之前我们要给你一个(要做的事的)清单. 5 准备你的代码库 很幸运，runserver 但是，在开始前，有一些** 1 关闭Debug模式. 我们在第2章,用命令 django-admin.py startproject创建了一个项目 , 其中创建的 settings.py 文件的 DEBUG 设置默认为 True . django会根据这个设置来改变他们的行为， 如果 DEBUG 模式被开启. 例如， 如果 DEBUG 被设置成 True , 那么: 所有的数据库查询将被保存在内存中， 以 django.db.connection.queries 的形式. 你可以想象，这个吃内存! 任何404错误都将呈现django的特殊的404页面(第3章有)而不是普通的404页面。 这个页面包含潜在的敏感信息，但是不会暴露在公共互联网。 2 你的应用中任何未捕获的异常，从基本的python语法错误到数据库错误以及模板语法错误都会返回漂亮的Django错误页面。 这个页面包含了比404错误页面更多的敏感信息，所以这个页面绝对不要公开暴露。 简单的说，把`` DEBUG`` 设置成`` True`` 相当于告诉Django你的网站只会被可信任的开发人员使用。 Internet里充满了不可信赖的事物，当你准备部署你的应用时，首要的事情就是把`` DEBUG`` 设置为`` False`` 。 来关闭模板Debug模式。 1 类似地，你应该在生产环境中把TEMPLATE_DEBUGFalse 如果这个设为`` True`` ，为了在那个好看的错误页面上显示足够的东西，Django的模版系统就会为每一个模版保存一些额外的信息。 2 实现一个404模板 1 如果`` DEBUG`` 设置为`` True`` ，Django会显示那个自带的404错误页面。 但如果`` DEBUG`` 被设置成`` False`` ，那它的行为就不一样了： 他会显示一个在你的模版根目录中名字叫`` 404.html`` 的模版 所以，当你准备部署你的应用时，你会需要创建这个模版并在里面放一些有意义的“页面未找到”的信息 这里有一个`` 404.html``的示例，你可以从它开始。 假定你使用的模板继承并定义一个 `` base.html``,该页面由titlecontent两块组成。 {% extends base.html %} {% block title %}Page not found{% endblock %} {% block content %} h1Page not found/h1 pSorry, but the requested page could not be found./p {% endblock %} 要测试你的404.html页面是否正常工作，仅仅需要将DEBUG 设置为`` False`` ，并且访问一个并不存在的URL。 （它将在`` sunserver`` 上工作的和开发服务器上一样好） 2 实现一个500模板 类似的，如果`` DEBUG`` 设置为`` False`` ，Djang不再会显示它自带的应对未处理的Python异常的错误反馈页面。 作为代替，它会查找一个名为`` 500.html`` 的模板并且显示它。 像`` 404.html`` 一样，这个模板应该被放置在你的模板根目录下。 这里有一个关于500.html的比较棘手的问题。你永远不能确定`` 为什么``会显示这个模板，所以它不应该做任何需要连接数据库，或者依赖任何可能被破坏的基础构件的事情。 （例如：它不应该使用自定义模板标签。）如果它用到了模板继承，那么父模板也就不应该依赖可能被破坏的基础构件。因此，最好的方法就是避免模板继承，并且用一些非常简单的东西。 这是一个`` 500.html`` 的例子，可以把它作为一个起点： !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN /TR/html4/strict.dtd html lang=en head titlePage unavailable/title /head body h1Page unavailable/h1 pSorry, but the requested page is unavai