;
   但是再往下，还是有点担心。一是Ajax，“Ajax With Django”这篇文章给出的资源靠谱；二是将来升级的问题，毕竟Django还没有到达1.0。

  ;

  对于Ajax和Django的集成问题，到底选择集成Dojo，还是选择集成JQuery，还是像TurboGears一样直接用MochiKit？

  ;

  论坛中，11月3日，James Bennett回答很酷：

“

On 11/3/06, Enquest <[EMAIL PROTECTED]> wrote:
> What would it take to integrate jquery to Django?
> Just like now is happening with Dojo... I think however jquery is a
> better lib ...

Dojo integration was a fleeting, now-discarded idea. Django will not
be "integrating" any JS toolkit. One good reason for this is evident
in your post: no matter which one was chosen, someone would always be thinking that some other toolkit would have been better.”

   是啊，总有人会不满意的。just遵循这个原则“make the simple things easy and the complex things possible.”

   大陆这边可能由于blogspot被封的原因，很少有人能看到11月9日台北thegive写的《从 Django 看 Ruby on Rails 成功的原因》。是啊，是及时切换到RoR，还是等待Django，还是TurboGears？这是一个问题。

    Ian Maurer倒是给出了TurboGears和Django的比较，请看后面的资源二。

虽然limodou推出了《Django Step by Step》，但似乎Python的Web框架介绍远远不如RoR的多和精彩。

;

资源一：

从 Django 看 Ruby on Rails 成功的原因

这里有一份对岸 cookoo 写的对Django的遗憾，真是一篇好文章，里面描写到 Django 如何错失大鸣大放的机会。我看完之后，突然发现 cookoo 这篇文章藉由 Django 的缺点，他也顺便偷偷分析了 Ruby on Rails 成功的原因。大家可以来看看

1. django的原始码改动频繁
2. ORM API 繁琐（后来按ActiveRecord风格重写）
3. 没有整合的测试框架
4. 没出书，文件相比Rails缺之甚多
5. python内部有人对django完全独立的一套full-stack系统有不同看法，又搞了很多别的框架（比如turbogears）
6. django对AJAX热潮无动于衷

相比起来

1. Rails Team 相当稳定，很少大改
2. ORM 太优美了
3. 出的书籍一级棒，文件也相当多
4. Ruby 因为社群小，超级团结
5. Full Stack 框架，Unit Test 内建
6. RJS 赶上 AJAX 热潮，炒热不少话题

虽然 Open Source 技术为本，但是撇开 Ruby on Rails 优秀的技术不谈。

• 假如大家都不写文件，Ruby on Rails 的文件不够多的话，有人敢用一个不熟悉的语言吗？
• 没有将 Ruby 社群主力放在 Rails 身上，写得出那么多 API 吗？
• 没有团结的团队，人员来来去去，吵来吵去的团队作得出好作品吗？
• 没有 DHH 肯花写程序以外的时间推销 Rails ，并且花众多时间写出一本Agile Web Development with Rails，会更多人愿意花时间去学习一个听都没听过，也没有公司support 的 Ruby on Rails 吗？

一 向是一盘散沙的 Open Source 社群可以仔细思考一下 Ruby on Rails 带给大家的启示。Ruby 社群向心力强，不分散力量，又懂得出书以及掌握时势用RJS炒热话题。这说明，团队管理好，向心力强，营销强，正是 Ruby on Rails 扩散那么快速的主因。其实，这不正是一个好商业团队应该具备的特质吗？

资源二：

TurboGears 和 Django 的比较

Django 和 TurboGears 都是 MVC 风格的框架，开发人员可以利用这些技术使用 Python 语言快速开发 Web 站点。为了选择最适合您的需求的技术，请考虑以下区别：

• 背景：

这两个项目与 Ruby on Rails 一样，都是从现有的应用程序中提取出来发布到开源社区中的。Django 的历史比较长，来源于一个每天服务于数百万次页面查看请求的在线报纸服务。TurboGears 是从一个胖客户机 —— RSS News Reader 应用程序，目前仍在开发中 —— 中提取出来的。TurboGears 的社区驱动力比 Django 更好，因为它是在现有开源组件上建立起来的。

