| 作者: | Django 团队 |
|---|---|
| 译者: | weizhong2004@gmail.com |
| 翻译开始日期: | 2006-04-04 |
| 翻译完成日期: | 2006-04-04 |
| 原文版本: | 2524 |
Django 起源于现实需要: 在我们快节奏的编辑部里, 我们经常只有大约一小时的时间以完成一个复杂的WEB应用(从仅有一个概念到发布完成). Django 被设计成不仅仅是快速的发布, 更重要的是保证正确无误.
如果没有那一大批开源项目--Apache, Python, and PostgreSQL 等等,Django根本不可能诞生. 我们觉得我们应该做点什么回报开源社区.
Django 名字来源于 Django Reinhardt, 他是一个吉普赛爵士乐手,活跃在上世纪三十年代至五十年代早期. 一直到今天,他仍然被认为是最佳的吉它手.
听听他的音乐,你会喜欢它们的.
根据 Wikipedia, "Django 被发音成 zhane-go (with a long 'a')."
我们已经使用 Django 差不多两年了. 用Django建成的站点访问量约为一小时一百万点击. 是的,它相当可靠. (原文:We've been using Django for almost two years. Sites built on Django have weathered traffic spikes of over one million hits an hour, and at least one Slashdotting. Yes, it's quite stable.)
与开发时间相比, 硬件是相当廉价的, 也正因为如此 Django 被设计成可以充分利用你有的硬件条件. Django 的数据库层 与 应用程序层 与生俱来就是清晰分离的, 它还拥有一个简单并且功能强大的 缓存框架.
Django 由 World Online 开发, 它是一家报纸的 WEB 部门.(位于 Lawrence, Kansas, USA.)
Adrian 是一个据有新闻背景的WEB开发人员. 在两年半的时间里,他是 World Online 的首席开发人员,在这期间Django被开发出来并据此建立了 World Online 的站点.现在他是 washingtonpost.com 的主要编辑, 在那里他继续他的 Django 开发工作. 他喜欢弹吉它(Django Reinhardt 风格) 和 hacking 象 chicagocrime.org 这样的项目.他生活在芝加哥.
在 IRC 上, Adrian 的昵称是 adrian_h.
Simon 来自英格兰, 他是一个很著名的WEB开发人员. 他在 World Online 实习过一年, 在那段时间他和 Adrian 从草稿开始开发了 Django. 他非常热心, 对WEB开发最佳化实践充满了热情, 并且他非常喜欢松鼠(也许这算个毛病?). 实习期后他返回大学一面继续学习,以完成他的学位,一面继续在WEB开发上做一些大的激动人心的东西.他生活在英格兰.
在 IRC 上, Simon 的昵称是 SimonW.
Jacob 是一个傲慢的家伙, 他来自加利福尼亚. 他花在编程和厨艺上的时间一样多. 他为 World Online 工作(WEB开发), 并且积极的 hacks on various cool side projects. 他对 Python-ObjC 绑定项目做出了贡献并且是解决如何用 Python 写 Tivo apps 第一人.后来他参与了 Python 的 PSP 项目. 他生活在 Lawrence, Kansas.
在 IRC 上, Jacob 的昵称是 jacobkm.
Wilson 的 design-fu makes us all look like rock stars. When not sneaking into apartment complex swimming pools, he's the Commercial Development Director for World Online, which means he makes the money that pays all our paychecks. He lives in Lawrence, Kansas.
On IRC, Wilson goes by wilsonian.
Django 维基展示了 Django-powered 站点列表. 你可以自由的将你的 Django-powered 站点添加到这个列表中.
这是因为 Django 严格来说不是 MVC 框架. 事实上我们不相信存在任何 capital-M 方法学; 我们做那些 "感觉" 对的东西. 如果你只是匆匆一瞥, 你可以称 Django 的 ORM 为 "Model", view 功能为 "View", 动态生成 API 为 "Controller" -- 事实上这不完全对.
其实你可以将 Django 称为一种 "MTV" 框架 -- 也就是说 Model,Template, 及 View 更容易被我们理解.
因此,尽管我们受到了 MVC 很深的影响 -- 特别是数据与逻辑分离部分 -- 在这么有意义的地方我们也还是迷途过.
我们清醒的意识到另有一些强大的 Web 框架存在, 我们并不反对从别的框架借鉴合适的东西. 正是因为我们不满意这种(多个框架混乱的)状态, 我们才开发了 Django .请了解因为 "<Framework X>" 实现的东西作为一个新特性添加到 Django 的理由不够充分,我们才没有实现它.
Django 项目开始于两年以前, 那时 Adrian 和 Simon 花了大量的时间研究各种各样的 Python Web 框架. 我们的意见是,它们中没有一种做得符合标准(足够好).
我们很挑剔.或许你可以称我们为(在有限时间内的)至善论者(或者叫十全十关主意者).
随着时间流逝, 我们偶然发现有些 开源库 做了一些我们已经实现的东西. 看到另外一些人用类似的方法解决类似的问题让人欣慰, 不过要整合这些外部代码已经太迟:我们已经写完,充分测试并且实现了我们自己的框架.并且我们的代码完美的满足了我们的需求.(原文:but it was too late to integrate outside code: We'd already written, tested and implemented our own framework bits in severalproduction settings -- and our own code met our needs delightfully.)
很多情况下,我们发现现存的 框架/工具 不可避免的多少有些不够成熟和小问题, 这些都令我们不够满意. 没有一个工具 100% 的符合我们的哲学.
就象我刚刚说过的,我们很挑剔.
在 设计哲学页 有我们的设计哲学文档.
毫无疑问,这些东西正在进行中. 不过,由于某些细节仍未最终定型(推敲中), 我们希望这些东西可以反映了 Django 1.0 的状态,而不是一个中间(易变的)状态.换句话说,由于 Django 的 API 还会有一些变化,我们现在不想花费太多精力在创建快照上.
当然, 还是有一些 非官方的快照 的,呵呵.
简短的回答: 当我们已经很满意 Django 的 API 时, 并且已经添加完所有我们认为 1.0 必须有的特性时, 并且准备从此向后兼容时. 应该在几个月后我们可以做到这一点.当然完全可能更早完成. 你可以理解为就是在 2006 年夏天.
当然, 你会注意到有 不少正式站点 使用了 Django. 没必要因为缺少1.0的某些特性东西就放弃选择 Django. (Don't let the lack of a 1.0 turn you off.)
Django 文档存在于每个 Django 安装的 docs 目录. 这些文档都是 ReST (restructured text) 格式, 并且每个文本文件对应 Django 官方站点上的一个 WEB 页面.
由于文档 stored in revision control, 你可以象浏览代码一样浏览文档的变化.
技术上讲, Django 站点上的文档由最新的开发版 ReST 文档生成而来. 因此 Django 站点上的文档会比 Django 发行版中的文档提供更多更新的信息.
只要运行 Django 发行版中的``ex_setup.py`` 脚本就可以.
Django 要求 Python 版本为 2.3 或更新
对一个开发环境来讲 -- 如果你仅仅相体验一下 Django --你不需要安装一个独立的 WEB 服务器; Django 自带了一个轻量级的开发版服务器. 如果要正式应用, 尽管 Django 遵循 WSGI 标准(意味着它可以运行在多种服务器平台), 我们还是建议采用 Apache 2 和 mod_python.
你当然还需要一个数据库引擎. 建议使用 PostgreSQL , 当然也支持 MySQL 和 SQLite 3 .
如果你只是打算在 本地计算机 上运行或者处于开发过程中, Django 自带的 WEB 服务器就足够用.
如果是正式应用, 我们建议 mod_python. Django 开发人员已经使用 mod_python 运行了差不多两年,它是相当的可靠.
不过如果你实在不想使用 mod_python, 你可以使用其它的服务器, 只要那个服务器支持 WSGI hooks. 参阅 server arrangements wiki page.
- 对 Python 2.4, 参照 mod_python & Python 2.3 指南.
- 对 Python 2.3, 从 http://www.modpython.org/ 获取 mod_python 并阅读 Running mod_python on Apache on Windows2000.
- 当然也可以看看这个 (非 Windows 专用) guide to getting mod_python working.
Django 开发人员每天都在改进 Django 并且 are pretty good about not checking in broken code. 在我们自己的服务器上,我们直接使用开发代码 (来自 Subversion 代码库). 因此可以认为开发版也很可靠. 我们建议你使用最新的开发代码,因为与官方发行版相比,它通常包含更多的特性和更少的错误.
请确保:
环境变量 DJANGO_SETTINGS_MODULE 被设置为完整的 Python 模块(如 "mysite.settings.main").
该模块位于 sys.path 中 (import mysite.settings.main 能够工作).
该模块不要包含语法错误 (当然).
如果你使用 mod_python 却 没有 使用 Django 的 request 处理器, 你需要处理一个 mod_python 的 bug(这涉及``SetEnv``的使用); 在你从Django import任何东西之前你需要做以下事情:
os.environ.update(req.subprocess_env)(此处 req 是 mod_python request object).
我们(想当然的)认为我们的模板引擎是自 chunky bacon 以来最好的东西. 不过我们也意识到选择哪种模板语言其实是一种信仰(或者说是习惯). Django 不会强制你使用哪种模板语言, 如果你喜欢 ZPT, Cheetah, 或者其它的别的, 你就自由的去用它吧.
在一个 model 中使用 FileField 或 ImageField 需要以下步骤:
- 在你的 settings 文件中, 定义一个完整路径给 MEDIA_ROOT 以便让 Django在此处保存上传文件. (出于性能考虑,这些文件并不保存到数据库.) 定义 MEDIA_URL 作为该目录的公共 URL. 要确保该目录对 WEB 服务器用户帐号是可写的.
- 在你的 model 中添加 FileField 或 ImageField, 并确保定义了 upload_to 选项,以告诉 Django 使用 MEDIA_ROOT 的哪个子目录保存上传文件.
- 你的数据库中要保存的只是文件的路径(相对于 MEDIA_ROOT). 出于习惯你一定很想使用 Django 提供的 get_<fieldname>_url 函数.举例来说,如果你的 ImageField 叫作 mug_shot, 你就可以在模板中以 {{ object.get_mug_shot_url }} 这样的方式得到图像的绝对路径.
如果你不介意数据库中的数据, 执行某个适当的 django-admin.py sqlreset 输出通过管道输送到相应的 数据库命令行程序 即可. 举例来说:
django-admin.py sqlreset appname | psql dbname
这里的 "psql" 假定你使用 PostgreSQL. 如果你用的是 MySQL, 则使用 mysql 这个命令行程序.
django-admin.py sqlreset 输出清除 app 的数据库表并创建新表的 SQL 语句.上面的命令使用 Unix 管道将SQL语句直接输送到 PostgreSQL 命令行程序.该程序接受 SQL 语句输入.
如果你在意表中数据,就要使用 ALTER TABLE 语句来手工修改数据表. 这也是我们经常使用的方式. 由于直接处理数据是非常敏感(而危险)的操作, 我们应尽量避免自动作业.也就是说, 我们已经做了一些工作添加了一个``django-admin.py updatedb`` 命令, 该命令可以输出需要的 ALTER TABLE 语句.
不支持. 目前仅支持单列的主键.
不过这实际上并不是一个问题, 因为没有任何人可以阻止你添加其它的约束(使用 unique_together model 选项或在数据上直接创建一个约束).类似admin 接口等等需要单列主键才可以工作. 很多时候,你需要一个简单的方式来指定一个对象,然后对其进行编辑或删除.
首先确认你的 Django DEBUG 设置成了 True. 然后,这样做:
>>> from django.core.db import db
>>> db.queries
[{'sql': 'SELECT polls_polls.id,polls_polls.question,polls_polls.pub_date FROM polls_polls',
'time': '0.002'}]
只有 DEBUG 是 True 时,``db.queries``才存在. 它是一个字典的列表,内容是顺序执行的 SQL 语句.每个字典有以下元素:
``sql`` -- 原始 SQL 语句 ``time`` -- 语句执行的时间,以秒计.
db.queries 包括所有的 SQL 语句 -- INSERTs, UPDATES, SELECTs, 等等. 只要你的程序访问数据, 这个查询就会被记录下来.
这是因为登录 cookie 没有被正确设置. 由于Django送出的 cookie 中的域名与你游览器中的域名不匹配,造成此现象.试着做以下两步:
- 在你的 admin config 文件中设置 SESSION_COOKIE_DOMAIN 选项, 以匹配你的域名. 举例来说, 如果你访问的是 "http://www.mysite.com/admin/" , 在你的"myproject.settings" 你应该设置 SESSION_COOKIE_DOMAIN = 'www.mysite.com'.
- 某些浏览器(Firefox?) 不喜欢从一个不包含句点的域名中接受 cookie. 如果你运行 admin site 在 "localhost" 或者其它的域名(不包含任何句点), 试试 "localhost.localdomain" 或 "127.0.0.1". 并设置相应的 SESSION_COOKIE_DOMAIN .
如果你确信你的用户名和密码正确, 你应该检查一下这个用户帐号的 is_active 和 is_staff 是否设置成了 True. admin 站点只允许这两个字段都设置成True的用户访问.
现在还做不到这一点, 不过由于很多人要求该特性,我们正在讨论该如何实现它.问题在于我们不想用当前请求层连接model 层和 admin 层(以得到当前用户). 这是一个难题.
现在还做不到,参见上一个问题的答案.
参阅 "如何通过 mod_python 使用 Django" 中的 serving the admin files 文档.
如果一个 ManyToManyField 只有不到两个关联对象的话,Django 就不会去麻烦的调用 filter .
举例来说 列表过滤器 包括 sites, 而目前数据库里只有一个 site , 就不会显示一个 "Site" filter. 因为, 按照 site 来过滤显然已经没有必要.
我们提供了一些选项.如果你只想在 Django 自动生成表单的基础之上做些修改,通过模块的 admin.js 参数， 你可以为这个页面自由添加新的 JavaScript 模块 . 这个参数是一个 URL 的列表, 指向被包含在 admin 表单中的 JavaScript 模块(通过一个 <script>标签).
如果调整自动生成表单仍然不能满足你的要求,你可以为 admin 写一个自定义的 view. admin 本身使用 Django 开发, 你完全能够写一个自定义 view 并挂接授权系统, 并实现你要做的任何事.
如果你只是想自定义 admin 界面的外观, 阅读下一个问题的答案.
我们认为它足够干净, 但你可能并不同意.你可以通过修改CSS文件和相应的图片文件来改变 adminsite 的外观.这个使用 HTML 构建, 只要你会编辑CSS,你就能让它变成你想要的样子. 我们已经制作了一个 admin CSS指南 来指导你如何开始.