Differences between revisions 1 and 19 (spanning 18 versions)
Revision 1 as of 2005-09-19 14:43:43
Size: 2813
Editor: ZoomQuiet
Comment:
Revision 19 as of 2007-04-13 08:33:41
Size: 7467
Editor: ZoomQuiet
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
'''
Pythonic Web 应用平台对比
'''
'''Pythonic Web 应用平台对比'''
Line 8: Line 6:
 * 更多的Py实现 CMS -- 内容管理平台见: http://wiki.python.org/moin/ContentManagementSystems
  * 各种CMS 的对比见 http://cmsmatrix.org/uploads/HA/cO/HAcOzvnZorPtv5wLpUxtDw/cms_matrix.gif http://cmsmatrix.org
Line 10: Line 10:
== 综合对比 ==
'''[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 类的极低学习成本,可以直接进入开发和同步运营,一切功能都可以自行快速开发出来,但是系统整体稳定性依赖开发人员的成熟度
平台的选择主要看你的应用原则,和运维手段,是想依赖平台的设计,还是开发人员的人品?
总之学习成本和对系统整体细节的掌控程度是呈反比的。
}}}
  * {{{
没有人否认 Zope-Plone 是最好的 base Python Web app. 平台,
但是, Zope2 也好 Zope 3 也好,都是有极高的学习曲线的,
就好象一个E国人,明知中文的唐诗是最优美的语言艺术,
但是他想恰当的引用诗句和真正可以自如的创造出古体诗的学习成本,
就好比我们要合理合法的深入使用Zope 平台和基于Zope进行二次开发的学习成本!
所以,就个人想立即享受,体验Python 的web app.应用开发,使用 Karrigell/web.py 吧!
想快速将Python 引入商业站点的快速开发,使用 Django/TurobGears 等等框架吧!
如果想真正服务永继的进行 web 服务的话,还是 Zope 3 吧!
}}}
   -- ZoomQuiet
=== 关注Ajax 时 ===
{{{
From: [email protected] <[email protected]> Mailed-By: googlegroups.com
Reply-To: [email protected]
To: "python.cn" <[email protected]>
Date: Jun 9, 2006 2:15 PM
Subject: [python-cn:10720] Re: 关于 Python 的 web 开发框架,应该选择哪个?
}}}
{{{
补充一点心得:
如果你的网页应用服务主要关注在 AJAX 应用,
大部分动作都用 javascript 在客户端完成,
只有 data 部分需要后端提供. 那么 TurboGears
是非常适用的选择.
1. 可以先用一般 serverside
开发方式写函式和建立网页应用服务原型 (prototype),
来测试你的网页应用服务该有的功能.
   @expose(format = ".template.pages") #资料以样版格式显示
   def method(self):
   ....
   return dict{data=data}
因为 TurboGears 中从传入 serverside 的表单资料处理一致,
所以在 serverside 写的 code 完全可以继续使用,
不必为了支持 AJAX 重写,
很好的达到不重复自己(DRY)的效果.
2.import javascript library , 将资料改以 JSON 格式传到网页
from turbogears import mochikit
...
@expose(format = ".template.pages") #资料以样版格式显示
@expose(format = "JSON") #资料以JSON格式显示
def method(self):
....
return dict{data=data, scripty = mochikit} #在网页上
TurboGears 预先包好 mochikit, scriptaculous, plotkit 等 javascript
库,
使用时可以用程式呼叫, 预设可用 JSON 格式传输,
预设 mochikit 库提供相应资料处理支援.
3. 在 client 端用 javascript 处理 DOM 物件.
因为在开发的第一步时已经能将所需的资料,
传输内容等都处理好了,
能确信资料传输的正确性. 所以开发 javascript 时,
可以专注在网页内资料处理的部分.
在这时遇到 bug
的话也可以很放心地将可能的问题点缩小到单纯网页内资料处理的范围,
因而 AJAX 开发时最麻烦的交叉 debug 也变得更容易.
因此如果你的网页应用服务主要关注在 AJAX 应用, 那么
TurboGears 是非常适合的选择.
}}}
Line 11: Line 99:
{{{发件人: [email protected] <[email protected]>
回复: [email protected]
收件人: "python.cn" <[email protected]>
日期: 2005-9-19 下午9:32
主题: TurboGears vs Django
对比集中在'''高压力环境稳定性'''和'''sqlobject的发展结合'''上

==== gasolin 曰 ====
[[Include(TGvsDjGasolin)]]

==== limodou 曰 ====
[[Include(TGvsDjLimodou)]]

[[Include(PyWebFrameDiscuss)]]

==== InterMa 补充 ====
 * 一篇好文:[http://jesusphreak.infogami.com/blog/vrp1 Python web development and frameworks in 2007]
{{{节译:
Line 17: Line 114:
这几天从limodu兄的blog中看到 TurboGears 这个框架,
看完演示教程后相当为之惊艳.
  * 大概意思是褒Dj贬Tg,不过个人还是比较喜欢Tg,希望她能度过难关。
 * 是也乎,俺也是看好TG ,奈何未成气候 -- ZoomQuiet
Line 20: Line 117:
Django 跟 TurboGears 的出现提供了一个相当 pythonic
的解决方案 (python + HTML :D).


不需要使用资料库查询语言或额外的资料库设计修改工具是一大特色.


TurboGears (Python) 是在 cherrypy +SQLObject等的基础之上整合相当成功的框架.


其计划的核心概念是不重复发明轮子, 而是把 python
中的各轮子组成有用的框架.
计划主要的工作是提供简化的安装, 设定, 操作,与文件.


之前 Ruby on rails 超热的时候似乎 python 社群有个 SUBWAY计划想达成类似的事情,
但一听就知道是想复制 ROR 的计划,并未提出相当的成果.

两者较不同的是 Django提供预设的资料库增删修改介面, 而 TGP似乎还没发展这块.

比起 Django 来说, TurboGears 更吸引我的是整合 AJAX 支援,

Django 跟 TurboGears 相比无论安装, 使用上都复杂许多,
而 Django 从头开发也意味着目前 python web开发社群要使用这框架也得多花费心力去学习.

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 成功的机率更大些.
= 自由评注 =
[[PageComment2]]

Pythonic Web 应用平台对比

TableOfContents

1. 综合对比

[wiki: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:2006-June/025610.html ZoomQuiet]

      从学习成本来看就三种层次:
      1:Zope 系列的高成本复杂性平台,维护需要深入学习成本,带来整体的稳定;
      2:Django 等的中等复杂度平台,通过各种组合,使用一定的框架概念,中度学习后,可以获得丰富的功能,和一定数量级别上的稳定;
      3:web.py 类的极低学习成本,可以直接进入开发和同步运营,一切功能都可以自行快速开发出来,但是系统整体稳定性依赖开发人员的成熟度
      平台的选择主要看你的应用原则,和运维手段,是想依赖平台的设计,还是开发人员的人品?
      总之学习成本和对系统整体细节的掌控程度是呈反比的。
    • 没有人否认 Zope-Plone 是最好的 base Python Web app. 平台,
      但是, Zope2 也好 Zope 3 也好,都是有极高的学习曲线的,
      就好象一个E国人,明知中文的唐诗是最优美的语言艺术,
      但是他想恰当的引用诗句和真正可以自如的创造出古体诗的学习成本,
      就好比我们要合理合法的深入使用Zope 平台和基于Zope进行二次开发的学习成本!
      所以,就个人想立即享受,体验Python 的web app.应用开发,使用 Karrigell/web.py 吧!
      想快速将Python 引入商业站点的快速开发,使用 Django/TurobGears 等等框架吧!
      如果想真正服务永继的进行 web 服务的话,还是 Zope 3 吧!

1.1. 关注Ajax 时

From: [email protected] <[email protected]>  Mailed-By: googlegroups.com
Reply-To: [email protected]
To: "python.cn" <[email protected]>
Date: Jun 9, 2006 2:15 PM
Subject: [python-cn:10720] Re: 关于 Python 的 web 开发框架,应该选择哪个?

补充一点心得:
如果你的网页应用服务主要关注在 AJAX 应用,
大部分动作都用 javascript 在客户端完成,
只有 data 部分需要后端提供. 那么 TurboGears
是非常适用的选择.
1. 可以先用一般 serverside
开发方式写函式和建立网页应用服务原型 (prototype),
来测试你的网页应用服务该有的功能.
   @expose(format = ".template.pages") #资料以样版格式显示
   def method(self):
   ....
   return dict{data=data}
因为 TurboGears 中从传入 serverside 的表单资料处理一致,
所以在 serverside 写的 code 完全可以继续使用,
不必为了支持 AJAX 重写,
很好的达到不重复自己(DRY)的效果.
2.import javascript library , 将资料改以 JSON 格式传到网页
from turbogears import mochikit
...
@expose(format = ".template.pages") #资料以样版格式显示
@expose(format = "JSON") #资料以JSON格式显示
def method(self):
....
return dict{data=data, scripty = mochikit} #在网页上
TurboGears 预先包好 mochikit, scriptaculous, plotkit 等 javascript
库,
使用时可以用程式呼叫, 预设可用 JSON 格式传输,
预设 mochikit 库提供相应资料处理支援.
3. 在 client 端用 javascript 处理 DOM 物件.
因为在开发的第一步时已经能将所需的资料,
传输内容等都处理好了,
能确信资料传输的正确性. 所以开发 javascript 时,
可以专注在网页内资料处理的部分.
在这时遇到 bug
的话也可以很放心地将可能的问题点缩小到单纯网页内资料处理的范围,
因而 AJAX 开发时最麻烦的交叉 debug 也变得更容易.
因此如果你的网页应用服务主要关注在 AJAX 应用, 那么
TurboGears 是非常适合的选择.

1.2. TurboGears vs Django

对比集中在高压力环境稳定性sqlobject的发展结合

1.2.1. gasolin 曰

Include(TGvsDjGasolin)

1.2.2. limodou 曰

Include(TGvsDjLimodou)

Include(PyWebFrameDiscuss)

1.2.3. InterMa 补充

{{{节译:

}}}

  • 大概意思是褒Dj贬Tg,不过个人还是比较喜欢Tg,希望她能度过难关。
  • 是也乎,俺也是看好TG ,奈何未成气候 -- ZoomQuiet

2. 自由评注

PageComment2

PyWebFrameVs (last edited 2009-12-25 07:10:11 by localhost)