在網路上，要看房子越來越方便了，但是，各家房仲公司的網頁介面不同，有些有地圖，有些沒有，不太方便，一個整合地圖網站，可以方便找房子的站，用 Debian, Django，Lighttpd，和一些 Google 提供的 API 就可以達到一致化的好處，還做了地址的正規化，提供看屋的平台，最重要的是，做了所有地區和路段的 RSS 訂閱，這應該是有使用 RSS 的一大福音，不過話說回來，大概在台灣還是只有學生族群，還有網路重度使用者會用 RSS，一般的上網人口可能只會用作業系統預裝的IE6，還不會下載 FireFox ，是我低估了台灣人嗎？ :-)

http://home.digez.com/

等很久的 Unicode branch 終於 merge 到 trunk 了，我可是流口水很久了，之前 Oracle branch 也 merge 了

HowTo

http://code.djangoproject.com/wiki/UnicodeBranch

在有 Database 的應用裡，寫多了 SQL（Structure Query Language） 會覺得他是一種累贅，讓你的邏輯不斷的，在程式語言，及 SQL 之間轉換，所以後來，就有了，很流行的 Database ORM (Object Relational Mapper) 來幫助我們開發，一來，可以用相同的邏輯思考方式，用物件的方式，去對應資料庫的元件，一來，可以有資料庫的抽象層，對一個系統的開發有很大的助益，但是，如果，要寫的 code ，比一般的 SQL 還要複雜，還要隴長，你該怎麼作呢？

寫回去 SQL 嗎？還是就去適應這樣的物件對應方式？

這也許沒有一定的答案，不過，我來分享一下，我用 Django ORM 到目前所遇到的問題，和解決的方法，所以，裡面有一些是個人好惡的選擇

* 現在Unicode 的branch 還沒有 merge 到 truck 裡，如果用 wxPython unicode 的版本，自己要處理，string to unicode 及 unicode to string 的問題

* ManytoManyField 的欄位，Q object OR 沒有辦法套用，在 djangosnippets 有解決辦法，連結是 http://www.djangosnippets.org/tags/m2m/ 不過還是希望有官方的

* 目前如果是用 truk 的 Django， 用 groupu_by() 只能在對應該物件的 database table 裡分 group，無法使用別的欄位作 group_by 的條件，在別的 branch 有解決了，可是基於，愛乾淨不要混用，太多 branch 的原則，我是用 extra 的解法，算是走 SQL 的回頭路，不過， “GROUP BY” 在 SQL 也是標準的語法，不至於破壞了資料庫的抽象層，不過，如果有用 GROUP BY 的話，不可以混用 filter 的功能，不然，產生的 SQL 語法不對，我們要決定所有的 where 條件，第一個例子，是有 where 的 group by，第二個，是沒有 whehe 可是要強加 grouop by 在不同欄位，這樣就還可以在 DB 上只用一個 query，在 Django 上還是傳回 QuerySet 的作法，不過，這一個 QuerySet 不可以再用 filter 的方式，因為這樣會讓 group by 及 where 的位置錯了

範例1::

qset = Stock.objects.extra(select={’totalsum’:‘sum(volume)’},where=[“customer_id=’%s’ group by product_id” %(customerid)])


範例2::

qset = Stock.objects.extra(select={’totalsum’:‘sum(volume)’},where=[“1 group by product_id”])

以上，是目前，我遇到的一些限制，及解決辦法，也許對您有參考的價值，在 Desktop 的應用程式上， 如果，還有更複雜的的需求， SQLAlchemy 應該是不錯的選擇

.. -- mode: rst --

每個人做出選擇都有許多的原因，我來說說我的。

話說去年秋末的時候，手上用 TurboGears 寫的東西，就快完成了，在一個天氣不錯的週末，趕著回家，notebook 掉了，泣，裡面，裝著我三四個月的努力，最後，當然是沒有像電視報導那樣，被善心人士撿到送到警察局，所以證件重辦，電腦重買，系統重寫，要重寫的時候，TurboGears 轉變的非常快，SQLObject 到 SQLAlchemy，範本系統則是 Kid 到 Genshi，而且開發進行的飛快，API 也不確定，所以那時候就選了 Django 來重寫，沒錯，我選的原因是，notebook 掉了，當時沒有時間等 API 穩定了

這一個真實的例子，告訴我們 Version Control 的重要，就算是只有一個人在寫也不例外

最令人高興的事，這兩個專案，都一直有進步

參考資料

http://www.turbogears.org/ TurboGears

http://www.djangoproject.com/ Django

.. -- mode: rst --

最近作一個公司內部簡單的應用，希望不要讓使用者再去記憶更多密碼，所以 POP3Backend 於是誕生，可以直接用公司的 POP3 Server 來作認證，會先試試 POP SSL 來連，不行才用一般的 POP 連結，真的是很短啦，有一點陽春，用了一個需外裝的 python dns 模組，來查網域的 MX 資料，還有很大的改善空間，不過還是可用啦，一樣，版權沒有，自己取用，責任自負

