这两个项目之间背景的差异导致了不同的项目优先级。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 驱动的站点的列表。这些实际的应用程序展示了我们可以使用每个工具实现什么功能。
关于作者
Ian Maurer 是 Brulant, Inc. 的一名资深顾问，他擅长使用开源软件和 IBM WebSphere 技术为各个行业开发集成的电子商务解决方案，其中包括消费品和零售行业。Ian 居住在东北部的俄亥俄州，他是 Cleveland Area Python Interest Group 的成员。
复制本页网址和标题，发送给你QQ/Msn的好友一起分享 给程序加个图标 多继承详解
精品推荐
