TableOfContents

1. Pythonic Web 应用平台对比

更多的Py实现 [http://wiki.python.org/moin/ContentManagementSystems CMS--内容管理平台] BR各种CMS 的对比见 BR http://cmsmatrix.org/uploads/HA/cO/HAcOzvnZorPtv5wLpUxtDw/cms_matrix.gif [http://cmsmatrix.org cmsmatrix.org]

Include(/PyWebMatrix)

1.1. 再次综合对比

1.1.1. limodou 曰

limodou <[email protected]>              hide details    4:52 pm (8 hours ago) 
        reply-to                [email protected]   
        to              [email protected]   
        date            Jul 8, 2007 4:52 PM      
        subject         Re: [python-chinese] 现在python的web框架这么多，有没有人能分析分析各自的优点缺点？

从级别上来说：

server级的了,许多东西都没有,大量的要自已去做.从这三者中如果要选择,我会选择karrigell.karrigell更接近php,功能比较多,模板丰富.

van Rossum这位python的创始人在多个场个宣传他喜欢django,就是在最近的Google developer day上,在北京见到这位＂明星＂他还在说：＂I like django＂.因为我想他的一个观点就是：＂Simple is the best.＂. 当然象大朗所说学习成本高要看怎么说了.如果你的要求高,django有许多高要求的东西,学起来自然很高.如果你的要求低,功能自然差了许多,而且可以使用admin,所以学习成本不高.而且每种框架都有自身的难度,深入下去自然要求比较高.这种高要求也许不全是学习成本,比如有些功能可能框架就没有, 这种难度就不再是学习的难度而是需要由你设计或寻找一个可用实例的难度了.

1.1.2. 沈崴 曰

沈崴 <[email protected]>                  hide details    12:36 am (40 minutes ago) 
        reply-to                [email protected]       
        to      
        [email protected],
[email protected]       
        date            Jul 9, 2007 12:36 AM     
        subject         [CPyUG:28791] Re: [python-chinese] 现在python的web框架这么多，有没有人能分析分析各自的优点缺点？   
        mailed-by               googlegroups.com

赵老师, 您好! 我曾走马观花地尝试过上述某些框架, 略有些感想, 希望能对您有所帮助 :)

程序员而言, 除非 ROR 带来的商业利益超过成本上的支出, 否则很难适应 ROR 的效率。打个比方, 在 Plone 中尽管你可以使用 ArchGenXML 通过 UML 图来建立 Plone 应用, 但是真正开始使用后, 我们会发现手写 Archetypes 代码其实要比画 UML 图要来得方便和快捷。

你完全没必要自己作任何事情。Archetypes 拥有难以置信的建模能力, 搜索引擎和增删改页面全自动生成。Plone 自带的工作流引擎允许你靠鼠标完成工作流设计。使用得当, Plone 能带来几十倍的开发效率提升。Plone 也有非常严重的问题。首先,几乎所有人都认为 Plone 很慢, 事实上, Plone Skin 带来了太多 IO, 明白这一点, 我们能把 Plone 加速到和 CherryPy2 不相上下的程度。其次, 很多人对 Plone 定制苦不堪言, 但是如果不过于依赖 Plone Skin, 那么这也不是一个问题。最后, Plone 的栈很深, 不是所有人都会有足够耐心花几年时间来熟练地使用她, 这才是真正的问题 (在下认为这是完全值得的)。

过于完善的系统反而完全束缚了我们, 既然 Django 看上去是目前最好的框架, 这时候我选择 Django。这或许从一个侧面反映了一个在国内鲜为人知的情况, 那就是无论是国内还是国外, 使用 Plone 的应用要远超过 Django, 但是 Plone 程序员不会告诉你哪些站点是用 Plone 开发的, 因为这太偷懒了。常常, 这时任务会简单到直接使用 SimpleHTTPServer.py 就可以解决, 因此即使是一个临时方案, Django 还是很少被我用到。

因为黑客或许会选择像 TG 那样通过重用构建起来的东西, 但是他们更喜欢正则。作为 TurboGears 系的一员, 小弟斗胆猜测大家的潜台词可能都是: 我们爱 CherryPy 这样的好东西, 这带来了另一个意想不到的大问题: Apache Proxy 已经是一个 Tree Mount 和正则发布系统, 无论对 CherryPy 还是 Django 这都绝对不是一个好消息。接下来, CherryPy 也没有传说中那么快, CherryPy2 已经是有定论了, 而我测试的 CherryPy3 通常也没有能达到 500 个请求每秒的速度。至于 CherryPy3 的 TurboGears 是否能用, 在下也还没有尝试过。如果在同级应用中 TurboGears 系能和 Django 分庭抗礼, 我个人觉得只有一个可能, 那就是 TurboGears (或者直接说 CherryPy) 要更简单一些。我个人最先接触到 CherryPy, 这样 TurboGears 系在实际中就用得更多一些, 但是这并不说明我喜欢 TG 要超过 Django。

5. web.py 是对 Django、TurboGears 这些框架的反动, 既然不能像 Plone 这样大而全, 何苦搞得那么复杂? 在下认为, web.py 的作者同样对 SimpleHTTPServer.py 这类的标准库同样非常不满。不过有点尴尬, 我对各种层次的应用都已经有合适的方案了, 而目前所有流行框架不能完成的事情 web.py 同样也搞不定。在下意识到或许所有人对于 web.py 因为各种原因都会有些痒。但是这不妨碍 web.py 的优秀和学术价值。

1.2. 综合对比

[wiki:2006-June/025580.html Re: 关于 Python 的 web 开发框架，应该选择哪个？]

1.2.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.2. TurboGears vs Django

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

1.2.2.1. gasolin 曰

Include(TGvsDjGasolin)

1.2.2.2. limodou 曰

Include(TGvsDjLimodou)

Include(PyWebFrameDiscuss)

1.2.2.3. InterMa 补充

{{{节译: 主要比对方面:

}}}

2. 自由评注

频率受到Spamer 攻击!070528关闭自由注释功能