摘要 把你的現有struts應用程序移植到stripes框架能夠簡化，并且這一移植過程要比你想象的更為容易。

　　一、 引言

　　把一個現有java web應用程序移植到一種新框架可能不是大多數開發者最感興趣的問題。除了要花費時間學習一種新的web框架外，例如標簽、國際化系統和校驗等繁重的轉化過程可能會迫使每一位程序員考慮再三。我最近就面臨這樣的一個挑戰-從struts進行移植。

　　在決定移植一個應用程序前，應該首先問一下"為何不使用現在的框架？"在我看來，struts是一種穩定的具有良好文檔的框架，并且有一大批開發者社區成員，但是其配置很麻煩，而且其表單、行為、應用程序流和校驗的分離有時會帶來很多麻煩。這種情形在我的struts應用程序不斷變大時越發糟糕。最后，純粹從一種維護的角度，我決定把它移植到一種新的框架。

　　開始，我認為沒有一種框架(java serverfaces，tapestry，webworks，spring mvc)值得從struts遷移向其遷移。例如jsf這樣的框架看上去極不友好。其它的，例如tapestry和webworks，涉及到整頁整頁的看上去令人麻煩的國際化系統。而從配置角度來看，spring mvc看上去并不比struts好多少。我選擇的框架應該僅需適當的學習時間，還要與移植效益相稱；而且，它還一定要使我編碼、排錯與維護更為容易。

　　二、 發現stripes框架

　　后來，我偶然發現了stripes框架。就象java社區中的許多發燒友一樣，我一直追隨著ruby on rails（ror）現象。依我看來，stripes是最接近于ror哲學的java mvc框架-簡單，漂亮，并且要求最小的配置。除了它的簡潔外，象我這樣一位struts程序員，stripes非常適合我的口味。應用程序流和許多命名慣例都與之十分相似。stripes中的actionbeans就象strut的actions，而forwardresolutions極象actionforwards。因此，使用這一框架，我不必拋棄我所有以前的struts知識。

　　另外吸引我的是stripes文檔。象框架本身一樣，文檔也是干凈、清潔而簡練。其標簽庫文檔和api都具有良好的歸檔，而且該框架的每一種特征幾乎都有相應的示例源碼。這些優秀的文檔再加上我的現有struts知識使我堅信，我可以快速地掌握這種stripes框架。

　　值得注意的是，stripes還包括另外一些使其成為一種良好的ajax平臺的特征，例如它提供了一種流式方案，該方案允許對ajax實現進行改進的錯誤處理。然而，對于我來說，最終的決定因素還是我能夠清楚地看到它會使我的生活更容易些。我估計，在我的應用程序的行為/配置/校驗部分，我只需使用約一半的代碼就夠了。更少的代碼意味著了更少的錯誤、更快的開發時間和更容易的糾錯。

　　三、 移植過程

　　我從視圖層開始移植，然后再向行為層移植。事實上，我也沒有很明確的邏輯思路；只是必須從某處開始，而視圖部分看起來更適合于作為一個起始點。

　　(一) javaserver pages

　　就象struts一樣，stripes使用jsp來實現其視圖層。我吃驚地發現，stripes標簽庫非常類似于struts的html taglib。事實上，我能夠使用這種統一替換方式來升級我的許多標簽。

　　stripes依賴于jstl實現jsp視圖中的邏輯。我在我的應用程序中混合使用了struts邏輯標簽和jstl。通過把我的所有邏輯標簽移植到jstl，我能夠利用jstl的優越的if/else和case語句的能力處理，它們可能是很原始的或者根本不存在于struts邏輯taglib中。

　　(二) 國際化

　　接下來，我要移植我的struts的消息資源。在配置端，所有要求的操作就是重命名我的struts消息資源文件。在我的jsp中，我能夠使用統一替換方式把我的所有struts message標簽(例如，＜bean:message key="buttons.save"/＞)替換為jstl格式標簽(例如，＜fmt:message key="buttons.save"/＞)。這種jstl格式標簽還支持可用于struts中的消息資源綁定。

　　(三) 表單

　　我的移植的最有意義的部分是去掉了我的struts action表單，這是在action類中進行的，要求大量的xml標記和冗長的轉換，如下例所示：