用來在 subversion tree 裡滾來滾去，真是舒服。
紀錄一下今天評估 django 和 turbogears 的結果。
django 發展得比較早 (根據 Django FAQ 的說法，已經開發兩年了；turbogears 則是從 2004 年底開始構思的)，repository 也比較深：
- svn repo: http://code.djangoproject.com/svn/
- trac: http://code.djangoproject.com/
turbogears svn 版號少得多：
- svn repo: http://www.turbogears.org/svn/turbogears/
- trac: http://trac.turbogears.org/
django 是設計給新聞網站用的：
We've been using Django for almost two years. Sites built on Django have weathered traffic spikes of over one million hits an hour, and at least one Slashdotting. Yes, it's quite stable.
turbogears 則是作為 zestynews 的基底，這是一個裝在個人電腦上的 web-based RSS reader。
兩者的設計概念截然不同。誰會比較好用還很難說，不過 turbogears 0.8a5 還要求 Python 2.4，這有點惱人。
Add a trackback
Please send trackback to: http://blog.seety.org/everydaywork/2005/12/26/458/trackback/.
Comments
Re: trac 真是太棒了
有寫過 tg 程式了嗎? 不知道感覺如何。
目前正在學 django，剛把所有文件看完一遍；它把 SQL table model 成 python 物件的作法不難懂 (我以前只會 raw SQL query)，不過在使用物件時利用了間接的 import，比較不直覺，需要多想一想才會了解。
django 也用了 MVC 設計，但其中的 MVC 被改稱作 Model-Template-View (MTV)。
目前正在學 django，剛把所有文件看完一遍；它把 SQL table model 成 python 物件的作法不難懂 (我以前只會 raw SQL query)，不過在使用物件時利用了間接的 import，比較不直覺，需要多想一想才會了解。
django 也用了 MVC 設計，但其中的 MVC 被改稱作 Model-Template-View (MTV)。
yungyuc
at 2005-12-28 17:32.
Re: trac 真是太棒了
DjanGo and TurboGears
說真的要比較這兩個 Web FrameWork 的話，真是說來話長，不過基本上，都是是不錯的選擇，這兩個專案，都是由很強的開發者，所主導的，所以都很好啦，不需要爭那一個比較好啦，就像是世界上的 Web Framework， 不會永遠只有 Java， dot NET，PHP， Ruby， Zope 或是 Perl， 每一個工具都有適合的地方啦，重點是我們能掌握多少，活用多少
基本上對於這兩個的比較，真的是很難有誰勝誰優的
這可以分成好幾個部份
URL mapping
DjanGo 是用像 Regular Expression 的方式作 mapping，速度很快，也有很大的彈性， 熟 Regular Expression 的人，該知道他的彈性，喜歡 Regular Expression 的人，就可以選它。
TurboGears 是用 CherryPy 的關係，他的 mapping 像是 python 物件一樣，把 class 或是 參數 mapping 到 url上
Database Mapping
DjanGo 自己有一套資料庫對應的 API，用起來已經夠用的，提供的不管是欄位對應，或是資料表的關係對應，都足敷一般的使用。
TurboGears 他則是採用 SQLObject 這一個模組，已經是相當成熟的模組，對應的方式，更像是真實 Python 物件。
Template System
DjanGo 有自己的一套 template 系統，也可以選用 ZPT 的方式
TurboGears 則是選用 Kid，不過已經有 Cheetah 的 plugin 了，以後應該還有更多
Cache System
在 Cache 上，是 DjanGo 的方式比較成熟，功能比較強，TurboGears 則是仰賴， CherryPy 及 SQLObject 的 Cache 機制。
Scalability
兩者的可延伸性，都很好，在 Apache 下可以用 mod_python，也都不用 Apache 改用 LightTPD ，來提昇效能。
其實很多的部份都是個人的選擇，和喜好，所以很難說那一個比較好，當然 DjanGo 比較成熟，對於初學者或是有經驗的人都是比較好的選擇，也提供一個很穩定的架構，API 也不會有很大的變動，文件比較齊全，非常有系統的架構，我想應該是很好的選擇，不用擔心以後要不要改的問題。
所以真的是看個性，我自己，因為都不排斥新的架構，也不太擔心那一個會是終極的解決方案，更不相信廠商說得，永遠只有一個架構的願景，純粹，以個人的喜好，我比較喜歡，TurboGears，因為 CherryPy 物件方式的 Controller 我比較不會出錯，比較有系統，SQLObject 非常直覺，已經非常像真實的物件了，CherryPy 支援的 template 系統很多，以後要加，應該更有彈性，也有我喜歡的，ClearSilver，可以有 C 的終極效能，還有已經要和 Subway 合併了，在 SVN 中的進步更是飛快，不過多是整合好的模組，或是，加強，TurboGears 自身的工具，在他的 tg-admin shell 裡，也是直接用 ipython，都是原本就很方便的工具，很快的也有權限及群組的功能，在 toolbox 裡，已經可以自動有管理的介面， Model Viewer，i18n tool set (在 DjanGo 中 i18n 也有好的解決方法)，還有還在討論的元件，這些都是很令人感興趣的。
開發的方法方面，每個人的想法會不同，有時候，都整合好的套件好用，我自身則是喜歡 TurboGears 的哲學，把一些已經很成熟功能強大的套件整合，這樣的好處，可以將不同的模組運用在不同的地方，不一定是 Web 的 AP，像是 SQLObject 就可以不管是 web base 或 form base 的應用裡，一旦 API 運用自如，很快就可以上手，如果以後對，TurboGears 不爽，可以直接由 CherryPy 這一層開始，如果，不喜歡SQLObjetc，想要跳槽，也可以，因為他們原本就是分開的，再來就是 OpenSource 的哲學之一，就是 Reuse，我們顧好自己的應用，如果發現採用的套件有 Bug， 將 Bug回報，讓別人幫我們維護我們也需要的部份，所以我覺得 TurboGears 的開發者在方法上，和我比較接近，說起來真賊，不過確是對大家都有易的，雖然，整個完整的方案像是 DjanGo，可以有集中的管理，和發展，但是對我來說，我用 TurboGears 只是再用原本就有在用的工具而已 (SQLObject，iPython...)。其實我相信，以後這兩個 Framework 會互相學習彼此的優點，所以都不錯啦。
說真的要比較這兩個 Web FrameWork 的話，真是說來話長，不過基本上，都是是不錯的選擇，這兩個專案，都是由很強的開發者，所主導的，所以都很好啦，不需要爭那一個比較好啦，就像是世界上的 Web Framework， 不會永遠只有 Java， dot NET，PHP， Ruby， Zope 或是 Perl， 每一個工具都有適合的地方啦，重點是我們能掌握多少，活用多少
基本上對於這兩個的比較，真的是很難有誰勝誰優的
這可以分成好幾個部份
URL mapping
DjanGo 是用像 Regular Expression 的方式作 mapping，速度很快，也有很大的彈性， 熟 Regular Expression 的人，該知道他的彈性，喜歡 Regular Expression 的人，就可以選它。
TurboGears 是用 CherryPy 的關係，他的 mapping 像是 python 物件一樣，把 class 或是 參數 mapping 到 url上
Database Mapping
DjanGo 自己有一套資料庫對應的 API，用起來已經夠用的，提供的不管是欄位對應，或是資料表的關係對應，都足敷一般的使用。
TurboGears 他則是採用 SQLObject 這一個模組，已經是相當成熟的模組，對應的方式，更像是真實 Python 物件。
Template System
DjanGo 有自己的一套 template 系統，也可以選用 ZPT 的方式
TurboGears 則是選用 Kid，不過已經有 Cheetah 的 plugin 了，以後應該還有更多
Cache System
在 Cache 上，是 DjanGo 的方式比較成熟，功能比較強，TurboGears 則是仰賴， CherryPy 及 SQLObject 的 Cache 機制。
Scalability
兩者的可延伸性，都很好，在 Apache 下可以用 mod_python，也都不用 Apache 改用 LightTPD ，來提昇效能。
其實很多的部份都是個人的選擇，和喜好，所以很難說那一個比較好，當然 DjanGo 比較成熟，對於初學者或是有經驗的人都是比較好的選擇，也提供一個很穩定的架構，API 也不會有很大的變動，文件比較齊全，非常有系統的架構，我想應該是很好的選擇，不用擔心以後要不要改的問題。
所以真的是看個性，我自己，因為都不排斥新的架構，也不太擔心那一個會是終極的解決方案，更不相信廠商說得，永遠只有一個架構的願景，純粹，以個人的喜好，我比較喜歡，TurboGears，因為 CherryPy 物件方式的 Controller 我比較不會出錯，比較有系統，SQLObject 非常直覺，已經非常像真實的物件了，CherryPy 支援的 template 系統很多，以後要加，應該更有彈性，也有我喜歡的，ClearSilver，可以有 C 的終極效能，還有已經要和 Subway 合併了，在 SVN 中的進步更是飛快，不過多是整合好的模組，或是，加強，TurboGears 自身的工具，在他的 tg-admin shell 裡，也是直接用 ipython，都是原本就很方便的工具，很快的也有權限及群組的功能，在 toolbox 裡，已經可以自動有管理的介面， Model Viewer，i18n tool set (在 DjanGo 中 i18n 也有好的解決方法)，還有還在討論的元件，這些都是很令人感興趣的。
開發的方法方面，每個人的想法會不同，有時候，都整合好的套件好用，我自身則是喜歡 TurboGears 的哲學，把一些已經很成熟功能強大的套件整合，這樣的好處，可以將不同的模組運用在不同的地方，不一定是 Web 的 AP，像是 SQLObject 就可以不管是 web base 或 form base 的應用裡，一旦 API 運用自如，很快就可以上手，如果以後對，TurboGears 不爽，可以直接由 CherryPy 這一層開始，如果，不喜歡SQLObjetc，想要跳槽，也可以，因為他們原本就是分開的，再來就是 OpenSource 的哲學之一，就是 Reuse，我們顧好自己的應用，如果發現採用的套件有 Bug， 將 Bug回報，讓別人幫我們維護我們也需要的部份，所以我覺得 TurboGears 的開發者在方法上，和我比較接近，說起來真賊，不過確是對大家都有易的，雖然，整個完整的方案像是 DjanGo，可以有集中的管理，和發展，但是對我來說，我用 TurboGears 只是再用原本就有在用的工具而已 (SQLObject，iPython...)。其實我相信，以後這兩個 Framework 會互相學習彼此的優點，所以都不錯啦。
TerryH
at 2005-12-29 12:22.
Re: trac 真是太棒了
令人尊敬的 TerryH 呀，您要不要把這一篇文章轉發到哪個更穩一點的地方 (ex: pythontw@groups.google.com)，這個比較真是夠深入，夠清楚啊。我的小爛站要是出了什麼萬一，以後再也看不到這文章怎麼辦！
我現在才要開始好好學 django；昨天順手把 po 檔翻了 submit 出去。許多人都說 SQLObject 好，不過我愈用 django data models 愈覺得好玩；像這種把關聯式資料庫對應到物件的作法對我來說真的好新奇有趣。
現在只有這樣... 等到有點心得了再提出來現醜一下 :p
-----
我現在才要開始好好學 django；昨天順手把 po 檔翻了 submit 出去。許多人都說 SQLObject 好，不過我愈用 django data models 愈覺得好玩；像這種把關聯式資料庫對應到物件的作法對我來說真的好新奇有趣。
現在只有這樣... 等到有點心得了再提出來現醜一下 :p
-----
yungyuc
at 2005-12-29 17:47.
Add a comment
http://www.turbogears.org/download/index.html#py23