為什麽要選擇 XForms？

理想主義者設想的是壹個全球化的互聯網絡：真實、公平、自由，任何人都能夠通過它進行自由而開放的信息交換；實用主義者則希望能在下午五點前完成工作，然後回家陪伴家人。理想主義者推崇 Standard Generalized Markup Language（SGML）、Extensible Markup Language（XML）、Scalable Vector Graphics（SVG）、Cascading Style Sheet（CSS）和 Extensible Hypertext Markup Language（XHTML）；而實用主義者信奉 HTML、JavaScript?6?4、表格和 Flash。理想主義者參加 World Wide Web Consortium（W3C），參與 Extreme Markup Languages 和 WWW 2007 這樣的研討會；而實用主義者則參加 HTML Authors Guild，參與像 Web Design World 這樣的研討會。理想主義者閱讀 Weaving the Web 和Effective XML 這類書籍，而實用主義者則閱讀像 Ajax in Action 和Designing Killer Web Sites 這樣的書籍。近來，這兩大陣營間爭論的焦點就是下壹代的表單技術：Web 2.0 應用程序或 XForms。雙方唇槍舌劍、爭論不休，因為沒有任何壹方能領會對方的目標，他們沒有任何***同語言。然而，這兩大陣營間的鴻溝並非不可逾越。許多理想主義的技術（例如 XHTML 和 CSS）已經被實用主義者所廣泛采納，因為這些技術為其工作帶來了切實的收益。可以理解，實用主義者從不追趕任何壹次 W3C 風潮，他們絕不會在第壹版的工作草案壹發布時就蜂擁而上，而是寧願等上幾年，直至新技術在他們的用戶群體中變得真正可靠且可用。他們不是早期采納者，但只要壹種技術對他們有意義而且工具支持充分，他們會是采納者。 XForms 是壹次理想主義的努力，目的在於解決當今折磨著 Web 開發人員的眾多實際問題。從現狀來看，以逐步改進傳統 HTML 表單為基礎的實用主義解決方案還算不錯，但它們永遠無法達到與 XForms 相同的高度。而恰恰因為 XForms“爬得更高”，因此如果失敗，也會 “摔得更狠”，而且會造成更大的負面影響。由於XForms 更加野心勃勃，因此希望與失望並存：希望在於將在不遠的未來成為現實的壹切，而失望則在於這壹切不可能在今天就成為現實。盡管如此，有必要理解 XForms 試圖達成的目標，這樣才能是公正地評判其他可選方案。如果 XForms 的奮鬥目標與您的目標不壹致。那它就沒有什麽吸引力。而如果 XForms 所爭取的目標正是您如今實際關註的問題，那麽也許值得您為之付出努力，承受新技術那不可避免的誕生之痛。回頁首多種環境關於XForms，您需要理解的第壹件事就是它並非僅面向 Web，也不是僅面向 HTML。當然，它也不是僅僅適用於經典的桌面瀏覽器，例如 Firefox Microsoft?0?3 Internet Explorer。XForms 的設計使它在其他許多環境中都能很好地工作，比如說移動電話瀏覽器、語音瀏覽器和壹些根本就不是瀏覽器的環境。例如，OpenOffice 2.0 使用 XForms 作為底層的表單技術。希望目前使用專利表單技術的其他產品 —— 例如 Microsoft Word、Adobe Acrobat 和 Universal Business Language（UBL） —— 將來能夠遷移到 XForms。（這些公司是否會這樣做還是未知數。）此外，與上壹代的 XML 相似，XForms 設計用於將目標與行動分離、含義與表現分離。它被設計成壹種表單需要收集的輸入的通用描述。壹個 XForms 對表單的呈現方式或用戶與表單的交互方式幹涉甚少。同壹個表單可以在壹種瀏覽器中以壹種方式呈現，而在帶有按鍵音和語音識別輸入的電話網絡則是另外壹種方式，在紙面上則是第三種方式，即人工填寫後用光學字符識別技術進行掃描。 Edsel 還是傳輸帶？我個人對於這個目標持保留態度。我稱之為技術的 Edsel 難題。試圖成為包治百病的萬金油的技術往往會以失敗而告終。W3C 的文檔對象模型（DOM）就是壹個經典例子，這壹規範努力向著過分通用的方向發展，結果令人沮喪。有時，為壹個環境度身定做的解決方案要遠遠勝於過分通用化的方式。另壹方面，有時通用化會帶來回報。或許 XForms 並不是失敗的 Edsel。或許它更像傳輸帶。您必須捫心自問，您是否真的需要同壹個表單在不同的環境中采用多種不同的呈現方式？許多應用程序並不需要這樣。例如，如果您正在編寫壹個簡單的 Web 站點投票程序，而且僅僅是出於娛樂的目的，那麽瀏覽器中的 HTML 或許已經足夠。然而，較大型的系統可能會受益於更為通用的方式。例如，壹個收集股東選票的系統通常要讓人們通過電話、書面和 Web 等方式投票。在這種情況下，壹種能夠通過單獨壹個源文檔支持所有這三種可選方式的表單技術是很有用的。或許您現在還不需要這種功能，但將來很可能會用到。例如，設想壹下，您使用移動電話呼叫服務器，並且口述（而不是打字！）壹段故事，通過這種方式實時更新您的博客。今天的語音識別技術還不足以支持這壹功能，但將來必然會發展到這種程度。當那壹天到來時，為壹個基於 XForms 的博客添加語音輸入支持只是小事壹樁，因為表單本身不需重寫。而基於 HTML 表單的系統根本無法提供類似的支持。或許我的眼光放得太過長遠，或許我應當關註眼前事而不是像科幻小說壹樣的未來界面。但這些科幻小說般的問題正是 XForms 正在嘗試解決的。回頁首多種設備支持Web 可能促進了許多計算機的銷售，但它所關註的絕對不僅僅是計算機 —— 至少不僅僅是那些傳統的臺式機。在不遠的將來，訪問 Web 的最普遍的設備將是移動電話。或許受歡迎程度次之的設備將是壹種人力膝上型電腦，它使用低功耗處理器、運行某個定制版的 Linux?0?3。許多人將會繼續使用像 Lynx 這樣的文本模式瀏覽器。XForms 的設計目的就是能夠在所有此類環境中很好地工作，而不只是在百萬色的 30 英寸顯示器上顯示的的圖形用戶界面（GUI）。實現多種設備支持的訣竅就是將表單收集的內容與表單的外觀分離開來。例如，壹份詢問送貨和收費地址的表單在 Firefox 等傳統 Web 瀏覽器中可能顯示在壹個頁面上。但在像移動電話這樣的小型設備上，它也可以輕松拆分為連續的兩屏。如果填寫表單的方式是語音而不是打字，它甚至可以是非可視化的形式。XForms 不必對用於填寫表單的設備類型做任何假設。回頁首機器的使用和自動化表單並非僅由人填寫。它也可用於在不同過程間通信。例如，壹位辦公室經理可在 Microsoft Windows?0?3 計算機上運行的富客戶端 GUI 程序中輸入辦公用品采購申請。隨後，此程序能在 OfficeMax、Staples、Office Depot 和 Laser Monks 網站上搜尋每項物品的最佳價格，然後再下訂單。這位辦公室經理在程序內填寫壹份本地表單，之後程序會將相關信息復制到提供最佳價格的商店的表單中。或許在此過程中並不需要人工幹預。壹臺智能化打印機能夠識別出墨粉即將用完，並且自動去重新訂購。為使這種場景變為現實，表單必須能被其他程序訪問，而不只是人。字段必須使用能被其他程序識別的名稱標記。而標簽（label）必須在標記（markup）中明確地附到特定的字段，而不僅僅是在頁面的可視化表現中附加。此外，如果表單能夠指定壹個字段要求輸入內容是壹個整數、壹個十進制數字、壹個日期、壹個未來日期、壹個合法的郵政編碼等，它將非常有用。在這壹用例中，表現不僅僅是從標記中分離出來，甚至可能完全不存在。人類非常聰明，能夠利用隱含的線索（例如字段在頁面上的位置）辨別什麽位置應該輸入什麽樣的數據。但計算機做不到，它們需要更多的幫助。XForms 設計用於為計算機提供這樣的幫助。關於可輸入表單的內容的信息越明確，計算機就能越輕松地自動與表單交互。回頁首國際化和本地化非ASCII 數據是表單編程和 Common Gateway Interface（CGI）中最令人頭痛的問題之壹。在涉及如何編碼和提交像 resumé 這樣的詞時（更不用說 Χηνο?0?9 或?9?6 了），早期的 HTML 和 URL 規範給開發商留下許多想像的空間。在過去的十年中，這種情況已經得到壹定程度的改善，壹些新興標準已經湧現出來。但毫無疑問，，不能以退為進。從壹開始就必須啟用 Unicode。 XForms 使用 XML 作為底層的序列化形式。當壹個瀏覽器或者其他客戶機接收來自服務器的 XForm 時，它接收的是 XML。當它將表單數據回發給服務器時，它將數據編碼為 XML 文檔。XML 文檔是 Unicode。當然也可以存儲為其他編碼，但這些編碼和 Unicode 之間的轉換是簡單和確定的。處理 XML 時，就不再存在任何編碼問題。通信的壹方以 ISO-8859-1 編碼讀取文檔而另壹方以 UTF-8 讀取的情況沒有機會出現。這將使得用希臘語、中文、法語、希伯來語和其他數百種語言填寫表單成為可能。引用 Robert Bringhurst 的壹句話，您不必再寄希望於 “沒人會提起 crêpes flambées 或 a?0?7oli；沒人叫做 Antonín Dvo?0?0ák、S?0?3ren Kierkegaard、Stéphane Mallarmé 或 Chlo?0?5 Jones；沒人居住在 ?0?7bidos、?0?3rhus、Kromì?0?3í?0?6、?0?1ster Vr?0?2、Pr?0?1honice、Nagyk?0?1r?0?2s、Dalas?0?7sla、K?0?3rka?0?6a?0?4 或是 K?0?2ln。”（The Elements of Typographic Style，Hartley & Marks 出版社，2002 年，第 90 頁）當然，真正的國際化和本地化絕不僅僅是讓人們用非 ASCII 字母輸入他們的姓名和地址。例如，允許希伯來文和阿拉伯文的表單從右向左排而不是從左向右排也是必需的。內容和表現的分離再壹次地拯救了我們。在壹個 XForm 中不存在對字段布局的任何要求，因此本地呈現程序可以自由使用任何對它來說合理的方向。無疑，提示有時也是有用的，比如說，它可以告訴呈現程序正在處理的是英語還是阿拉伯文。這又到了 XML 展示力量的時機。XForms 完全允許使用 xml:lang 屬性、雙向的 Unicode 標記、Ruby 文本，以及其他壹些對英語關系不大但對於其他語言至關重要的小秘訣。最後，表單本身需要本地化。同樣的表單必須能從已翻譯成不同語言的資源文件中加載自己的標簽和其他人類可見的內容。就像是編寫富客戶端 GUI 的時候，您不會希望將可翻譯的字符串放在源代碼中，因為翻譯人員往往不是程序員。回頁首可訪問性對於XForms，壹個最不明顯但最重要的目標就是可訪問性。壹個 XForm 表單不應只考慮視力健全、肢體靈巧的用戶。對於那些有著臨時或永久的視力、肢體或其他缺陷的人們，它也需要很好地發揮作用。這不只涉及顯而易見的視力障礙和身體殘疾用戶的範疇，也同樣意味著其他所有人。因為每個人都會在某些時刻有所不便。許多人使用移動電話的小屏幕和數字鍵在網上沖浪。也有人會在開車時利用語音界面填寫 XForms。隨著司法管轄的進壹步完善，可訪問性不僅僅是壹個好點子。它就是法律。回頁首輸入驗證填寫表單時出錯並不令人驚訝。您總是會被要求輸入電子郵件地址兩次，目的就是確保沒有拼寫錯誤。人們編寫了許多復雜的 JavaScript 代碼去校驗基本的約束條件：例如信用卡號碼的位數要正確，其失效日期應該在將來而不是在過去。當然，您可以用 JavaScript 代碼來編寫類似的檢查。但是表述約束條件是什麽要比編寫代碼進行檢查輕松壹百倍。XForms 力求通過更加直觀的聲明式方法簡化此類檢查。因此，它們可能是最先編寫出來的。某些約束條件可以在用戶輸入時檢查。例如，如果壹個輸入字段聲明輸入其中的內容應該是型號，那麽瀏覽器可能會忽略用戶按下的任何非數字鍵。其他瀏覽器可能會在提交表單前檢查這些約束條件，並在發現違規情況時警告用戶。當然，壹個健壯的 Web 應用程序不能依賴客戶機提交的任何東西。壹名惡意用戶可以在提交壹筆訂單前改變總價，從而嘗試破解系統。只有驗證數據的人才可以信任數據。客戶機可以信任客戶機驗證的數據，但服務器只能信任服務器驗證的數據。出於這方面的原因，XForms 被設計成既允許在服務器端驗證，也允許在客戶端驗證。信任，但必須驗證。所有由客戶機提交的數據可以（並且應該）根據模式進行測試，以確保它符合模型。有可能也會基於 HTML 表單來測試對傳統 Web 應用程序的輸入，但 XForms 竭力使這變得更簡單、更健壯，幾乎達到測試比不測試還簡單的程度。這應該能夠消除與 Web 相關的許多小的安全漏洞。回頁首避免數據的往返傳遞壹個系統的速度取決於它最慢的部分。在 Web 應用程序中，性能瓶頸通常不是服務器（如果它正在處理大量連接），也不是客戶機和服務器之間的網絡連接。重要的是同時把這兩方面必須完成的工作最小化。性能瓶頸很少會是客戶機，因此如果您能把任何工作從服務器或網絡轉移到客戶機上，無疑會獲得性能提升。目前的 HTML 表單壹個嚴重的局限性就在於：每壹次通過計算更改表單值時，都需要與服務器進行壹次數據往返傳遞。服務器不得不接收輸入、處理輸入，然後向客戶機返回壹份新表單。有時這是必要的，比如說服務器從只有它能訪問的數據庫返回信息時。但有時根本沒有理由說工作不能完全在客戶機上執行。例如，客戶機能夠輕松地合計出壹個購物車中所有的商品的總價並在提交表單之前顯示給用戶。事實上，幾乎所有購物車的詳細信息可以存儲在客戶機上，只在結賬時才發送到服務器。目前，這種過程是用 JavaScript 實現的，但 JavaScript 難以閱讀和維護。添加依賴於其他字段內容的計算字段可實現壹種更具聲明性的方式。此外，這些字段可以是只有客戶機才能看到的純輸出字段。服務器沒有必要查看它們。出於安全性的考慮，它會根據客戶輸入的無關數據重新計算所有結果。相關數據保留在它所屬的客戶機上。這種方式巧妙地消除了服務器程序員依靠可破壞的客戶機計算開啟安全漏洞的所有機會。回頁首結束語 XForms 設計用於在多種環境中工作，適於不同能力（既包括技術方面的能力，也包括個人方面的能力）的用戶。它將數據從表單表現中分離出來，使同壹表單能夠采用多種不同呈現方式，以滿足各種用戶的需求，從而實現了這壹目標。這要求您徹底改變自己看待軟件和設計軟件的方式。它類似於從 Word 中基於表現的標記轉向 XML 中基於語義的標記。在編程領域中，就像是從 Java?6?4 這樣的命令式語言轉向 SQL 等說明性語言。在您設計 XForms 時，必須考慮您希望從用戶那裏得到的信息，而不是表單的外觀。我不能確定這種風格的表單設計是否會比傳統可視化設計難度大，但它不那麽直觀，而且大多數 Web 設計人員並不熟悉它。這當然需要壹個適應過程。對於具有壹次性交付機制的簡單應用程序來說，這種更高壹層的間接性可能並不值得。但對於更加復雜的應用程序，它帶來了改進可訪問性、可本地化能力、安全性、健壯性和其他理想特征的真實希望。參考資料學習您可以參閱本文在 developerWorks 全球站點上的英文原文。閱讀“Introduction to XForms, Part 1: The new Web standard for forms”。XForms Requirement 給出了 XForms 必要性的最初闡述。XForms Working Group Charter 介紹最初的官方 XForms 目標。閱讀Wikipedia: XForms ：壹份極好的入門資源。Wikibooks 有壹個關於 XForms: Tutorial and Cookbook 的部分，這裏的信息經常更新。developerWorks 中國網站 XML 技術專區提供了數百篇關於 XML 開發各個方面的文章。developerWorks 技術活動和網絡廣播：隨時關註最新技術。獲得產品和技術獲取MozzIE，壹個開放源碼控件，使您能在 IE 中呈現 XForms。討論developerWorks blogs：加入 developerWorks 社區。關於作者Elliotte Harold 出生在新奧爾良，現在他還定期回老家喝壹碗美味的秋葵湯。但目前他和妻子 Beth、他們的狗 Shayna、貓 Charm 和 Marjorie 定居在布魯克林附近的 Prospect Heights。他是 Polytechnic 大學的計算機科學副教授，講授 Java 和面向對象編程。他的 Cafe au Lait Web 站點是 Internet 上最受歡迎的獨立 Java 站點之壹，子站點 Cafe con Leche 是最受歡迎的 XML 站點之壹。他的著作包括 Effective XML、Processing XML with Java、Java Network Programming 和The XML 1.1 Bible。他的最新著作是 Java I/O, 第二版。他目前從事 XOM API 處理 XML、Jaxen XPath 引擎和 Jester 測試覆蓋工具的研究。關閉[x]關於報告濫用的幫助報告濫用謝謝! 此內容已經標識給管理員註意。關閉[x]關於報告濫用的幫助報告濫用報告濫用提交失敗。請稍後重試。關閉[x]developerWorks：登錄IBM ID：需要壹個 IBM ID？忘記IBM ID？密碼：忘記密碼？更改您的密碼保持登錄。單擊提交則表示您同意developerWorks 的條款和條件。使用條款當您初次登錄到 developerWorks 時，將會為您創建壹份概要信息。您在developerWorks 概要信息中選擇公開的信息將公開顯示給其他人，但您可以隨時修改這些信息的顯示狀態。您的姓名（除非選擇隱藏）和昵稱將和您在 developerWorks 發布的內容壹同顯示。所有提交的信息確保安全。關閉[x]請選擇您的昵稱：當您初次登錄到 developerWorks 時，將會為您創建壹份概要信息，您需要指定壹個昵稱。您的昵稱將和您在 developerWorks 發布的內容顯示在壹起。昵稱長度在 3 至 31 個字符之間。您的昵稱在 developerWorks 社區中必須是唯壹的，並且出於隱私保護的原因，不能是您的電子郵件地址。昵稱：（長度在 3 至 31 個字符之間）單擊提交則表示您同意developerWorks 的條款和條件。使用條款. 所有提交的信息確保安全。為本文評分評論回頁首