明天公司補放國父誕辰紀念日，所以有空到 Google 翻翻最近有沒什麼有趣的文章。我找到了一篇 TurboGears vs Rails. 文章名稱夠聳動，雖然這篇文章有點舊了 (用的是 0.9 的預覽版 TurboGears, 或稱為未進化型態版本 XD), 不過裡面對 TurboGears 和 Rails 的特性確實抓得頗準:

The Pythonic way is "explicit over implicit". Everything is out for show: you know what modules are imported, you know what methods are exposed, you know what columns are defined and so on. It may take more keystrokes but the extra code let's you know what is happening when things go wrong. python 語言的風格是 '直率的比含糊的好'. 所以所有的過程都可以被檢視：妳曉得如何導入使用的模組，函式怎麼對應到網址上，妳也曉得資料物件如何定義等等。妳可能需要多打一些字 (註：事實上不多), 但是這些額外的程式碼能讓妳在發生錯誤時更容易地知道自己的程式到底發生了什麼事.

The the Rails way is the opposite: take the burden off the developer, don't bother them with the petty details that get in the way and add to the line noise. Rails 的寫作方式則相反：把讓開發者困擾的因子都去除掉，不要在開發中用細節來干擾程式碼.

事實上去年 5 月底時，我在看過 OnLamp 網站上的 Ruby On Rails 教學後，相當驚訝現在網頁開發的進步 (之前有一年沒寫動態網頁了). 所以我也趁等待完成論文前的時間歔空寫了篇 Ruby On Rails 教學。不過在 7 , 8 月 Django, TurboGears 這些 Python 框架相繼出現後，我發現除了可以使用熟悉的 Python 語言風格來寫程式之外，以後也可以透過網頁介面來使用大量的 Python 模組實在非常吸引我。而當 TurboGears 框架出現 ToolBox 這神奇的工具箱後，我開始漸漸投入了 TurboGears 開發的行列.

能展現自我特點的是創意而不是程式碼 在我的觀念裡，能展現自我特點的是創意而不是程式碼 (也許因為我不是個天才程式設計師吧 XD). Rails 也是個相當吸引人的框架 (差不多靠一己之力拉拔 Ruby 語言 XD). 但是 python 的 "應該會有一個 -- 最適當的一個的方式來實現" 哲學比較接近我的想法。在閱讀其他人的 TurboGears 專案時只要不用到太進階的 Python 語言功能，基本上都非常易於閱讀與修改. (例如目前 TurboGears 最進階的教學文件: SQLalchemy 版的 SimpleBlog, 花一些時間就可以改寫成 TurboEntity 版 SimpleBlog 之一, 之二)

當開始使用 MVC (Model, View, Controller) 的方式設計網站程式後，組織網站架構的重任就從傳統的分頁換到程式控制部份 (Controller) 的網址 - 函式對映 (URL Mapper) 上.

舉 python 網頁框架的例子為例，python 的網頁框架很多，最常聽到的 Django, TurboGears, pylons 都各自有各自不同的網址 - 函式對映方式. 網址 - 函式對映能將程式控制部份對映到網站架構，也能依照一些規則將輸入的網址對應成函式的參數，方便程式使用.

Colubrid 這個 WSGI 工具的網站上清楚地列出了目前常見的 URL 對映分類:

• 使用 正則表達式 (Regular Expression, Regex) 對映 -Django
• 使用 物件 (Object) 對映 -TurboGears
• 使用 路徑 (Routes) 對映 -pylons

"-" 號後面的補註是我另加上去的，表示這幾個框架預設的 URL 對映方式. 當然有的框架也可以用另外的 URL 對映 (例如 TurboGears 也能使用路徑對應方式).

範例​

首先我們先給出一個基本的程式架構，再來討論如何將這個程式對應到網頁上。本文隱藏了各網頁框架特定的程式碼，因此在實際運行各種對應方式時需要再加上各自的程式碼.

Class Root(object):
   def index(self):
       return "Front Page"
   def profile(self):
       return "Profile Page"

app = Root()

這個類別 (Class) 包含兩個函式 (Method), 我們的目的是讓它顯示成如下的網站架構:

/
- index
- profile

例子很淺顯，我們就開始來嘗試吧

1. 使用 正則表達式 (Regular Expression) 對映

使用時在 Root 類別裡加上正則表達式來對映網頁