雖然也很想用 LDAP，不過，內部系統雜亂的歷史包袱，還一時改變不了，還是先撐一下吧，說到認證，不免要抱怨一下，什麼時候，台灣才有正式的非商業，OpenID service provider 壓

連結在這 http://www.djangosnippets.org/snippets/203/

參考資料

http://www.carthage.edu/webdev/?p=12 ，LDAP Authentication in Django with Backends
http://www.djangoproject.com/documentation/authentication/ ，User authentication in Django

.. -- mode: rst --

果然，自己又當了一次小白，我錯怪了 Django

原來是自己修改了 mysql backend 的 base.py 才會造成怪怪的編碼問題，精神不好的時候，還是，看看資料，想想計畫，不要寫太多東西

.. -- mode: rst --

最近在做的東西，是用 MySQL （懶，已經有 MySQL了，不想再裝 PostgreSQL 了），在資料庫上預設用 UTF8 編碼，在 Django 上，如果 DATABASE_ENGINE = ‘mysql’，第一個 connection 都會下， SET NAMES utf8; 然後，之後的 Query 都會自己加 SET NAMES latin1; 大多時候，是正常，不過，有時是亂碼，奇怪就在，我把這一個有問題的結果，print 出來除錯時，螢幕是亂碼，可是在網頁上又可以變正常，真想掉眼淚

這種情形，一開始用 Sqlite 開發的時候，也沒有，所以開發環境，還是跟實際一模一樣比較好

真是很怪的情形，令我頭痛好幾個晚上，有點像是靈異現象了

不過還好試一下舊的mysql engine ，還可以用，而且不會有這種怪情形，他只有會在connection 時下， SET NAMES utf8; 之後的 Query 不會加 SET NAMES latin1

暫時用這一個好了，設定 settings.py 裡改成 DATABASE_ENGINE = ‘mysql_old’

作業環境，Debian_etch，python2.4.4，python-mysqldb-1.2.1-p2-4，mysql-server-5.0.32，Django svn 4866

.. -- mode: rst --

Guido 說，Django 是Web framework 的選擇，但是因為開發模式不同，並不會納入，標準的函式庫之中，會像是 PIL 或 NumPy 一樣的方式，同時也希望，Django 和 TurboGear 可以和在一起

聽到大老這樣說，打擊最大的應該是 TurbeGear 的起始開發者，Kevin Dangoor，不過，相信開發還是會繼續，不過，令人擔心的是，這樣也許，會引響使用者的成長，現在也只能看看以後的發展摟

順便，技一下目前的近況好了

Django

目前可以多個資料庫的版本快要 commit 了，然後有 json 的 serializer, 要加入，AJAX 的應用可以方便一點了

TurboGear

慢慢要換成是 SQLAlchemy 的 ORM，不過，FastData 還有 CatWalk 一時沒辦法追上

Django 的 admin 真的很方便，Cache 很好用，效能沒有話說，不過，目前自己整合 Javascript 的函式庫,還是比較麻煩一點點，TurboGear 則是 Widget 的部分好用，input，output 有加了一成資料格式的處理，方便直接與 Javascript 呼用，不過，目前 ORM 正在過度期，也連帶影響了其他的套件，不過還真希望，好用的東西互用，開發可以同心協力，不過，一直以來,現實與理想總是有些許的差距，不過，直得開心的是,都會向前走

連結

http://www.blueskyonmars.com/2006/08/19/there-cant-be-only-one/

http://pyre.third-bit.com/blog/archives/613.html

說真的要比較這兩個 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，也可以用 Buffet 支援的 template，現在有 CherryTemplate，Kid，Myghty，Python 2.4 String Templates，XSLT 等

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 會互相學習彼此的優點，所以都不錯啦。

聽再多，都比不上，你自己實做一下，自己感受一下吧 :-)

Ruby on Rail

紅很久了，以 Ruby 快速開發的架構

DjanGo

蠻新的，以 Python 開發

TurboGears

非常新，以 Python 開發

以上的架構，多是有自己的 Application Server，結合範本，也可以做到 MVC 的開發，也容易快速的結合 Ajax， 彈性都非常大，都可以快速開發 Web 應用，功力好，喜歡自己堆積木的同好，不要放過，對 Java 來說，真是很好的對應，Vgod ，有一則 blog，Rail v.s. J2EE 的圖，真的非常好笑，當然，Perl 的架構也是很多，看到 CPAN 就夠嚇人了，不過我自己對整合駱駝文並不太行，常常會頭暈，所以那一部分留給長輩說吧。

我自己則是比較喜歡 TurboGears，原因，大概就是，喜歡，CherryPy （櫻桃派），還有 SQLObject ，這兩個可是很有名的，也不是說 DjanGo 的方式不好，雖然他的成熟度稍高，也已有大型的實作，對岸，也有熱心的朋友 woodpecker.org.cn，不過，TurboGears 的開發腳步非常快，相信，很快 0.9 和 1.0 stable 的發佈應該也不會太遠。

Django, Or why I chose it over turbogears and ruby on rails

TurboGears, or why I chose it over Django and Ruby on Rails