從 Dynamic 、 script 到 Python

by thinker

關鍵字:

我是一個心血來潮的人，這幾天又心血來潮弄了一個 $WEB$ 的 framework 。之所以會重新設計一個 framework ，是有感於 $XML$ 和 XLST 的肥大，不但沒有如其所號稱的減輕 programmer 的負擔，還讓 programmer 必需在不同的語法間轉換。而 server page 的設計，讓 HTML 和程式語言混雜在一起，無全破壞了程式的美感。 server page 的原始碼，只能用垃圾來形容。

不可否認的， XLST 的功能確實強大，能將 representation  和 control 完全分離。 $WEB$ programmer 要做的是，將 control 產生的資料轉成 $XML$ 形式，再以 XLST 完成 template ，最後 runtime 執行 translator 產生 XHTML 。XLST 實在是一個囉嗦的語言，為了做 flow control 必需加一大堆的 tag ，完全不直覺、壟長，也容易 typo 。因此，除了在 $GinGin$ 這個 project 試用之外，我再也不使用 XLST 這樣累人的東西。

server page ，如 PHP 、 JSP 、 PSP ($Python$ Server Page) 等，能提供很強大的控制能力。但，它的問題在，把 HTML code 和程式碼混在一起，每每都讓我頭昏眼花。又因為 representation 沒辨法從 control 抽離，造成每個 server page 的 programmer 不斷在套版面的地獄裡打滾。 Java 制定了一堆 tag library ，這些 tag 減少部分的問題，卻增加了其它問題。重要的是， programmer 依然痛苦在套版面，還得一方面學習變化多端的新 tag 。而，包含 tag library 的網頁，不再能靜態觀察了。你必需放到 server 上去看，否則你永遠不知道 render 出來的結果正不正確。

== 新的 Framework ==
累積了種種抱怨，我動手設計了這個 framework 。主要目的是要解決 MVC 裡頭的 V 和 $C$ 的糾葛。這時 $Python$ 的 dynamic typing 和 script-language 的特性，大大的幫上了忙。script-language 的特點，能讓我直接利用直譯器的能力，提供一些指令，也不需要寫複雜的 parser 。 Dynamic typing 的特點，讓我在處理不同資料來原，可能發生複雜的資料型別變化時，可以不用定義複雜的型別架構。依靠 $Python$ 的方便性，只需花數個小時就能完成一個簡單的 template generator ；從 XHTML 產生 $Python$ code template 。

programmer 或 art 可用 nvu 或者 Dreamweaver ，做出類似下面的檔案:
{{{
.....
<table>
<tr>.....</tr>

<tr temp_act="group_pattern(this)" background="red">
<td> <span temp_act="replace_node('item')">ITEM1</span></td>
<td> <span temp_act="replace_node('number')">NUMBER1</span></td>
</tr>
<tr temp_act="group_pattern(this)" background="green">
<td> <span temp_act="replace_node('item')">ITEM2</span></td>
<td> <span temp_act="replace_node('number')">NUMBER2</span></td>
</tr>

<tr temp_act="ignore()">.....</tr>
<tr temp_act="ignore()">.....</tr>
</table>
....
}}}
FAKE_* 和 temp_act="..." 的部分是由 programmer 加上，其它是由 art 產生的。在 parse 這個 XHTML 的 source 時，我直接使用 linkname:[xml.dom] http://docs.python.org/lib/module-xml.dom.html 來產生 DOM object tree ，我只需 travel 整棵 tree 。讀出每一個 tag node 的 temp_act attribute 和 FAKE_* 開頭的 comment 來處理就可以了。FAKE_BEGIN 後面和 temp_act 的內容，其實就是 $Python$ 的 function call 。我只將這些 code 從 node 的 attribute 讀出來，或是 comment 的 data 讀出，就可以交代給 $Python$ 的 interpreter 幫我處理剩下來的部分。

例如:
{{{
def group_pattern(this):
   ........

def replace_node(path):
   ......

code = node.getAttribute("temp_act")
gdict = {'group_pattern': group_pattern, 'replace_node': replace_node, .......}
ldict = {'this': node }

exec code in gdict, ldict
}}}
將所要提供的功能和資料，設定在 global 和 local namespace ，並用 exec 指令在您所設定 namespace 裡執行 temp_act 的內容。如此，我們就可以透過 implement 這些 function 的方式，提供各式各樣的功能。

== Fake Tag ==
FAKE_BEGIN 和 FAKE_END 的目的，是為了避免在 XHTML 裡，加入多餘的 tag 。因為這可以會影嚮到 browser 對原始的顯示結果。例如，我設計了一個 repeat_group() 的 function 。這個 function 能將該 node 及其 children 轉換成一個可以重複的 pattern ，以顯示 list 型態的資料。經常你會需要幾個不同的 pattern 輪流使用，例如單行顯示紅色，雙行顯示藍色。因此，在 repeat_group() 底下的 tag ，你可以使用 group_pattern() 來定義數個 pattern 。依其次序，輪流使用。以前面的例子來說，若我們在 table tag 呼叫 repeat_group() ，將在每兩筆資料產生一個新的 table 。於是我們會變成有許多只有兩筆資料的 table ，而非一個 table 包含所有資料。

