|
ySJ
|
2.0/chapter15/#77 |
2010-04-22 14:56:40
|
（这个名字随你的便，只要它是一个有效的表名，而且不是已经在您的数据库中使用的表名。）这个命令以Django的数据库缓存系统所期望的格式创建一个表。
|
|
|
ySJ
|
2.0/chapter15/#77 |
2010-04-22 14:53:12
|
（这个名字随你的便，只要它是一个有效的表名，而且不是已经在您的数据库中使用的表明。）这个命令以Django的数据库缓存系统所期望的格式创建一个表。
|
|
|
ySJ
|
2.0/chapter15/#76 |
2010-04-22 14:50:17
|
这里的[cache_table_name]是要创建的数据库表名。
|
|
|
ySJ
|
2.0/chapter15/#73 |
2010-04-22 14:48:18
|
为了使用数据库表作为缓存后端，首先在数据库中运行这个命令以创建缓存表：
|
|
|
ySJ
|
2.0/chapter15/#69 |
2010-04-22 14:47:17
|
毫无疑问，在Django的缓存后端不应该用于持久化，它们本来就被设计成缓存的解决方案。但我们仍然指出此点，这里是因为基于内存的缓存是暂时的。
|
|
|
ySJ
|
2.0/chapter15/#68 |
2010-04-22 14:37:58
|
显然，内存不是用来持久化数据的，因此不要把基于内存的缓存作为您唯一的存储数据缓存。
|
|
|
ySJ
|
2.0/chapter15/#68 |
2010-04-22 14:37:47
|
显然，内存不是用来持久化数据的，因此不要吧基于内存的缓存作为您唯一的存储数据缓存。
|
|
|
ySJ
|
2.0/chapter15/#67 |
2010-04-22 14:36:18
|
由于缓存的数据存储在内存中，所以如果您的服务器崩溃，数据将会消失。
|
|
|
ySJ
|
2.0/chapter15/#66 |
2010-04-22 14:35:42
|
最后有关Memcached的一点是，基于内存的缓存有一个重大的缺点。
|
|
|
ySJ
|
2.0/chapter15/#66 |
2010-04-22 14:35:13
|
最后关于Memcached的是基于内存的缓存有一个重大的缺点。
|
|
|
ySJ
|
2.0/chapter15/#60 |
2010-04-22 14:34:40
|
这个例子中，缓存在运行在IP地址为172.19.26.240和172.19.26.242，端口号为11211的Memcached实例间分享:
|
|
|
ySJ
|
2.0/chapter15/#58 |
2010-04-22 14:33:35
|
要充分利用此功能，请在CACHE_BACKEND里引入所有服务器的地址，用分号分隔。
|
|
|
ySJ
|
2.0/chapter15/#57 |
2010-04-22 14:33:02
|
这意味着您可以在多台机器上运行Memcached的守护进程，该程序会把这些机器当成一个单一缓存，而无需重复每台机器上的缓存值。
|
|
|
ySJ
|
2.0/chapter15/#57 |
2010-04-22 14:32:36
|
这意味着您可以在多台机器上运行Memcached的守护进程，该程序会当成一个单一缓存组机器，而无需重复每台机器上的缓存值。
|
|
|
ySJ
|
2.0/chapter15/#56 |
2010-04-22 14:31:53
|
Memcached的一个极好的特性是它在多个服务器间分享缓存的能力。
|
|
|
ySJ
|
2.0/chapter15/#51 |
2010-04-22 14:30:56
|
若要使用Memcached的Django，设置CACHE_BACKEND到memcached：/ / IP：port/，其中IP是Memcached的守护进程的IP地址，port是Memcached运行的端口。
|
|
|
ySJ
|
2.0/chapter15/#49 |
2010-04-22 14:30:05
|
如果您无法安装cmemcache，您可以安装python - Memcached，在ftp://ftp.tummy.com/pub/python-memcached/。如果该网址已不再有效，只要到Memcached的网站http://www.danga.com/memcached/），并从客户端API完成Python绑定。
|
|
|
ySJ
|
2.0/chapter15/#43 |
2010-04-22 14:28:38
|
在安装了Memcached本身之后，你将需要安装Memcached Python绑定，它没有直接和Django绑定。
|
|
|
2.0/chapter14/#23 |
2010-04-22 14:27:11
|
浏览器的开发者在很早的时候就已经意识到， HTTP协议的无状态性会对Web开发者带来很大的问题，于是(<emphasis>cookies</emphasis>)应运而生。
|
|
|
ySJ
|
2.0/chapter15/#39 |
2010-04-22 14:23:23
|
Memcached是免费的（http://danga.com/memcached）。它作为一个守护进程运行，并分配了特定数量的内存。
|
|
|
ySJ
|
2.0/chapter15/#32 |
2010-04-22 14:21:53
|
这里是一个CACHE_BACKEND所有可用值的解释。
|
|
|
ySJ
|
2.0/chapter15/#31 |
2010-04-22 14:20:41
|
缓存设置在settings文件的 <literal>CACHE_BACKEND</literal>中。
|
|
|
ySJ
|
2.0/chapter15/#28 |
2010-04-22 14:19:48
|
也就是说，你必须告诉它缓存的数据应该放在哪里，在数据库中，在文件系统，或直接在内存中。
|
|
|
ySJ
|
2.0/chapter15/#27 |
2010-04-22 14:18:31
|
缓存系统需要一些少量的设定工作。
|
|
|
ySJ
|
2.0/chapter15/#23 |
2010-04-22 14:17:28
|
这些类型的缓存你不直接控制，但是你可以提供关于你的站点哪部分应该被缓存和怎样缓存的线索(通过HTTP头部)给它们
|
|
|
ySJ
|
2.0/chapter15/#22 |
2010-04-22 14:16:50
|
Django也和"上游"缓存工作的很好，例如Squid(<reference name="http://www.squid-cache.org/" refuri="http://www.squid-cache.org/">http://www.squid-cache.org</reference>)和基于浏览器的缓存。
|
|
|
ySJ
|
2.0/chapter15/#6 |
2010-04-22 14:13:24
|
从处理器资源的角度来看，这是比较昂贵的。
|
|
|
ySJ
|
2.0/chapter15/#5 |
2010-04-22 14:12:43
|
也就是说每次用户访问一个页面，服务器要执行数据库查询，启动模板，执行业务逻辑以及最终生成一个你所看到的网页，这一切都是动态即时生成的。
|
|
|
ySJ
|
2.0/chapter15/#4 |
2010-04-22 14:07:49
|
动态网站的问题就在于它是动态的。
|
|
|
ySJ
|
2.0/chapter14/#742 |
2010-04-22 14:04:53
|
大多数情况下，你并不需要本章所提到的所有功能。但当你需要在用户间实现复杂交互时，最好能熟悉这些功能。
|
|
|
ySJ
|
2.0/chapter14/#728 |
2010-04-22 14:00:10
|
在例子视图中，系统在创建了播放列表（playlist）以后，为用户保存了一条消息。
|
|
|
ySJ
|
2.0/chapter14/#716 |
2010-04-22 13:58:27
|
每个消息都和一个 <literal>User</literal> 相关联。不存在过期和时间戳的概念。
|
|
|
ySJ
|
2.0/chapter14/#715 |
2010-04-22 13:56:09
|
消息系统会为给定的用户发送消息。
|
|
|
ySJ
|
2.0/chapter14/#708 |
2010-04-22 13:54:44
|
例如，你可以创建一个 <literal>'Special users'</literal> 组，并且允许组中的用户访问站点的一些VIP部分，或者发送VIP的邮件消息。
|
|
|
ySJ
|
2.0/chapter14/#705 |
2010-04-22 13:53:38
|
例如， 如果<literal>Site editors</literal> 组拥有 <literal>can_edit_home_page</literal> 权限，那么该组中的任何用户都拥有这个权限。
|
|
|
ySJ
|
2.0/chapter14/#701 |
2010-04-22 13:52:51
|
组提供了一种通用的方式来让你将用户分类，这样就可以为组内的用户授予权限规则或其他标签。
|
|
|
ySJ
|
2.0/chapter14/#695 |
2010-04-22 13:50:25
|
权限以 <literal>"._"</literal> 的形式出现。就是说，假如你的应用<literal>polls</literal>有一个<literal>Choice</literal>模型，那么对应的权限就是<literal>"polls.add_choice"</literal>，<literal>"polls.change_choice"<literal>和<literal>"polls.delete_choice"</literal>。
|
|
|
ySJ
|
2.0/chapter14/#690 |
2010-04-22 13:44:18
|
例如，我们可以允许Mary改变新闻故事，但是目前还不允许设置Mary只能改变自己创建的新闻故事，或者是给定状态，出版日期或者ID号的新闻故事。
|
|
|
ySJ
|
2.0/chapter14/#685 |
2010-04-22 13:39:31
|
只有设置了 <emphasis>change</emphasis> 权限的用户才能使用变更列表，变更表单，变更对象的视图。
|
|
|
ySJ
|
2.0/chapter14/#663 |
2010-04-22 13:34:29
|
这些用户的权限信息存储在 <literal>{{ perms }}</literal> 模板变量中。这是一些列权限方法的简短代理。
|
|
|
ySJ
|
2.0/chapter14/#658 |
2010-04-22 13:30:26
|
详细信息请参阅第九章。
|
|
|
ySJ
|
2.0/chapter14/#656 |
2010-04-22 13:29:52
|
从技术上来说，只有当你使用了 <literal>RequestContext</literal> |
|
|
ySJ
|
2.0/chapter14/#657 |
2010-04-22 13:29:38
|
<emphasis>并且</emphasis>TEMPLATE_CONTEXT_PROCESSORS 设置包含了 "django.core.context_processors.auth" （默认情况就是如此）时，这些变量才能在模板context中使用。
|
|
|
ySJ
|
2.0/chapter14/#656 |
2010-04-22 13:28:29
|
从技术上来说，只有当你使用了 <literal>RequestContext</literal>这些变量才可用。
|
|
|
ySJ
|
2.0/chapter14/#647 |
2010-04-22 13:26:26
|
这个表单需要一个叫 <literal>registration/register.html</literal> 的模板。这个模板可能是这样的：
|
|
|
ySJ
|
2.0/chapter14/#647 |
2010-04-22 13:26:13
|
这个表单需要一个叫 <literal>registration/register.html</literal> 的模板.。这个模板可能是这样的：
|
|
|
ySJ
|
2.0/chapter14/#644 |
2010-04-22 13:24:14
|
Django为此提供了可用的内置表单, 下面这个例子就使用了这个表单:
|
|
|
ySJ
|
2.0/chapter14/#643 |
2010-04-22 13:23:27
|
作为这个事情的最简化处理, 我们可以提供一个小视图, 提示一些必须的用户信息并创建这些用户。
|
|
|
ySJ
|
2.0/chapter14/#640 |
2010-04-22 13:22:42
|
最近每个开发人员都希望实现各自不同的注册方法，所以Django把写注册视图的工作留给了你。
|
|
|
ySJ
|
2.0/chapter14/#635 |
2010-04-22 13:22:03
|
加入salt值得hash并不是绝对安全的存储密码的方法，然而却是安全和方便之间很好的折衷。
|
|
