|
Size: 3437
Comment:
|
Size: 3559
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 11: | Line 11: |
| ===== gasolin曰 ===== | |
| Line 16: | Line 17: |
| }}} 这几天从limodou兄的blog中看到 TurboGears 这个框架, 看完演示教程后相当为之惊艳. |
}}}这几天从limodou兄的blog中看到 TurboGears 这个框架,看完演示教程后相当为之惊艳. |
| Line 20: | Line 19: |
| Django 跟 TurboGears 的出现提供了一个相当 pythonic 的解决方案 (python + HTML :D). |
Django 跟 TurboGears 的出现提供了一个相当 pythonic 的解决方案 (python + HTML :D). |
| Line 23: | Line 21: |
不需要使用资料库查询语言或额外的资料库设计修改工具是一大特色. |
不需要使用资料库查询语言(SQL)或额外的资料库设计修改工具是一大特色. |
| Line 29: | Line 25: |
| '''其计划的核心概念是不重复发明轮子, 而是把 python中的各轮子组成有用的框架.计划主要的工作是提供简化的安装, 设定, 操作,与文件.''' * 我们的 WuKooPy 也是这意思，不过关注的深度比较浅 -- ZoomQuiet |
|
| Line 30: | Line 28: |
| 其计划的核心概念是不重复发明轮子, 而是把 python 中的各轮子组成有用的框架. 计划主要的工作是提供简化的安装, 设定, 操作,与文件. 之前 Ruby on rails 超热的时候似乎 python 社群有个 SUBWAY计划想达成类似的事情, 但一听就知道是想复制 ROR 的计划,并未提出相当的成果. |
之前 Ruby on rails 超热的时候似乎 python 社群有个 SUBWAY计划想达成类似的事情,但一听就知道是想复制 ROR 的计划,并未提出相当的成果. |
| Line 42: | Line 34: |
| Django 跟 TurboGears 相比无论安装, 使用上都复杂许多, 而 Django 从头开发也意味着目前 python web开发社群要使用这框架也得多花费心力去学习. |
'''Django 跟 TurboGears 相比无论安装, 使用上都复杂许多''',而 Django 从头开发也意味着目前 python web开发社群要使用这框架也得多花费心力去学习. |
| Line 45: | Line 36: |
| TGP 是由 python script 组成的 controller 呼叫 SQLObject 来读出资料库中的资料, 再以字典形式传值到样板中当作动态语言的变数. |
TGP 是由 python script 组成的 controller 呼叫 SQLObject来读出资料库中的资料,再以字典形式传值到样板中当作动态语言的变数. |
| Line 49: | Line 38: |
| 达成资料库(model)--controller--template (View) 的 MVC 架构 | 达成'''资料库(model)--controller--template (View)''' 的 MVC 架构 |
| Line 51: | Line 40: |
| 传出的格式如 {data=content, pagename=page.pagename} 这样一次收集所有用到的参数, 接收用[div] py:replace="data"/ Page text goes here.[/div] 这样在标签中加"py:replace"的格式插入参数, |
传出的格式如 {{{ {data=content, pagename=page.pagename} }}} 这样一次收集所有用到的参数,接收用 {{{[div] py:replace="data"/ Page text goes here.[/div] }}} 这样在标签中加`"py:replace"`的格式插入参数, |
| Line 56: | Line 48: |
| Ruby on rails 或 Django 每加一页新的资料, 要处理的 MVC 关连似乎不及TurboGears 承袭 cherrypy 架构(不知有无说错?)的简单明了 |
Ruby on rails 或 Django 每加一页新的资料, 要处理的 MVC关连似乎不及TurboGears 承袭 cherrypy架构(不知有无说错?)的简单明了 |
Pythonic Web 应用平台对比集
1. TurboGears vs Django
1.1. gasolin曰
{{{发件人: [email protected] <[email protected]> 回复: [email protected] 收件人: "python.cn" <[email protected]> 日期: 2005-9-19 下午9:32 主题: TurboGears vs Django }}}这几天从limodou兄的blog中看到 TurboGears 这个框架,看完演示教程后相当为之惊艳.
Django 跟 TurboGears 的出现提供了一个相当 pythonic 的解决方案 (python + HTML :D).
不需要使用资料库查询语言(SQL)或额外的资料库设计修改工具是一大特色.
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 成功的机率更大些.