BooGoo

by thinker

關鍵字:

BooGoo https://opensvn.csie.org/traccgi/PumperWeb/wiki/BooGoo 是一系列 $WEB$ framework $研究$中，最後釋出的成果。BooGoo 是一個 client side 的 framework，遵循 design for change 的原則，讓 $WEB$ application programmer 能 $coding$ by example。去除 jQuery 和 UI component，其實只是由幾百行的 $javascript$ code 加上一些 CSS 、 XHTML 所組成的。BooGoo 是基於 jQuery 實作，採 MIT license 釋出。

[attach:screenshot.png]

BooGoo 的畫面共分成兩個部分， sidebar 和 content area 。 sidebar 用來擺放各種系統功能項，而 content area 則顯示使用所要讀取的資料。其基本概念是，所有的資料都透過 $AJAX$ 的方式，載入到 content area 顯示，不經過 page load 過程。這不是一個新的$想法$，但 BooGoo 的目的，就是將做法定下來，變成$範例$，讓 application programmer 可以遵循、修改、抄襲。

BooGoo 被設計來和 linkname:ez_web http://heaven.branda.to/~thinker/GinGin_CGI.py/show_id_doc/215 配合，兩者的配合包括 client side 和 server side 的 $coding$ 方法和規則。透過這些規則，programmer 可以在確定感下，開始 application 的設計。這些規則並不是用來限制 programmer 的，而是用來幫助 programmer 起步的。隨專案的進行，programmer 對 project 的掌握度越來越高，programmer 有權力，也應該無懼的去打破或修正規則中不合適的部分。

== BooGoo 主要功能 ==
BooGoo 提供下列幾項功能，用來傳送資料到 server 和從 server 讀取資料。
 * view_page()
 * send_data()
 * send_data_and_view_page()
 * send_form()
 * send_form_and_view_page()
 * view_page_on()
 * set_stat()
 * unset_stat() 
view_page() 能從 server 讀取資料，然後顯示在 content area
{{{
view_page("my_server_url", { var1: "data1", var2: "data2"});
}}}
var1 、 var2 將成為 $URL$ 的參數，完整 $URL$ 為 http://server/.../my_server_url?var1=data1&var2=data2 。
(補述: 建議將變數編進 $URL$ 裡，做為 resource 的 identify 。變數的次序最好依其階層關係。可以 join 的方進行 ["http://server/page", "aaa", "bbb"].join("/"))

send_data() 則純粹 post 資料到 server 端。send_form() 則是將 form 的內容，透過 $AJAX$ 的方法傳送，而非由 browser 的預設傳送方式。如:
{{{#!raw
<form action="target_url" method="POST"
    onsubmit="return send_form(this, callback)">
<input type="text" ..../>
....
<input type="submit" .../>
</form>
}}}

另外 set_stat() 和 unset_stat() 則是透過新增、移除 body tag 的 class ，來改變畫面的狀態。舉例能用在可修改的頁面:
{{{#!raw
<style>
.field {
    visibility: hidden;
    position: absolute;
}
.edit .field {
    visibility: visibile;
    position: static;
}
</style>
Your name: Foo
<input class="field" type="text" name="name" value="Foo"/><br/>
Phone #: 3939889
<input class="field" type="text" name="tele" value="3939889"/><br/>

<input type="button" onclick="set_stat('edit')" value="修改" />
}}}
使用者按下「修改」鈕後，進入修改模式，而且畫面出現輸入欄位。

send_form_and_view_page() 則能在正確送出 form 的內容後，讀取另一個指定的 $URL$ ，並顯示在 content area 。
{{{#!raw
<form action="server/modify" method="POST"
    onsubmit="return send_form_and_view_page(this, 'page_after_submit', {var1: '...', var2: '...'})"/>

Your name: Foo
<input class="field" type="text" name="name" value="Foo"/><br/>
Phone #: 3939889
<input class="field" type="text" name="tele" value="3939889"/><br/>

</form>
}}}

== UI 元件 ==
除了這些基本功能外， BooGoo 也以 jQuery 為基礎，提供了兩個元件。 grid 和 gindoc 。 grid 就是 data grid ，應該不用多說，就是一個可捲動，可拉動欄位大小的 table 。下面是一個使用$範例$
{{{#!raw
<script>
function grid_sel(r, c) {
    alert("table is selected at row " + r + " col " + c);
}
</script>

<table class="outline grid widget" wrap="grid(grid_sel)" width="200" height="300">
<thead>
<tr>
<th>Col 1</th>
<th>Col 2</th>
<th>Col 3</th>
</tr>
</thead>
<tbody>
<tr>
<td>item 1</td>
<td>item 2</td>
<td>item 3</td>
</tr>
<tr>
<td>item 1</td>
<td>item 2</td>
<td>item 3</td>
</tr>
<tr>
<td>item 1</td>
<td>item 2</td>
<td>item 3</td>
</tr>
<tr>
<td>item 1</td>
<td>item 2</td>
<td>item 3</td>
</tr>
</tbody>
</table>
}}}
使用者只需要為 table 加上 widget 這個 class ，並設定 wrap attribute ，就可將 grid 的行為套在這個 table 上。

