使用基於組件的框架
在爲傳統的Web 應用編寫HTML 頁面的時候，頁面作者手邊只有非常有限的一套預定義GUI 組件，即HTML 表單元素。它們的特徵集近10 年來幾乎沒有什麼變化，與現代的GUI 工具集相比，它們是非常基礎和令人失望的。如果頁面作者希望引入樹控件或者可編輯的柵格、日歷控件或者動態的分級菜單之類的，就需要藉助於基礎文檔元素的低層編程。這跟開發者使用組件工具集（例如MFC、GTK+ 、Cocoa 、Swing 或QT）來創建桌面GUI 的抽象級相比，似乎是非常差的選擇。
1. Web UI 組件
基於組件的框架的目標是通過提供服務器端組件工具集（其API 類似於桌面GUI 組件集的API），來提高Web UI 編程的抽象級別。當桌面UI 組件呈現自身的時候，它們通常使用低層調用在一個圖形上下文上繪圖，來生成幾何圖元、位圖或者類似的東西。當基於Web 的UI 組件呈現自身的時候，它們自動生成能在瀏覽器中提供相同功能的HTML和JavaScript 流，以減輕可憐的編程者在低層編程的苦差事。圖5-4 展示了基於組件的Web 框架的結構。
圖5-4 基於組件的框架的架構。應用被描述爲一些組件的集合，它們通過向瀏覽器發送HTML和JavaScrpt流來呈現自己。除了蒐集瀏覽器發送到單個組件的請求的較大的控制器和較大的領域模型外，每個組件還包含自己的小規模的模型、視圖和控制器
很多基於組件的框架都使用桌面風格的隱喻來描述用戶交互。也就是說，按鈕組件應該有點擊事件的處理函數，而文本域組件應該有valueChange 處理函數，等等。在大多數框架中，通過每一次用戶交互觸發一個請求，大部分的事件處理都委派給了服務器。更加聰明的框架則設法在場景的背後完成這樣的任務，但是在有些框架中每一次用戶事件都會刷新整個頁面。這明顯導致了笨拙的用戶體驗，因爲一個設計成UI組件集的應用，相對於使用Model2 設計成頁面集合的應用，通常會有大量細粒度的交互。
這些框架的重要設計目標是能夠從一個單獨的UI組件模型描述來呈現不同類型的用戶界面。一些框架，例如，針對.NET和JSF（JavaServer Faces）的Windows 表單，已經能夠做這件事了。
2. 與Ajax 互操作
那麼基於組件的框架如何適應Ajax 呢？表面上看，兩者都是從類似文檔的界面向基於UI 組件的界面轉化的，所以出現重疊應該是件好事。如果理解Ajax 的可插拔的呈現引擎能夠開發出來，這種類型的框架會強大到足以生成客戶端應用。這樣做有相當大的吸引力，因爲它可以避免對開發者進行再培訓去學習JavaScript 的複雜性，並且它通過普通的舊式（plain-old）HTML 呈現系統，爲較爲陳舊的瀏覽器提供了一個替代品。
對於那些僅僅需要標準UI 組件類型的應用，這樣的解決方案會工作得很好。然而，僅有一定程度的靈活性是不夠的。例如Google Maps （參見第1 章）成功的很大原因就在於它定義了自己的UI 組件集，從可滾動的地圖到用於縮放的滑動條、可彈出的氣球提示和地圖上的大頭針等等。試圖使用桌面UI 組件的標準集合來創建這些效果是非常困難的，即使最終創建出來了也可能不會令人滿意。
也就是說，很多應用的確更容易適應傳統範圍內的UI 組件類型，這種類型的框架可以很好地爲它們服務。在靈活性和方便性之間取得平衡對於很多基於代碼生成的解決方案是相通的，也很容易理解。
爲了給Ajax 應用提供完全的服務，框架也必須有能力提供必要的數據。這可能會有更多的問題，因爲控制器緊緊地綁在了服務器層上，並且緊緊束縛在通過桌面隱喻來定義的機制上。有很好響應性的Ajax 應用需要更多的自由來確定它自己的事件處理函數，而不是服務器事件模型看起來允許的那樣。盡管如此，在這些框架的背後還是有股相當大的動力。無疑，伴隨着Ajax 越來越流行，更多的這類解決方案還會浮現出來。5.5.3 節將要引入的命令隊列可能是向着JSF 及其類似框架發展的一種方法，雖然它並不是爲了這個目的設計的。目前從我的喜好來看，這些框架將客戶端綁的有點太緊了。
觀察這些框架如何在將來適應Ajax 是一件很有趣的事情。Sun 的內部和一些JSF 廠商對於提供支持Ajax 的工具集已經產生了巨大的興趣，.NET 表單已經可以支持一些類似於Ajax 的功能，並且承諾在即將來臨的Atlas 工具集中提供更多的支持（參見本章“資源”一節以獲得所有內容的URL）。
這也提出了一個問題：如果Web 框架專門爲Ajax 來設計，那麼它看起來應該是個什麼樣子？今天，這類框架還沒有出現，我們在這裏闡述的Web 框架終有一天會被認爲是這類框架的先驅。