當我撰寫本文時，有兩種技術在剛剛發布或馬上要發布的時候，就獲得了令人難以置信的發展動力，在與各自相關的應用領域內掀起了小小的革命。 XForms 是人們期待已久的替代 Html 表單的技術。它超越了對 XML 的簡單重復，提供了一種 XML 編輯方案和經過抽象的用戶界面層。與此同時， 可伸縮向量圖形（Scalabel Vector Graphics, SVG）隨著它加速進行的第二次小版本升級，戲劇性地擴展了應用的場合，適應性與可擴展性也比以往更高了。本次系列文章介紹了研究這兩種技術的全新視角，並展示出將兩者集成起來的方法。本文首先對 XForms 和 SVG 進行分析，並研究它們之間可能的相關性。
XForms
XForms 是 HTML 表單的繼任者，但是在開發基於表單的交互式應用中，Html 表單的重要性不應該被忽視。
Html 表單簡史
我假設您作為一名 developerWorks XML 專區的讀者，可能已經具有了 HTML（以及後來的 XHTML）及其表單功能的相關應用知識。HTML 表單最早實現了客戶機和服務器之間的交互，這比靜態文檔請求更進了一步。HTML 表單是一種非常實際的方法。它通過各種不同的預先設置好的小控件（widget），如 簡單的輸入字段、文本框、單選按鈕、組合框、選擇列表等等，給開發 Web 內容的人員提供與用戶交換文本數據的手段。毫不誇張地說，Web 能發展到今天這個狀態，Html 表單是起了重要作用的。不過我們還是要關注一下這項技術的真正意義。Web 並不僅僅是一種不可思議的催生新的發展趨勢和全新經濟模式等等的通信手段。事實上，Web 開發本身並不像聽上去那麼美好。每一個開發人員，只要曾經用基於表單的交互技術開發過哪怕是相當簡單的 Web 應用程序，就能給您列出一大串讓人心煩的問題。毫無疑問，這其中就包括 XForms 致力於解決的問題，比如驗證，還有對用戶界面控件輸入值的限制等等。
在 Html 時代，驗證通常是很頭疼的問題，開發人員解決這一問題的方法一般有三種。第一種，也是最直接的一種方法是，讓服務器負責驗證，一般是通過 Perl 這樣的腳本語言實現的。編寫這樣的程序是異常乏味的工作，這種解決方案本身也很糟糕，因為每當在表單驗證過程中遇到錯誤，就必須傳回一個新文檔，稍後再重新處理一次。第二種方法是在客戶端驗證，這牽扯到在完全與所用平台相關的對象模型上使用基於 Java Script 的腳本技術。第三種方法是第一、二兩種方法的結合。不管您使用哪種方法，所需的工作依舊讓人望而生畏，得到的結果也永遠無法令人滿意。
在用戶界面方面，情況也不是很好。我在 上面列出的所有 UI 小控件一開始都還不錯，但是很快問題就出現了。UI 控件的范圍相當小，如果要提供更豐富的輸入機制，如用於選擇離開日期的日歷，那麼人們就必須采用智能化的客戶端腳本和可怕的 DHtml 方法。這些技術對於兼容性而言都是可怕的負擔。每一種表單控件的外觀和行為都與特定的平台緊密相關。盡管這樣的方法可以與用戶的環境很好地集成，但是它限制了創建完整的定制控件的可能性，也無法為了實現更廣泛的用途而對圖形界面進行簡單的修改，甚至不能保證多種平台上都具有一致的外觀。
除了驗證和用戶界面控件這兩個重大問題之外，設備依賴性、可訪問性、缺乏與 XML 集成的手段等問題也同樣值得關注，因此我們必須開始研究新的表單解決方案。當 W3C 開始開發下一代 Web 表單時，所有這些問題都被考慮進去了。
用 XML 方式實現的表單
近來很多 Web 應用程序都開始圍繞 XML 做文章。隨著這樣的應用程序越來越多，XML 的功能已經體現到客戶機上（比如使用 XHtml）。XForms 與 XML 平台緊密連接在一起，因此能與 XML 的處理流程完美結合。XForms 將表單的模型和表現完全分離，從而引入了一種全新的表單表示方法。
表單的 模型基本上是一種結構化的占位機制，用戶可以通過適當的人機界面向其中輸入數據。在 XForms 中，內容開發人員用 XML 定義這個模型，即采用最能滿足需要的 XML 定制文法，根據特定的目標來建立模型的結構。一旦定義好模型之後，剩下的工作就只是定義哪些部分要通過用戶界面暴露出來了。
用 XForms 定義用戶界面的方法相當抽象，您也永遠不會直接規定需要的 UI 看起來是什麼樣子。內容開發人員通過內置的 XForms 元素構建用戶界面。從一種比較高的層面上來說，XForms 元素定義用戶如何輸入或選擇模型中的某個特定元素（通過 XPath 表達式指定）。要是用沒那麼抽象的方式來表示最後一句話，在 Html 中您說“在這兒畫一個文本輸入控件，讓用戶輸入日期字符串”，而在 XForms 中，您說“給用戶一個合適的控件，以便選擇適合我的模型的值。”
這種方法是不錯，但它到底是怎麼解決前面那些問題的呢？XML 模型出色的地方在於，您可以（通過內置的 W3C XML Schema 數據類型或者XForms 自己的類型）真正將某一種數據類型綁定到模型中的任意元素上。首先，當用戶輸入或者通過控件選擇某個值的時候，對這個值的驗證工作可以通過 XForms 結合指定的數據類型自動完成。其次，由於您的模型元素具有數據類型，當您通過用戶界面元素引用它的時候，您可以肯定，用戶能獲得一種適當的數據選擇方式。在前面我們提到 XForms 中您可以說“給用戶一個適合的控件，以便選擇適合我的模型的值。”，因此，如果您想要提供的是日期類型的值，那麼 XForms 就有可能識別出這些提示，為您顯示一個日歷控件來輸入日期。
不管您是否相信上面的話，我這裡也只是剛剛涉及 XForms 的皮毛而已，有關這方面的更多資料，請您參閱 參考資料。前面我提到過 Html 表單的一個缺點，就是它缺乏對樣式的支持。在 XForms 中，沒有哪個用戶界面元素具有多種外觀，因為這些元素僅僅定義了交互中的約束條件（如可以選擇的條目數）。數據類型是提示 XForms 將適當的輸入控件表現給用戶。您可以用 SVG 來實現 XForms的表現和交互層。下面看看 SVG 最近都取得了哪些進展，這些進展又是如何幫助我們實現上面的設想的。
可伸縮向量圖形
XForms 和 SVG 的新特性之間具有潛在的協作能力，很多設想都可以因此而實現。
早期的 SVG 1.0
2001 年 9 月，SVG 1.0 成為一種推薦標准，從那個時候起，這種技術逐漸在相當多不同業務領域內得到應用。其中值得注意的應用范圍包括地圖與圖形。最近，SVG 借助開放源代碼項目在其自身之上進行了越來越多的面向應用程序的開發，這些項目的目標是提供可重用的、基於 SVG 的用戶界面控件庫。在這些項目中，交互式 SVG 的基礎就是腳本語言（一般是 ECMAScript）和 DOM（包括 SVG 專用的擴展）。
雖然這些項目的基礎都是相同的，但是庫的架構卻在朝不同的方向發展。構造這樣的架構有一種非常直接的方法，即在庫中提供面向對象的 ECMAScript API。這樣，如果我想創建 SVG 的組合框，我就可以提供一個 SVGComboBox 類。用戶可以創建這個類的實例，調用若干方法填充參數值，並發出繪制命令 —— 這種方式與傳統框架中的普通 UI 工具箱非常類似，比如像 Swing、WinForms、Aqua 等等。雖然這些庫事實上是在 SVG 之上建立起來的，提供 API 只是為了對庫中的 DOM 腳本機制進行抽象，但是幾乎不存在與 SVG 語言本身集成起來的情況。此外，使用每一種控件的定制 API 都需要經歷一個學習過程，而且，我們沒有利用 XML 內在的優點，如聲明或語義等等。
可以用一種聰明些的方法來提供可重用的庫，即讓一些 XML 作為公共的 API。回到我剛才提到的組合框的例子，我可以在自己的名稱空間中給用戶提供一個 XML 元素，比如 <ui:comboBox> 。庫中有一部分程序在加載的時候對整個文檔進行解析，檢查什麼地方出現了 <ui:comboBox> ，然後構造出 SVGComboBox 對象。 <ui:comboBox> 元素基本上是作為一種速記的形式，用來調用 SVGComboBox 實例中所有必要的方法。由於我定制的元素是 DOM 的一部分，所以在用戶通過 DOM API 訪問我的定制控件或更改屬性值（如 x 坐標位置，或控件內容）的時候，我還是可以使用轉換事件。隨著時間的流逝，很多開發人員都認為這種方法是更加適合的。他們相信，以 XML 為中心的方法更能適應於 SVG 環境。
然而人們已經證實，這種方法並不像原先想像的那樣是最佳的方法。渲染的工作依舊在文檔樹中進行，人們已經證明這種做法在一些情況下會使系統崩潰。將所有的東西放在同一棵樹中也是有風險的。最大的風險是自定義信息與原始結構混合。如果不同的擴展信息對文檔樹中的內容有所假設的話，上面的做法會導致它們之間不兼容。
一些 SVG 開發人員一直在討論在 SVG 之上構建擴展機制的方法。這些討論為 W3C SVG Working Group 提供了必要的信息，他們可以在規范中解決這些問題。在 SVG 1.2 中，我們發現了解決方案的第一個征兆，其中出現一種稱為 RCC 的新特性。
揭開面紗：RCC 與 SVG 1.2
Rendering Custom Content (RCC)是在 SVG 環境中使用定制 XML 文法的最新基礎框架。RCC 框架在 SVG 實現技術和概念之上提供了相當輕量級的一層。
RCC 給開發人員帶來的主要快樂就是它將 SVG 1.0 以前隱藏得很好的一個概念暴露了出來，這個概念叫做 shadow tree（影像樹）。影像樹在 SVG 1.0 中用來擴展 <use>、<pattern> 以及 <marker> 這幾個元素的 SVG 表現。直到現在為止，SVG 實現中依然包含了對影像樹的操縱，RCC 允許外來文法中的任何元素都可以擁有公共的影像樹，這樣就將這種機制暴露出來了。SVG 1.2 為訪問影像樹提供了新的 DOM API；您可以通過常規的 DOM API，像操縱常規文檔樹一樣操縱影像樹。假設您生成的全部圖形及附加的事件監聽器都存在於一個自包含的樹中，另外的組件很難觸碰到。即便您真的想這樣做，也要完全了解在這棵樹之內做的任何工作都可能是破壞性的。有了影像樹之後，文檔樹中剩下的唯一一樣東西就是您的定制元素，除此以外別無他物。
您的目標是用 DOM 腳本控制定制元素，以及用通用的方式將定制元素集成到文檔樹當中。RCC 只是問題的一方面，如果您想讓元素像其他任何 SVG 元素一樣，那麼事件方面也需要同樣地處理。SVG 1.2 中有另外兩個與 RCC 有關的新標准： DOM Level 3 Events和 XML Events（參閱 參考資料）。有了 DOM Level 3 Events，您就可以為定制類型創建專用事件。這樣，當用戶通過這個元素的圖形外觀（位於該元素的影像樹中）選擇新值時， <ui:comboBox> 就能夠發出一個 select 事件。
能夠發出定制事件當然很好，但是還需要能夠 監聽 這些事件。為此，可以使用原來 DOM Level 2 例程中的 EventTarget::addEventListener() 方法。然而，這種方法意味著需要一個編程環境，而我們通常期望能用描述性的方法在給定元素中實現對事件的監聽。有了 XML Events，您就可以通過標准的聲明語法來監聽任意的事件，內置事件或自定義事件都可以。您不再需要那些基於屬性的事件監聽器（如 onmouSEOver ），也不需要朋友們的幫忙。同時，在事件方面，RCC 也為 SVG 帶來了兩個新的內置事件，它們與用 RCC 定義的外來元素的綁定機制有關。在本系列的下一篇文章中您將會看到，這兩個事件，以及整個 RCC 框架，都是非常優秀的東西，它們使得 SVG 開發人員能提供與常規 SVG 元素類似的定制元素，從而為把 SVG 作為所有 XML 應用程序的全新編程平台鋪平了道路。
結束語
XForms 是高度抽象的，基於 XML 的解決方案，對 Html 表單構成了挑戰。它實現了數據與表現的完全分離。同時，SVG 1.2 通過影像樹和直接的事件集成機制，提供了更具擴展性的平台，並將這些封裝在 RCC 框架中。了解這些情況之後，就應該開始用 RCC 提供的簡潔方式構建定制 UI，然後在 XForms 環境中重用這些組件，從而提供一種豐富的用戶體驗。本次系列的下篇文章將著重介紹如何創建基於 RCC 的 SVG 組件，稍後，我們再深入探討與 XForms 的集成。