自從年Apache Struts出現以來它在大多數的標准下都運行良好幫助開發出了許許多多基於Java的Web應用程序Struts是利用服務器端生成的HTML和客戶端驗證的Javascript的完美結合使開發和維護變得更加容易隨著時間的推移用戶對Web應用程序的要求不斷增加Struts 幾乎還滯留於原地給Web開發者留下了越來越多無趣的銜接代碼如何才能建立一個完美的框架結合體呢？
Struts的前世今生
在JavaOne 大會上一些Struts的開發者們與Rich Feit（Apache蜂巢計劃的提交者）還有一些Struts的用戶共聚一堂討論Struts的未來與會者提出了Struts Ti的項目它描述了這樣一個框架能夠集眾家所長重新組合成一個堪稱完美的框架可是Struts本身的問題出現了Struts 的代碼庫不適合大幅度的改進而它本身的特性設置也相當有限缺乏了像Ajax的快速和可擴展性
同樣在JavaOne會上筆者還與Webwork的核心架構師Jason Carreira討論了關於OpenSymphony WebWork 的項目探討我們如何能更好地協同工作對於在XWork上進行開發筆者還是十分感興趣的特別是它們核心的命令模式框架但Jason Carreira建議筆者直接在WebWork 上進行開發當我和Rich使用了最初幾個Struts Ti的版本後我們決定采納Jason的建議
我們認為Struts應該滿足高級應用程序的需求並且在WebWork 框架中的開發經歷也證明了這點Rich和筆者大多數時間都與一位WebWork 的高級開發者Patrick Lightbody一起工作在這段時期內Patrick和Spring WebFlow項目的創建者Keith Donald從各個角度考慮了關於一個全新的Web框架的構想希望能將它們結合在一起也就是將Keith的Spring WebFlow和Ted Husted與筆者的Struts以及Patrick和Jason的WebWork與Rich的Beehive結合在一起探討了將這些平台結合到一個框架中的可能性
不幸的是細節方面的困難出現了Beehive和WebFlow無法將其壓縮和轉換方面的特性進一步融合同時還有項目的所有者商標以及身份等問題不久這個團隊就解散了
我們不想就這樣解散筆者和Ted（Apache軟件基金會的成員）開始與Patrick（WebWork 的高級開發者）和Jason（Webwork核心架構師）探討如何能讓我們更好地合作Ted產生了Struts與WebWork合並的想法
由於Struts Ti還是基於WebWork設計的那麼將WebWork的代碼轉向Struts項目並不是件難事我們在一月開始了關於WebWork 的Apache Incubator進程並完成了WebWork 代碼
Struts 的由來
同時Struts本身也在為項目的核心識別進行了激烈的競爭到底它是不是多重Web框架Struts包括了Apache Shale它是一個包含了JSF的Web框架作為一個Struts的子項目有著Struts Action （現在稱之為Struts ）與Struts Action （完成了的WebWork 代碼）的一些特征不幸的是這些子項目讓開發者們有些混淆不清他們都用一個單一框架表示Struts
在嘗試將Struts Action 與Shale的子項目結合到一個單獨的Struts 之後Shale的開發者意識到如果這些能成為他們以後工程中的開發框架也是不錯的選擇Struts Action 很快就更名為簡潔的Struts
如今Apache Struts項目已經有它的框架的兩個主要版本但它仍是一個基於Action的框架項目並且WebWork仍然在定期發布程序補丁直到Struts 達到GA或是最終穩定但所有新的開發卻都是使用Struts 代碼
由此看來想要在Struts與WebWork的合並中尋找什麼奇跡是不可能的還是另尋途徑更好但是我們不會放棄當初Struts Ti的構想為將來做出一個集眾家所長的完美框架而努力
From:http://tw.wingwit.com/Article/program/Java/ky/201311/27957.html
