一
概貌
Wicket是基於web應用框架的高級組件
其主要特點
* 在HTML和java之間的明確分隔
* OO組件模式
* 自動狀態管理
* 高度生產化
* 低學習投入
* 屏蔽Servlet API
HTTP協議細節
* 無需XML配置文件
* 易於構造可重用組件
Struts是以Model
MVC 為藍本構建的web應用框架
其工作圍繞著處理HTTP請求的action類來完成
配置方式采用XML文件
下文將對Wicket和Struts在體系
HTTP請求處理
Servlet API和HTTP協議抽取
狀態管理
配置這六方面進行比較
二
比較第一方面
體系
Struts體系基於解釋每個HTTP請求並將其定向到某個處理該類型請求的指定Action類
每個Action類將處理後的結果返回
並決定下一步走向——通過轉發或者重定向到另一個Action或者將控制權交給輸出HTML的JSP頁面
從技術較大來講
雖然每個部分之間做到了很好的解耦
但是基於HTTP請求的處理模式可謂與時代不符（與wicket相比就是過時了）
兩大原因如下
* Struts並不是真正意義上的純粹面向對象
每個Action類定義了一個abstraction（抽取）
但是abstraction是由HTTP協議的請求機制決定的
而並非面向對象的分析
* 除非我們在java代碼中直接輸出HTML（當然除非我們瘋了）
那麼為了輸出HTML我們就要學習另外的主流技術
比如JSP和自定義tag
使用在JSP中使用tag並非易事
尤其是當我們把這項工作交給美工小組時
這會直接導致兩個結果
JSP代碼被他人作的一沓糊塗
或者是我們自己完成這項任務
而Wicket的處理方式則不同
從整體來講應該說是更加優雅些
它采用面向對象的組件技術實現web與用戶的交互（這點有些如Swing）
在Wicket中的每一頁是由若干的使用組合設計模板生成的組件構成
頁面和組件各自渲染自己
並直接或者間接的與markup文件（標識文件
形式就像JSP）關聯
當HTTP請求到來時
這些請求被轉換
傳遞到組件上的相應事件中來
這一點與微軟的VS很相象
所以Wicket能夠解決struts體系中存在的問題
* Wicket是完全面向對象的
我們可以利用組件的繼承性設計自己的應用
這裡不需要為處理HTTP協議的請求/響應而作任何工作
* Wicket所使用的markup文件與純粹的HTML很接近
所以容易上手使用
Wicket在markup文件中所引入的內容非常整潔
並符合XHTML標准
任何了解HTML的開發者都可以如編輯HTML文件那樣編輯Wicket的markup文件
就好似他並不知道這是Wicket的markup文件一樣
三
HTTP請求處理
在Struts中
一個HTTP請求被接收後
Struts將在配置文件中查找request path和相應的Action類
如果這些已經被配置好了
它將將提取請求參數放入到ActionForm bean中
並執行一些驗證
然後HTTP請求
回應和ActionForm對象都將作為參數傳入到Action類中
從這點可以看出Action的開發者掌握著應用的方方面面
他們必須處理HTTP session
維護HTTP請求和session的屬性
並在action執行完時建立需要返回的信息
最後還要返回相應的ActionForward以使struts知道下一步在哪裡
假如此時ActionForward將控制權交給了JSP頁面
開發者就要使用struts自定義的tag庫編寫JSP代碼
如此繁復的工作環節很容易出現錯誤
而且struts還需要三個位置保持一致
struts XML配置文件
java Action類
JSP自定義tag
而在Wicket中
一個HTTP請求被接收後
Wicket將確認HTTP所請求的那個頁面和在這個頁面關聯的組件
如果請求的目的是form
Wicket將自動提取請求參數
驗證參數
進行一些預先規定好的類型轉換
設置form組件中的model（模式
這裡用法與MVC中類似
但有不同）值
接著轉化請求為相應類型的事件
調用目標組件上的相應事件偵聽器
這樣就會導致事件處理代碼運行來執行業務邏輯
然後
事件處理器還將指定下一步頁面的位置
被指定的頁面將初始化（如果頁面從未被初始化的話）並自動渲染
渲染處理將按照順序訪問每個頁面組件
要求它們進行自我渲染
在markup文件中能夠組件僅通過名字與HTML元素進行映射
Wicket出色的原因
* 每個組件知道如何處理自己事件
因此我們只需要將組件放到頁面上
編寫事件處理器就行了
如果一個頁面中存在
個能引發事件的不同的組件
我們除了進行將它們添加到頁面上的工作外沒有別的工作
但如果在struts中
我們可能需要建立
個不同的Action類或者一個具有
個分支語句的Action類
並要在XML配置中逐一添加
* Wicket帶給了我們考慮組件/事件重用的機會
而不用將注意力放到如何處理HTTP請求和回應上
* 與struts相比使用Wicket會降低我們的代碼量
這正是重用組件帶來的益處
Wicket本身不使用任何的XML配置文件
只需要修改web容器的web
xml文件中的servlet聲明部分
假如我們曾經編寫過Windows API
並用過Visual Basic或者Borland Delphi的話
下面的比較會更加讓人印象深刻
使用struts開發就像使用Windows API一樣
接收原始消息
解碼原始消息
然後再處理這些消息
由於Windows API是基於消息循環工作的
所以系統除了消息回應外不期望任何的返回值
從另一方面看
Dephi在TApplication類中隱藏了Windows消息循環
使開發人員圍繞著TApplication類建立其他的類
原始的系統消息就這樣被Dephi內建類接收
被內建類解析並被確定其接納者
消息被轉換為一個事件
並被傳送到某個特定的對象
如Windows應用程序一樣
Wicket應用也具有服務於文本和HTML模板的資源文件
從這點看
Wicket象用Delphi做桌面開發一樣被用來做web開發
四
Servlet API和HTTP協議的抽取
Struts沒有隱藏Servlet API和HTTP協議的細節
為了使用Struts
我們必須樂於和HTTPServletRequest
HttpServletResponse 和HttpSession類打交道
並圍繞著請求和回應建立應用
這便是所有Model
MVC wen框架與生俱來的弱點
正如上面說的
Wicket隱藏了Servlet API和HTTP協議的細節
對於一些應用
我們甚至觸及不到這些細節
甚至對於非常復雜的應用
我們也僅使用適當的Wicket協議抽取類
而經常用到的是java組件類
POJO業務模型
純HTML標記文件
五
狀態管理
使用Struts開發
我們將獲得全部的狀態管理權
這對於建立大規模的
高升級空間的
集群應用來講是很好的
因為我們將獲得對HttpSession上每件事物的控制權
但是對於中小型應用
我們將沒有緣由編寫一些額外的代碼
這樣將導致應用變得復雜和編寫費時
在狀態管理上
Wicket可以作為一個不錯的選擇
Wicket框架默認代管所有的組件狀態
這對於中小型應用
在狀態管理上的代碼量幾乎為
但是Wicket也提供了一些API使我們進行標准狀態管理和實現自己的狀態管理
這樣
即使是大型應用
我們也能夠全權掌握狀態管理
事實上
即使在使用Wicket編寫大型應用時
通常也是先讓Wicket代管所有的狀態
然後再慢慢的實現自己定義的狀態管理以提高應用性能
六
配置
不言自明
Struts需要一個XML文件
定義對HTTP請求和響應的映射和所有的ActionForm對象等
這個文件可能非常大而且復雜
而新版本的Struts提供了將這個文件分解為多個模塊的方法
雖然這樣可以將模塊分類
但是這樣同樣要維護許多的小文件
Wicket不需要配置文件
Wicket通過一個簡單的應用配置類或者通過編寫web容器的web
xml文件中Servlet init參數來完成程序的初始化
而HTTP請求到組件事件的映射
組件如何輸出HTML等被包含在了Wicket的應用邏輯裡
從而極大地簡化了配置
七
Wicket
的RoadMap
* JavaScript support
* CSS support
* Markup inheritence
* Experimental AJAX support
* Improved URL handling
* Include of external markup
* Simplified Choice component
* Improved Feedback support
* Thread safe validation (bug fix)
* Immediate button support for Forms
* Panel support for TreeView
* Date picker component
* Component reference examples
* AJAX support
* Portlet support (JSR
)
* Clean and pretty URL
s
* JAAS/Acegi/other security integration
八
參考資料
/Newuserguide
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28524.html