{{{
<table>
<tr>.....</tr>
<span temp_act="...">
<tr>....</tr>
<tr>...</tr>
</span>
}}}
若不想如此，就必需在這兩個 pattern 的外圍，多加一個 tag，以呼叫 group_pattern() 。但是這造成 browser 在讀取 XHTML soruce 時，有不同的 render 結果。為了避免這個窘境，我加入了 fake tag 的$想法$，也就是由 FAKE_BEGIN 和 FAKE_END 的一對 comment ，模擬成一個 tag。當我們的 template generator 在讀取 XHTM soruce 時，遇到這樣的 comment ，就會為這一對 comment 產生一個 fake tag ，並將之間的所有 tag node 都加入為 fake tag 的 children。如此， generator 在處理時，就可以減少例外狀況的複雜度。而 browser 在讀取 XHTML source 時，也不會受到額外 tag 的干擾。

== 設計 Function ==
就這樣，我們設計了一些 function ，而不是弄了一個很複雜的 parser 。這就是 $Python$ 所方便， Java 的 programmer 應該會在這個地方拜倒，或者是去找另一個 embedded script language 。

透過 generator 產生的是一個 $Python$ module 。一個 $Python$ module 就是一個 template 。programmer 只需要 import 這些 module ，呼叫 template() 這個 function 就可以使用了。
{{{
import $test$_template
.........
$test$_template.template(data)
}}}

== Dictionary ==
Data 要以什麼格式傳給 template 嗎？ $XML$ 嗎？ 當然不! 我們將所有 data 都裝在 dictionary 裡面， $Python$ 是一個以 dictionary 為基礎的語言， dictionary 隨處可見，也充滿了彈性。因此，我們將資料裝在 dictionary 裡，就像 $XML$ 一樣，成為 tree 狀況架構。
{{{
<data>
<record><item>..</item><number>....</number></record>
<record><item>..</item><number>....</number></record>
<record><item>..</item><number>....</number></record>
....
</data>
<url>....</url>
}}}
像這樣的資料，我們可以用 dictionary 表示成:
{{{
data = {
  'data': {
       record: ( {'item': ..., 'number': ...},
                        {'item': ..., 'number': ...},
                      )
       },
  'url': '...............'
}
}}}
以這種形式，程式可以很容易的操縱這些資料，而且還能有 $XML$ 的功效。我想不出有什麼理由， $Python$ 的 programmer 不使用 dictionary ，而使用 $XML$ 。如果您需要和其它人交換資料， dictionary 也很容易轉成 $XML$ ，只而寫個 function 去 travel dictionary 的 tree ，一對一的產生 tag 。因此，我強烈覺的， $Python$ 的 programmer 應該用 dictionary 而非 $XML$ 。其它語言應該也是一樣，除非您的 dictionary 和 Java 的 dictionary 一樣難用 :p

== 結語 ==
寫了這麼長一篇，其實還有很多想寫，但是我已經手軟。除了 template 的 generator ， 我還寫了一個簡單的 $CGI$ framework ，可以配合 template 使用。同樣是利用 $Python$ 的特性，在數個 component 之間傳遞訊息，達到所謂的彈性。擴充，只是增加新的 module ，新舊功能很快的融合在一起。最後，老話一句 「 KISS; Keep It Simple and Stupid 」，何必將事情搞的很複雜，簡單點不是很好嗎？Template 只需要很簡單的資料置入的功能，何必弄來「能上天下海」的神力。

最後更新時間: 2007-01-03 22:03:17 CST | 引用

查詢:

COMMENTS:

on 2007-01-04 16:04:44 CST

gasolin said ..

您試過 python 的 genshi 或 kid template 嗎? 看起來像是頗類似的東西.

on 2007-01-05 14:26:08 CST

Thinker said ..

gasolin, 我去看了一下 kid 和 genshi, 我的結論是方向完全不同。這個 template 的目的是避免在程式中接觸 XML 或 XHTML/HTML ，而 kid 和 genshi 則幾乎是建立在 XML 之上。而 kid 則和其它 server page 沒兩樣，在 template 上面做大量的 flow-control ，使的 programmer 在套版面時，非常的痛苦。而 art 也無法正確的看到套版面後的靜態結果，這是我在極力避免的。

on 2007-01-24 11:47:00 CST

遊手好閒的石頭成 said ..

Python 的 Dictionary 和 JavaScript 的 Object 語法幾乎相同。所以這裡的 dictionary 也可以用獨立的 JSON 文件儲存。彈性會更好。 See also <a href="http://blog.roodo.com/rocksaying/archives/2644922.html">Example of Configuration Driven Development with PHP</a> <br/> 我覺得動態語言的資料記述語法本身就具有結構性，和 XML 一樣是種結構化文件。不像 Java/C# 必須要用 XML 記述。是以在動態語言中， XML 只是一個「選項」，而非必要事項。