这两个项目之间背景的差异导致了不同的项目优先级。Django 项目来源于迅速变化的在线出版业，它重点关注的是一个可以快速构建并修改基于内容的应用程序的框架。TurboGears 项目的基础是消费产品，重点关注的是胖客户机应用程序和可插入体系架构。

• URLs：

TurboGears 的请求分发机制通过控制器类和方法名进行路由。在添加新控制器类或方法之后，它们就自动变为可用的了。如果我们需要修改执行给定控制器的路径，就需要对代码结构重新进行配置。反之，Django 使用了一个单独的基于正则表达式的配置文件将 URL 映射为底层代码，这样就降低了 URL 路径结构与实际实现之间的耦合程度。

TurboGears 系统的设置比 Django 更加快捷，因为它只需要一个 expose 操作让新页面变成可用即可。然而，Django 配置系统可以进行最大限度的控制和灵活性。在发生重大变化之后，Django URL 可以简单地重新映射到应用程序上。这个帮助防止由于旧书签或缓存搜索引擎结果引起的 “链接失效” 的情况。“链接失效” 会对 Django 设计用来创建的基于内容的 Web 站点的通信级和可用性造成很大的影响。

• 代码重用：

TurboGears 团队将他们的项目称为大框架，这样清晰地表达了 TG 是一个由现有的很多组件构成的项目这一思想。TurboGears 团队选择并集成了最好的开源代码，而不是从头重新开始编写。TurboGears 框架的另一个优势是这是一个由很多社区构成的大项目。TG 现在功能已经非常强大，正在强力促进大家对构成 TurboGears 核心组件的兴趣和参与。这样可以起到水涨船高的效果。

另外一方面，Django 是在 2003 年创建的，当时 Python 组件的状态还不像现在一样稳定。Django Web 栈是从头开始创建的，最终的结果是获得了一个稳定的框架，这个框架已经被用来创建了多个每天处理数百万点击率的 Web 站点。然而，有些人评论说 Django 项目可能会由于缺乏代码的重用而遭遇 NIH（Not Invented Here）问题。Django 团队的立场是在 Python 中从头创建一个框架所需要的工作不会比将现有的组件拼装在一起更困难，这样最终可以生成一个更统一的框架。

• JavaScript：

TurboGears 在自己的框架中首先提供了 MochiKit，这是一个 JavaScript 库。这个团队还创建了一个部件库，它可以充分利用 JavaScript 创建丰富的表单元素。这显示了胖客户机（Ajax）开发在 TurboGears 世界中是多么重要。Django 团队没有选择使用一个 JavaScript 库来默认地包含自己的框架，但是他们已经对这种可能性展开了讨论。这两个项目都不会限制我们使用任何 JavaScript 库。

• 管理工具：

这两个项目都有管理接口。Django 管理工具的目标用户是那些需要良好数据入口工具的终端用户，这样每次向应用程序中添加新功能时就不需要对工具进行定制了。另一方面，TurboGears 管理工具重点关注的是开发人员的需要：它为开发人员提供了一组设计工具，以及一个基本的数据库查看器和编辑器。

• 许可证：

由于 Django 是从头开始创建的，因此整个项目都使用的是开源许可证（BSD 许可证）。TurboGears 是由多个项目构成的，使用了多个许可证。SQLObject（ORM 工具）是使用 LGPL（Lesser General Public License）保护的，这说明对 SQLObject 进行的任何直接修改都需要贡献回这个项目。这个许可证并不 要求使用它的应用程序也开放源代码。不过有些公司会禁止使用受 LGPL 许可证保护的软件。在这种情况下，我们可以考虑使用 SQLAlchemy，它是 TG 社区大力支持的另外一个 ORM 工具。

• 实际例子：

请参见 参考资料 部分给出的已知的 Django 和 TurboGears 驱动的站点的列表。这些实际的应用程序展示了我们可以使用每个工具实现什么功能。

资源三：