Size: 3437
Comment:
|
Size: 4054
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 4: | Line 4: |
''' Pythonic Web 应用平台对比集 ''' |
'''Pythonic Web 应用平台对比''' |
Line 10: | Line 9: |
==== TurboGears vs Django ==== {{{发件人: [email protected] <[email protected]> 回复: [email protected] 收件人: "python.cn" <[email protected]> 日期: 2005-9-19 下午9:32 主题: TurboGears vs Django |
== 综合对比 == '''[wiki:PyCNmail/2006-June/025580.html Re: 关于 Python 的 web 开发框架,应该选择哪个?]''' * limodou {{{ web framework大多数从功能上都大同小异。从功能上分:zope/plone算大型的,而django, turbogears算是轻量级的。从学习曲线上分,zope/plone要长一些,而django, turbogears相对要短一些。对于django, turbogears来说,开发的理念有所不同,但功能是类似的。django所有东西都是自已开发的,象模板系统,url映射机制,ORM等。而turbogears则是许多相对成熟项目的集合,这一点与pylons也很象,如模板系统主要是kid,通过模板适配可以使用其它的模板(强调一下,django是松耦合的,许多组件也可以替换),web server组件使用cherrypy,ORM使用SQLObject(还可以使用SQLAlchemy)等等。关于这两种集成的方式,不同的人有不同的看法。有人认为turbogears是好的,因为没有重新造轮子。但有些人象我认为集中式更易管理和控制。所以关键看你认同哪一种设计理念。 对于ajax也有许多不同的声音。ajax本身可以与后台无关,它主要是在前端通过javascript, DOM来操纵前端数据,与后台交互。从这一点上,任何web framework都可以算是支持ajax。如果说不支持,那是从后台能否自动生成相应的html, javascript代码这一层来说的。turbogears嵌入了mochekit的js库的支持,可以通过python程序生成相应的js代码。django则是有人做过这样的工作,但要么不是成熟的东西,要么还没有成型。为什么会这样也与django的设计理念有关系。象turbogears,它的支持是针对不同的js库生成不同的包装,这样如果js库非常多,自然会有许多的包装,目前已经是这样的。而django在讨论是则不希望是这样,希望有一个中间层或无关层,但的确这一点很难。因此后来可能限定在了dojo,不过还没有相关的代码可以看到。只不过admin功能使用了dojo的一些东西。 还有pylons也很有特色。但对于我上人来说,我认为它太复杂了,不容易理解,所以也没有人研究过。目前国内对于django, turbogears, pylons都有人研究,从人数上看是比例依次递减。对于zope/plone则有专门的czug.org,有许多人在学习和研究。 总之,不同的框架从基本功能上是大同小异,在功能是各有特色的,设计理念上也是各有差异。选择一个框架不仅看它的功能是否满足,可能还有许多的因素,如人气,成熟度,是否有现实的应用,性能,设计理念等等。应用从方面进行考查,而且用着顺心可能更重要。象karrigell作为初学入门,或更轻量级的选择也是不错。 -- I like python! |
Line 17: | Line 31: |
这几天从limodou兄的blog中看到 TurboGears 这个框架, 看完演示教程后相当为之惊艳. |
* [wiki:PyCNmail/2006-June/025610.html ZoomQuiet]{{{ 从学习成本来看就三种层次: 1:Zope 系列的高成本复杂性平台,维护需要深入学习成本,带来整体的稳定; 2:Django 等的中等复杂度平台,通过各种组合,使用一定的框架概念,中度学习后,可以获得丰富的功能,和一定数量级别上的稳定; 3:web.py 类的极低学习成本,可以直接进入开发和同步运营,一切功能都可以自行快速开发出来,但是系统整体稳定性依赖开发人员的成熟度 |
Line 20: | Line 37: |
Django 跟 TurboGears 的出现提供了一个相当 pythonic 的解决方案 (python + HTML :D). |
平台的选择主要看你的应用原则,和运维手段,是想依赖平台的设计,还是开发人员的人品? |
Line 23: | Line 39: |
总之学习成本和对系统整体细节的掌控程度是呈反比的。 }}} === TurboGears vs Django === 对比集中在'''高压力环境稳定性'''和'''sqlobject的发展结合'''上 |
|
Line 24: | Line 44: |
不需要使用资料库查询语言或额外的资料库设计修改工具是一大特色. | ==== gasolin 曰 ==== [[Include(TGvsDjGasolin)]] |
Line 26: | Line 47: |
==== limodou 曰 ==== [[Include(TGvsDjLimodou)]] |
|
Line 27: | Line 50: |
TurboGears (Python) 是在 cherrypy +SQLObject等的基础之上整合相当成功的框架. 其计划的核心概念是不重复发明轮子, 而是把 python 中的各轮子组成有用的框架. 计划主要的工作是提供简化的安装, 设定, 操作,与文件. 之前 Ruby on rails 超热的时候似乎 python 社群有个 SUBWAY计划想达成类似的事情, 但一听就知道是想复制 ROR 的计划,并未提出相当的成果. 两者较不同的是 Django提供预设的资料库增删修改介面, 而 TGP似乎还没发展这块. 比起 Django 来说, TurboGears 更吸引我的是整合 AJAX 支援, Django 跟 TurboGears 相比无论安装, 使用上都复杂许多, 而 Django 从头开发也意味着目前 python web开发社群要使用这框架也得多花费心力去学习. TGP 是由 python script 组成的 controller 呼叫 SQLObject 来读出资料库中的资料, 再以字典形式传值到样板中当作动态语言的变数. 达成资料库(model)--controller--template (View) 的 MVC 架构 传出的格式如 {data=content, pagename=page.pagename} 这样一次收集所有用到的参数, 接收用[div] py:replace="data"/ Page text goes here.[/div] 这样在标签中加"py:replace"的格式插入参数, Ruby on rails 或 Django 每加一页新的资料, 要处理的 MVC 关连似乎不及TurboGears 承袭 cherrypy 架构(不知有无说错?)的简单明了 TurboGears 教程中是由单一的 controller (标准的 python class) 呼叫 SQLObject来读出资料库中的资料, 再以字典形式传值到样板中当作动态语言的变数. ` 达成资料库(model)--controller--template (View) 的 MVC 架构`. 由 controller 传出的格式如 `{data=content,pagename=page.pagename}` 一次收集网页样板将用到的 data 跟pagename 参数. 网页样板 template 接收用`[div] py:replace="data"]` 内容显示在这里 `[/div]` 实际显示时会将"内容显示在这里"这段替换成资料集"data"中的内容. 要在网页样板中调用这几个参数有两个方式. 第一种是可以在标签中加`py:replace="data"`, 来插入 data字典参数; 或是使用类似一般动态语言给参数的方式 `${data}` 插入data 字典参数. 注意第二种的格式还是跟 python调用字典的感觉很像. 间中用到的 HTML, ini 都算是基本的内容, 用起来没什么要另外学东西的负担. Django (或 Ruby on rails)每加一页新的资料, 都要分别处理对应的 controller. 关连似乎不及 TurboGears 承袭 cherrypy 架构可使用单一 controller 的简单明了(不知有无说错?) 因此我认为相比之下 TurboGears 成功的机率更大些. |
[[Include(PyWebFrameDiscuss)]] |
Pythonic Web 应用平台对比
1. 综合对比
[wiki:PyCNmail/2006-June/025580.html Re: 关于 Python 的 web 开发框架,应该选择哪个?]
limodou
web framework大多数从功能上都大同小异。从功能上分:zope/plone算大型的,而django, turbogears算是轻量级的。从学习曲线上分,zope/plone要长一些,而django, turbogears相对要短一些。对于django, turbogears来说,开发的理念有所不同,但功能是类似的。django所有东西都是自已开发的,象模板系统,url映射机制,ORM等。而turbogears则是许多相对成熟项目的集合,这一点与pylons也很象,如模板系统主要是kid,通过模板适配可以使用其它的模板(强调一下,django是松耦合的,许多组件也可以替换),web server组件使用cherrypy,ORM使用SQLObject(还可以使用SQLAlchemy)等等。关于这两种集成的方式,不同的人有不同的看法。有人认为turbogears是好的,因为没有重新造轮子。但有些人象我认为集中式更易管理和控制。所以关键看你认同哪一种设计理念。 对于ajax也有许多不同的声音。ajax本身可以与后台无关,它主要是在前端通过javascript, DOM来操纵前端数据,与后台交互。从这一点上,任何web framework都可以算是支持ajax。如果说不支持,那是从后台能否自动生成相应的html, javascript代码这一层来说的。turbogears嵌入了mochekit的js库的支持,可以通过python程序生成相应的js代码。django则是有人做过这样的工作,但要么不是成熟的东西,要么还没有成型。为什么会这样也与django的设计理念有关系。象turbogears,它的支持是针对不同的js库生成不同的包装,这样如果js库非常多,自然会有许多的包装,目前已经是这样的。而django在讨论是则不希望是这样,希望有一个中间层或无关层,但的确这一点很难。因此后来可能限定在了dojo,不过还没有相关的代码可以看到。只不过admin功能使用了dojo的一些东西。 还有pylons也很有特色。但对于我上人来说,我认为它太复杂了,不容易理解,所以也没有人研究过。目前国内对于django, turbogears, pylons都有人研究,从人数上看是比例依次递减。对于zope/plone则有专门的czug.org,有许多人在学习和研究。 总之,不同的框架从基本功能上是大同小异,在功能是各有特色的,设计理念上也是各有差异。选择一个框架不仅看它的功能是否满足,可能还有许多的因素,如人气,成熟度,是否有现实的应用,性能,设计理念等等。应用从方面进行考查,而且用着顺心可能更重要。象karrigell作为初学入门,或更轻量级的选择也是不错。 -- I like python!
[wiki:PyCNmail/2006-June/025610.html ZoomQuiet]
从学习成本来看就三种层次: 1:Zope 系列的高成本复杂性平台,维护需要深入学习成本,带来整体的稳定; 2:Django 等的中等复杂度平台,通过各种组合,使用一定的框架概念,中度学习后,可以获得丰富的功能,和一定数量级别上的稳定; 3:web.py 类的极低学习成本,可以直接进入开发和同步运营,一切功能都可以自行快速开发出来,但是系统整体稳定性依赖开发人员的成熟度 平台的选择主要看你的应用原则,和运维手段,是想依赖平台的设计,还是开发人员的人品? 总之学习成本和对系统整体细节的掌控程度是呈反比的。
1.1. TurboGears vs Django
对比集中在高压力环境稳定性和sqlobject的发展结合上
1.1.1. gasolin 曰