|
2.0/chapter02/#251 |
2009-11-22 15:54:29
|
而在 Django 中，这并不是一个好主意你不能这样做。
|
|
|
2.0/chapter02/#251 |
2009-11-22 16:05:16
|
而在 Django 中，把任何Python代码和web server的文档根(root)放在一起并不是一个好主意。因为这样做有使人能通过网路看到你原代码的风险.
|
|
|
2.0/chapter02/#252 |
2009-11-22 16:06:32
|
那太糟了。
|
|
|
2.0/chapter02/#243 |
2009-11-22 16:08:54
|
项目 是 Django 实例的一系列设置的集合，它包括数据库配置、Django 特定选项以及应用程序的特定设置。
|
|
|
2.0/chapter02/#241 |
2009-11-22 16:10:04
|
一但你安装好了python，django和（可选的）数据库及相关库，你就可以创建一个<emphasis>project</emphasis>，迈出开发django应用的第一步。
|
|
|
2.0/chapter02/#241 |
2009-11-22 16:11:00
|
一但你安装好了python，django和（可选的）数据库及相关库，你就可以通过创建一个<emphasis>project</emphasis>，迈出开发django应用的第一步。
|
|
|
2.0/chapter02/#236 |
2009-11-22 16:14:26
|
尽管如此，还是要记住：
Django 所捆绑的一些附加工具 一定 需要数据库，因此如果选择不使用数据库，你将不能使用那些功能。
|
|
|
2.0/chapter02/#237 |
2009-11-22 16:17:51
|
(我们将在本书中自始至终强调这些功能)
|
|
|
2.0/chapter02/#326 |
2009-11-22 16:24:11
|
完成这些设置后，你所在的本地网络中的其它计算机，就可以在浏览器中，访问你的 IP 地址了。比如：
<reference name="http://192.168.1.103:8000/" refuri="http://192.168.1.103:8000/">http://192.168.1.103:8000/</reference> . (注意，你或许需要单独地去确认一下在本地网络中，你的电脑的 IP 地址)
|
|
|
2.0/chapter02/#332 |
2009-11-22 16:24:47
|
好了，你已经安装好一切所需， 并且开发服务器也运行起来了，你已作好了准备可以继续 <reference name="learn the basics" refuri="../chapter03/">learn the basics</reference> ---用Django伺候网頁, 这一章的内容。
|
|
|
2.0/chapter02/#326 |
2009-11-22 16:28:30
|
完成这些设置后，你本地网络中的其它计算机就可以在浏览器中访问你的 IP 地址了。比如：
<reference name="http://192.168.1.103:8000/" refuri="http://192.168.1.103:8000/">http://192.168.1.103:8000/</reference> . (注意，你或许需要单独地去确认一下在本地网络中，你的电脑的 IP 地址)
|
|
|
2.0/chapter02/#326 |
2009-11-22 16:33:11
|
完成这些设置后，你本地网络中的其它计算机就可以在浏览器中访问你的 IP 地址了。比如：
<reference name="http://192.168.1.103:8000/" refuri="http://192.168.1.103:8000/">http://192.168.1.103:8000/</reference> . (注意，你将需要校阅一下你的网络配置来决定你在本地网络中的IP 地址)
|
|
|
2.0/chapter02/#218 |
2009-11-22 16:39:39
|
3.X 版本不支持嵌套子查询和一些其它相当标准的SQL语句。
|
|
|
2.0/chapter02/#224 |
2009-11-22 16:41:31
|
在Django中使用Oracle数据库
|
|
|
2.0/chapter02/#262 |
2009-11-22 16:50:34
|
如果你使用一个trunk版本，你会在 <literal>djtrunk/django/bin</literal>
下发现 <literal>django-admin.py</literal> 。你将来会常用到<literal>django-admin.py</literal>，考虑把它加到你的系统路径中去比较好。
|
|
|
2.0/chapter02/#260 |
2009-11-22 16:51:57
|
如果用的是 <literal>setup.py</literal> 工具安装的 Django ， <literal>django-admin.py</literal> 应该已被加入了系统路径中。
|
|
|
2.0/chapter02/#252 |
2009-11-22 16:53:03
|
那就太糟了。
|
|
|
2.0/chapter03/#3 |
2009-11-22 16:55:43
|
前一章中，我们解释了如何建立一个 Django 项目并运行 Django 开发服务器。
|
|
|
2.0/chapter03/#9 |
2009-11-22 16:58:24
|
作为我们的第一个目标，让我们创建一个网页，用来输出这个著名的示例消息：
|
|
|
2.0/chapter03/#21 |
2009-11-22 17:03:29
|
在上一章使用<literal>django-admin.py startproject</literal>制作的<literal>mysite</literal>文件夹中，创建一个叫做<literal>views.py</literal>的空文件。这一章中, 这个Python模块将包含我们的视图。
|
|
|
2.0/chapter03/#25 |
2009-11-22 17:08:13
|
这就是你需要键入到<literal>views.py</literal>文件中的整个函数和导入声明，：
|
|
|
2.0/chapter03/#25 |
2009-11-22 17:08:31
|
这就是你需要键入到<literal>views.py</literal>文件中的整个函数和导入声明：
|
|
|
2.0/chapter03/#30 |
2009-11-22 17:10:06
|
首先，我们从 <literal>django.http</literal> 模块中导入（import） <literal>HttpResponse</literal> 类。参阅附录 H 了解更多关于 HttpRequest 和 HttpResponse 的细节。
|
|
|
2.0/chapter03/#36 |
2009-11-22 17:18:20
|
这是一个包含触发此视图的当前Web请求信息的对象，是<literal>django.http.HttpRequest</literal>类的一个实例。在这个示例中，我们虽然不用<literal>request</literal>做任何事情，然而它仍必须是这个视图的第一个参数。
|
|
|
2.0/chapter03/#40 |
2009-11-22 17:21:31
|
在下一小节: 你的地一个 URLconf，将聚焦在Django是如何找到这个函数的。
|
|
|
2.0/chapter03/#46 |
2009-11-22 17:25:42
|
一个视图就仅是一个Python函数。这个函数第一个参数是HttpRequest；它返回一个HttpResponse实例。为了使一个Python的函数成为一个Django视图，它必须干俩件事。
|
|
|
2.0/chapter03/#47 |
2009-11-22 17:26:10
|
（也有例外，但是我们稍后才会接触到。)
|
|
|
2.0/chapter03/#46 |
2009-11-22 17:27:01
|
一个视图就仅是一个Python函数。这个函数第一个参数是HttpRequest；它返回一个HttpResponse实例。为了使一个Python的函数成为一个Django视图，它必须干这俩件事。
|
|
|
2.0/chapter03/#52 |
2009-11-22 17:34:36
|
那是因为我们的mysite项目还对hello视图一无所知。我们需要明白的告诉Django: 我们正在用一个特别的URL来激活这个视图。
|
|
|
2.0/chapter03/#52 |
2009-11-22 17:35:14
|
那是因为我们的mysite项目还对hello视图一无所知。我们需要明白的告诉Django: 我们正在用一个特有的URL来激活这个视图。
|
|
|
2.0/chapter03/#53 |
2009-11-22 17:38:42
|
（继续我们刚才类似发布静态HTML文件的例子。现在我们已经创建了HTML文件，但还没有把它上传至服务器的目录。）为了1在Django中绑定视图函数和URL，我们使用URLconf。
|
|
|
2.0/chapter10/#132 |
2009-11-23 21:17:43
|
从Model中删除一个字段要比添加容易得多
|
|
|
2.0/chapter10/#133 |
2009-11-23 21:19:57
|
删除字段，仅仅只要以下几步
|
|
|
2.0/chapter10/#135 |
2009-11-23 21:21:07
|
删除字段，然后重新启动你的web服务器
|
|
|
2.0/chapter03/#237 |
2009-11-25 22:44:17
|
最重要的设置是ROOT_URLCONF，它将作为URLconf告诉Django在这个站点中那些Python的模块将被用到
|
|
|
2.0/chapter17/#67 |
2009-11-29 03:53:13
|
出于性能的考虑，每个已启用的中间件在每个服务器进程中只初始化 <emphasis>一</emphasis> 次。
|
|
|
2.0/chapter17/#68 |
2009-11-29 03:55:37
|
也就是说 <3>__init__()<4> 仅在服务进程启动的时候调用，而在针对单个request处理时并不执行。
|
|
|
2.0/chapter17/#67 |
2009-11-29 03:56:07
|
出于性能的考虑，每个已启用的中间件在每个服务器进程中只初始化 <emphasis>一</emphasis> 次。也就是说 <3>__init__()<4> 仅在服务进程启动的时候调用，而在针对单个request处理时并不执行。
|
|
|
2.0/chapter17/#67 |
2009-11-29 03:56:37
|
出于性能的考虑，每个已启用的中间件在每个服务器进程中只初始化 <emphasis>一</emphasis> 次。也就是说 <3>__init__()<4> 仅在服务进程启动的时候调用，而在针对单个request处理时并不执行。
|
|
|
2.0/chapter17/#67 |
2009-11-29 03:56:41
|
出于性能的考虑，每个已启用的中间件在每个服务器进程中只初始化 <emphasis>一</emphasis> 次。也就是说 <3>__init__()<4> 仅在服务进程启动的时候调用，而在针对单个request处理时并不执行。
|
|
|
2.0/chapter17/#68 |
2009-11-29 03:57:03
|
ssss
|
|
|
2.0/chapter17/#68 |
2009-11-29 03:58:52
|
也就是说
|
|
|
2.0/chapter17/#68 |
2009-11-29 04:02:23
|
This means that is called only once at server startup not for individual requests.
|
|
|
2.0/chapter17/#68 |
2009-11-29 04:04:18
|
也就是说 __init__() 仅在服务进程启动的时候调用，而在针对单个request处理时并不执行。
|
|
|
2.0/chapter17/#68 |
2009-11-29 04:06:20
|
也就是说 __init__() 仅在服务进程启动的时候调用，而在针对单个request处理时并不执行。
|
|
|
2.0/chapter17/#68 |
2009-11-29 04:08:09
|
也就是说 <literal>__init__()</literal> 仅在服务进程启动的时候调用，而在针对单个request处理时并不执行。
|
|
|
2.0/chapter08/#343 |
2009-11-29 04:17:13
|
考虑这个 URLconf/view 设计:
|
|
|
2.0/chapter14/#74 |
2009-12-02 11:40:38
|
cookie需要延续的时间（以秒为单位）
|
|
|
2.0/chapter14/#75 |
2009-12-02 11:42:14
|
如果参数是<literal></literal> |
|
|
2.0/chapter14/#75 |
2009-12-02 11:43:37
|
如果参数是<literal> None</literal> ，这个cookie会延续到浏览器关闭为止。
|
|
