之前在這篇《回應 zmx: 該怎麼說 HTTP？》提到了所謂的「在 <table> 和 <tr> 之間隱藏 <form> 的技巧」，就此解釋一下。
<form> 是一個 CSS 屬性 display 為 block 的 HTML tag，所以他的呈現，會是一個矩型的區域，不管在 IE 或是在 mozilla/firefox (gecko) 之下，都會有一個特點：<form> 的內含區域的下方會有一塊留白。這是什麼意思呢？讓我們來看看範例就知道。
範例一：一個 <table> 內含一個 <form>，<form> 再內含一個 <table>：
<table border="1"> <tr> <td> <form> <table border="1"> [...]
抱歉，之前發文的時候忘記加標題了，然後後來補標題時，又看錯文標成另外一篇要標的題目，我不是對這個 issue 想搖頭啊。:-p
GET/POST/HTML 之間，最大的問題，是由以下幾個事實組合而成的：
瀏覽器可以把 JavaScript 關掉，網站老闆為了保證他的網站，即使在這樣的情況，仍然能夠正確執行，會要求網站苦工在主要功能上，不得依賴 JavaScript。
要發 HTTP Post request，在 HTML 裡必須要有 <form> 的存在才有可能。
而不依靠 JavaScript 想要把 <form> 給 submit 出去，只可能利用 <input type="submit">，或另外一個 image button 什麼的。
<form> 對應的 CSS display 屬性是 block，在 IE 裡，一定會佔有空間，造成排版上的不對齊。雖然說有在 <table> 和 <tr> 之間隱藏 <form> 的留白的取巧辦法可以解決這個問題，但不是每個網頁都有用到 <table>。
除非網站老闆可以接受畫面、操作方便性的不完美，否則 POST + HTML 必定不可能達到老闆的需求與時代的趨勢 (RIA)。
我看了 XPlanner 的 screenshots，感覺這也是相當強大的軟體。我現在比較會碰到的困擾是，issue tracker 常會無法與 process 整合。要把 issue tracker 用的好，勢必要有一套 process 配合。但因為人工作時的活動，其實是非常 dynamic 的，若要遷就 issue tracker 所內含的 process 邏輯，人會感到非常痛苦。
我覺得應該是要讓 issue tracker 來配合 process 才對。雖說人的工作過程是 dynamic 的，但還是會自然而然地形成出一種流程，這樣子的流程，其實才是最符合開發的需要。
我在使用 Trac 時，也會感到這種與 process 的不協調感，所以才會想簡單弄個 Trac Aggregator，看看能不能解決一些已經意識到的問題。這還是只有我一個人在用，我不敢想像多人使用的情況下，事情會變得多糟糕。
不曉得 Edward 兄在工作上，使用 XPlanner 有沒有什麼心得呢？:-)
前陣子我在 blog 上簡單介紹了 Trac Aggregator，因為在工作上總是必須多個專案同時進行，相互依存，又因為當初規劃 repository 的決策，造成搭配 Trac 時，因為 Trac 沒有 multi-project support，而使用起來非常麻煩[1]。所以只好簡單地寫了這個 PHP script 當作個人工作用的 issue portal。
其實說穿了很簡單，Trac 的 report 是藉由讓使用者自行編輯 SQL 指令而產生的。而 Trac 的資料庫就放在 TRAC_ENV 下的 db/trac.db 這個 SQLite 資料檔裡。所以我們只要自己用 PHP 開 SQLite 資料檔，然後把 Trac 裡的 report 的 SQL 指令搬過來，排版 output 一下，簡易版 Trac Aggregator 就完成了。
比較麻煩的，反而是如何呈現跨專案的 ticket list。由於每個專案的 milestone 進度都不會相同，排序的問題就相對地複雜很多。目前我只是簡單地在 script 裡，用 compositional compare function [...]
當初規劃工作用的 Subversion repository 時，我選擇將各個專案擺在各自的 repositories 裡，而沒有依照 SVNBook 裡介紹的 repository layout 基本型，將所有專案依目錄規劃，通通擺在一個 repository 裡。這樣各有好處和壞處：
把專案分開放在各自的 repositories 裡：這麼做的好處是，backup/restore 時非常方便，可以 by project 做 backup 和 restore，這在當 respository 變很大的時候更是明顯[1]。不過當同時進行多個專案，且互有牽扯包含的時候，這樣的作法就不太好，如 revision number 會有很多份，無法用單一一個 revision number 來表達一個軟體 (由多個專案組合而成) 的 snapshot。
把所有專案通通放在單一一個 repository 裡：管理起來會比較麻煩，目前我眾多的 repositories 共佔用 1.3G 的磁碟，如果這是單一一個 repository 的話，那在備份的時候，管理者就會很頭痛。至於壞處則是，由於目前 Subversion 只能夠藉由 svn:externals 進行跨 repositories 的整合，因此，我們便無法在不同專案間，svn copy 來去自如。
如果不只放程式檔的話，通常會膨脹的很快。我之前在從 CVS 跳槽到 Subversion [...]
因為不爽只給白金會員下載功能，gslin 公告推出 無名小站 Blog 備份服務，讓大家可以以 RSS2.0 的格式，完整下載無名小站的 blog 資料。這樣就等於是開放整個 blog 了，任何人都可以用來下載無名 blog 上任意人的 blog 資料，甚至砍整個站，不曉得會不會產生法律問題。從技術上來說，這樣子無名是無法擋的，就跟鎖右鍵防止下載圖檔是無效的一樣，看的到就抓的到。
不過寶貝還是不願撤離無名，我也只好由她了。@@a
在愛德華日誌看到這篇《Subversion 最佳實務》，愛德華應該一樣是在台灣工作吧？看到有台灣的公司這麼先進，實在高興。我們部門現在用的是非常鳥的 Visual SourceSafe (VSS)，根本一點都不 safe。我只好偷偷自己用 Subversion，有需要的時候，再來和 VSS 做 sychronization。苦啊！
Issue tracker 建議使用 Trac，這是我見過目前與 Subversion 整合的最好的 issue tracker。剛也寫了一篇關於 Subversion 與 Trac 的升級心得，歡迎指教。Trac 最可惜的就是直到 1.0 版大概都還不會有真的 multi-project support，我只好另外寫簡單的 Trac Aggregator 來湊合著用。很希望能多和大家交流版本管理系統的使用心得。:-)
就在前幾天，Subversion version 1.2.0 終於 release 了，於是我就在等 Ports，兩天後，devel/subversion 總算升到 1.2.0 了，趁著今天空閒，我做了升級。畢竟，我需要的 Issue 2065、2099 和 2134 都是修正於 1.2 版，要升上去才能用。
升級之後，一切順利，唯一要注意的是，svnadmin create 的 --fs-type 的預設值從原先的 bdb 改為 fsfs。我比較喜歡 bdbfs，至少因為 bdbfs 在 Subversion 裡的歷史比較悠久，應該會比較保險一些。所以我一併把我的 svn-newrepo.sh 修改了一下，強制預設使用 bdbfs，只要我都是用 svn-newrepo.sh 建立 repository，便不會因為忘記這個預設值改變的事情，而設錯了 --fs-type。
不過，我還是發現了另外一個問題。也就是新的 Subversion 1.2.0 和 Trac 0.8 並不相容，進 Timeline 區時，便會顯示如下的錯誤：
Traceback (most recent call last):
File "/usr/bin/trac-admin", line 34, in [...]
前幾天 zmx 在他的 blog 發表了這篇《你會說 HTTP 嗎》。這應該是延續之前 Google Accelerator 的 bug 而來的話題。老實說，「不會更改資料的用 GET，會更改資料的用 POST」是沒錯，可是問題就真的是出在 HTML 的設計不良，Web application 一直有向 RIA 靠攏的趨勢，可惜偏偏 HTML 的天性不適合如此。在沒有更好且廣為接受的替代方案出現之前，大家也只好用這些偷吃步的方法迂迴達到目的。
非不為也，實不能也啊～ 然後 W3C 制訂的 XForms 這個 HTML <form> 的後繼者又實在太過複雜，也根本還沒訂定完成。這叫眾多 web developers 如何是好？
ps. 實在看不懂 Xuite 的 trackback 怎麼用。:-(
來追一下 Ajax 技術吧。:-) 研究分析：
Flickr: From Flash to Ajax
參考資料：
Ajax: A New Approach to Web Applications - 介紹 Ajax 的文章。
BackBase－Axaj-based RIA - 自從 Flickr 棄 Flash 而就 Ajax 之後，Ajax 這個詞就紅了起來。其實概念很簡單，不過大環境到最近才成熟。三、四年前的時候，大家就有在幻想這樣的架構，但根本作不出來。因為 browser 彼此之間的相容性太差，與 W3C 標準差別太大，根本很難下手。再加上那時候的 W3C 的標準，也過於陽春，Ajax 需要的一些關鍵技術，也尚未成熟。現在技術成熟了，也許漸漸地市場上就可以看到 Ajax 相關的程式庫甚至 framework 出現了，好比阿修現在推薦的 BackBase 這間公司的產品。
Ajax and FlickrJS - 既然 Flickr 開始用 Ajax 了，當然原本的 Flickr API 就也該有個 [...]