urls = [
         (r'^index,'index'),
         (r'^profile,'profile')
       ]

網頁架構是一串以 (r' 網頁名稱 ' ,' 函式名稱 ') 組成的列表來定義. 網頁名稱，函式名稱部份都可以使用正則表達式

2. 使用 物件對映

不必加入特別的對映方式. Root 類別在實例化後等同網站預設的根目錄， Root 類別下的兩個函式直接對映到相應名稱的網頁上.

/- Root
- index()
- profile()

訪問 / 或 /index 時就等於訪問 index () 函式， 訪問 /profile 時就等於訪問 profile () 函式

3. 使用 路徑對映

這種方式是跟 Ruby on Rails 學來的. 方法是另外建立一個類別，專門處理網頁架構.

class app(RoutesApplication):
  mapping = [
      ('/', Root.index),
      ('/profile', Root.profile)
  ]

app = app()

網頁架構是以 (' 網頁名稱 ' ,' 類別。函式名稱 ') 組成的列表來定義. 網頁名稱部份可以使用正則表達式.

結語​

我在寫本篇之前，從來沒有看懂其他網頁框架的對應方式，因此傻瓜式的物件對映方式對我來說是最直覺了，使用至今還沒什麼感到不方便的地方.

雖然本篇所作的比較簡單，無法展現各種對映方式的實際能力， 例如本篇沒有比較到輸入參數的對映方式.

以上三種方法都已經被證明有效而且許多網站正使用著這些方法運行著. 希望大家能以本篇為基礎，就較理解的 URL 對映方式繼續深入學習.

我很想知道各位看官，對於用簡單的例子來對的各種 URL 對映方式做說明是不是比較容易理解呢？

CEATEC JAPAN 2006 上東京大學的 Ezaki San 的研究室 (養海龜 的那間) 又推出了 Dual Stack Mobile IPv6 展示，可以應用在一般 IPv4 環境中. 前陣子看 Draft 時覺得這個方法很棒但是實做也很複雜，想不到這麼快就有實做展示出現了.

看展示平台的樣子是拿筆電當作 Home Agent, 拿 Sharp Zaurus 分別當作 IPv4 與 IPv6 環境下的 Mobile Node, 讓兩者可以順暢使用 IPv6 做溝通.

圖片連結自 http://www.ipv6style.jp/jp/20061018/ceatec3.html

根據這封信件所言，IETF 上 又將出現一個新的 Working Group. 這篇是他們的 Design team 在 NEMO WG 上的宣告.

這個 WG 的起因來自於 Edouard LASNIER REDDAN 一封雷諾車廠研發 MIPv6 Car 成果的信件. 信中說明在大環境使用 IPv4 的環境下在車輛中使用 MIPv6 的車子已經被開發出來了 (用的可能就是 Mobile Router), 需要解決的問題除了透過轉換透通機制在純 IPv4 網域取得 HA address 外，還有就是從車廠的角度看，HA 不能被通信商把持的問題.

MIPv6 addressing v4 traversal 看起來很值得研究， 而 HA 不能被通信商把持的問題感覺似乎在未來可以用來加持我的 NEMO-DHA 架構。可惜跟現在我的論文主題方向還是有些差別....

為了更容易了解這封信的價值.. 我把雷諾車廠信內提到的主題內容也整理成了投影片大綱了附在前一篇中

MIPv6 & traversal/Tunnel 應該將會是蠻熱的題材吧，要求的背景知識也很高， 可惜是實驗室目前要做這題材的話也等於找人重新開始學了， 從讀 traversal/Tunnel mechanism, 想 idea, 到準備模擬工具， 跟其他 lab 比起來已經沒什麼優勢了...... 殘念

我想也大概不會有人想做 (碩士班做的話從頭學再用功大概 2 年內對這主題也不可能做出好東西，除非請博班帶著大家分著做), 只是講講有這東西而已.

要我繼續留下來是辦不到的，可惜了這麼棒的東西卻不能自己做....

After watching Mark Ramm's TurboGears One Page Reference,

I made a huge MindMap to track my understanding of TurboGears svn version, I think this MindMap will help others as well.

Here are parts of them (that I've tracked):

and related Cherrypy API

Notice that a part of notes in these MindMaps are based on Mark Ramm's One Page Reference.

And it's even better if someone intrest to make a more fancy quickreference based on those early works.