另一個是 gindoc ，一個 ReST like 的 text formater:
{{{#!raw
<div class="widget" wrap="gindoc()">
<textarea class="invisible">
== Hello ==
* item 1
* item 2
</textarea>
</div>
}}}
同樣是加上 widget 這個 class 和設定 wrap attribute，BooGoo 就將 textarea 裡的文字，轉換成 formated HTML code ，並顯示在 div 裡。

相同的方式，未來也可加上其它的 UI component。

== BooGoo 的概念 ==
BooGoo 認為所有的流程都由 client side 的 $javascript$ 來決定，透過 view_page() 、 send_data_and_view_page() 、 send_form_and_view_page() 等 function ，決定下一個 page 。而非由 server 端的程式決定 $WEB$ application 的流程。 server 端的功能，純粹是查核 client 端的資料和讀取、寫入資料庫的資料。server 端程式，純粹是做為 storage 的介面，並進行權限的管制。

由於 BooGoo 完全沒有換頁的動作，因此能持續保持 application 的狀態，而不必透過  session 或 cookie 傳遞。除了降低程式的複雜度，也能提高 scalibility。或許由 client 決定流程，會有安全上的考量。但 server 端程式，可以透過資料檢核和權限管制的途徑，避免安全上的漏洞。這種檢核和管制，就算是流程由 server side 決定的系統，也是無法避免的。

== ez_web ==
BooGoo 的模式，大大的簡化了 server side 的工作內容。server side 的功能，簡化至 data resource 的 create/retrieve/update/delete (CRUD http://en.wikipedia.org/wiki/CRUD_(acronym) ) 四種功能。ez_web 的設計，高度的配合此種模式的需求，提供必要的協助。 BooGoo 希望所有的資料都使用 URI 來表示。例如，留言板的文章，就以 http://server/board_a/msg/1001 代表一篇文章，而 http://server/board_a/msg/1002 代表另一篇文章。這和以往使用 page=xxx ，以參數指定文章的方式不同。相當接近 linkname:$REST$ http://en.wikipedia.org/wiki/Representational_State_Transfer 的做法。

ez_web 提供 kit.path_consumer() 和 rewrite_path() 的功能，就是為了支援這樣的需求。

== 結語 ==
整合了 ez_xml (template) 、 sqlcc ($database$) 、 ez_web 和 BooGoo 之後，呈現出一個 client side script 主導的發展環境。美工使用 dreamwaver ，組合基本的 UI 元件，並做美術設計。 Client side programmer 再 wrap 現成的 UI component，如 grid 或 gindoc。接著 server 端提供 storage 並做查核。這是一整套的劇本，提供 $WEB$ application 另一個設計的途徑。

== URLs ==
* https://opensvn.csie.org/traccgi/PumperWeb/wiki/BooGoo
* https://opensvn.csie.org/traccgi/PumperWeb/attachment/wiki/BooGoo/boogoo-0.1.tar.gz

最後更新時間: 2007-02-08 21:43:33 CST | 引用

查詢:

COMMENTS:

on 2007-02-09 23:22:53 CST

遊手好閒的石頭成 said ..

view_page() 的調用 service 的格式，和底下的部份 (像 REST 的) 不一致喔。這樣會不會變成 view_page() 用得是一套， REST 用得是另一套？我是兩種都接受，用 URI 時這樣做: http://example.com/className/methodName/argname1/argvalue1/argname2/argvalue2 。argname 和 argvalue 的順序可以隨意放。只看true/false的argument，可以只寫argname。以前用 php 實作的方式: http://blog.roodo.com/rocksaying/archives/2633503.html#comment-3838830

on 2007-02-10 01:12:43 CST

Thinker said ..

這個部分我保留了彈性，如果是使用 REST 格式，就必需自行組成 URL 的 path。在我自己的實驗和試作中，都是使用 path 而非參數的方式傳遞。因為 REST 型式的 URL ，是做為 resource 的 id ，其 path portion 的次序是有意義的，不適合任意變動。況且， URI 往往有階層性的，例如 board A 的 msg N ，組成 http://server/boards/A/N 其次序是有階層性的意義。因此，view_page() 時，URL 以 join 的方式產生 ["...", "boo"].join("/") 。這樣應該比較合適。

on 2007-02-10 01:23:27 CST

Thinker said ..

["http://server/base/path", "value1", "value2"].join("/") 在 server 端使用 ez_web 時，透過 kit.path_consumer 可依次序，成為 process() 的 argument。這也是 kit.path_consumer 存在的價值。

on 2007-02-10 09:57:46 CST

遊手好閒的石頭成 said ..

我記得 Python 的引數可以用 Keyword Arguments 而無視次序。應該不用像 PHP 要動用 Reflection class 探查參數次序吧？

on 2007-02-10 10:40:36 CST

Thinker said ..

是啊... Python 有 keyword argument，但我希望能保留 URI 的單一性，和 path 的階層關係。而且，固定的次序，對 application programmer 似乎比較單純一點。固定次序其實還有其它好處，debug 時比較不會眼花看錯，log 的分析較容易。這些都能減輕 programmer 的負擔。這是我設計時，依經驗而產生的考量。或許不完全正確，但會隨者時間修正。