隨筆檔案

作者：施偉，原文出處： http://www.aygfsteel.com/crespo9907/archive/2007/03/10/webworkinaction_note3.html，轉載請保留。

??????在上一篇筆記WebWork In Action學習筆記(二) WebWork方式的HelloWorld 中我們已經學會了如何構建一個簡單的WebWork應用程序，除了創建幾個簡單的Java和Jsp程序外還配置了web.xml和xwork.xml。本篇我們就來繼續討論都是在xwork.xml中配置的action、result和interceptor三個極其重要的部分。正是它們實現了WebWork中優雅的MVC，result更是支持多種表現方式讓開發Viewer變得更加容易，而interceptor則讓WebWork變得異常強大并具有魔法。下面我們就開始吧！

??????一、action? 絕對的核心

??????在實際應用中不出意外action總是一個擴展com.opensymphony.xwork.ActionSupport的Java類，或者說總是會繼承ActionSupport（直接或間接）。我們在上篇筆記的HelloWorld程序中就可以知道WebWork的通過Servlet-Dispatcher（新版本已經更改為過濾器實現）接收道Http請求后分析特定的URL形式后調用action。如/hello.action樣式的URL請求就調用了HelloWorld類的execute()方法。

??????配置一個action需要的最少信息是action名和對應的action類。當它們添加到xwork.xml文件中時，就建立了一個action的映射。還是列出一個最簡潔的例子：將action名login映射到Login類。
??????
??????上面的代碼中action標簽是自封閉的，你肯定會想這有什么用啊？確實，除了象使用<ww:action/>標簽這種極少數的情況下，沒有result信息的action是沒有什么實際作用的。幸運的是WebWork內置了幾乎所有常用的result類型，當然你也可以建立自定義的result類型（在后面的筆記會詳細介紹）。我們現在就來為上面的配置添加result吧，讓它成為一個真正能在實際中使用的action。


??????比較上面兩個例子有兩個重要的變化：引入了webwork-default.xml以及加入了兩個result節點。每個result都有一個名字、一個可選的類型和一個具體的值。當沒有指定類型時就會使用package或者superpackage的默認result類型。在這種情況下就是webwork-default.xml文件中定義的dispatcher（分發器）。

??????在上面的例子中，如果返回的result code是success那么用戶就會被重定向到/secure/dashboard.action（這是另外一個action，現在暫時還沒有定義，我們先不管它）。如果返回為input瀏覽器會在此顯示login.jsp，并且用戶剛才輸入的信息還在，因為此時的類型為默認的分發器，action會把參數值繼續傳遞給login.jsp。注意result映射可以是絕對路徑也可以是相對路徑。在討論namespace概念的時候，這個會很重要。

??????下面我們來討論一下為action提供別名。在配置中每一個action節點就是一個action映射，但是也可以將多個名字映射到相同的action類。WebWork是一個實現了泛化command模式的框架。在默認情況下，WebWork調用action類的execute()方法。但是你也可以通過在action映射中增加一個可選的method屬性，指定WebWork應該調用哪個方法。不過所指定的方法必須和execute()方法具有相同的“形狀”，即沒有輸入參數，返回一個String類型的result code并且有選擇的拋出異常。下面給出一個例子：

???
??????三個action均是關聯到UserAction類，第一個執行默認的execute()方法，而后兩個則執行edit()方法。（注：WebWork通過xwork.xml映射到方法有兩種機制：通過查找與method屬性值一致的方法；通過查找doMethod()形式的方法。這是為了兼容舊版本的一些做法，因為有些詞是Java關鍵字不能作為方法名，如default。這個時候就把方法名寫為doDefault，method值為default同樣可以工作。不過上次看Struts的文檔發現WebWork2遷移到Struts2后取消了這種機制，所以建議大家最好不要使用。）還有一個小技巧請大家注意：后兩個action映射的方法都是一樣，但是配置了兩組不同的result，這也是action別名的好處之一。

??????WebWork還有一種很方便的不需要配置的別名語法，支持形為name!method.action的映射。如上面的例子中，users!edit.action就會被映射到edit()方法中。在Struts2中可以通過設置打開或者關閉這種語法。

??????附Struts2相關資源：
????? WebWork2與Struts2的一些區別???http://struts.apache.org/2.x/docs/key-changes-from-webwork-2.html
??????WebWork2如何遷移到Struts2?? http://struts.apache.org/2.x/docs/webwork-2-migration-strategies.html

??????我們還可以通過使用<param>標簽來實現action的參數化，從而自定義action。舉個例子就很好理解了：假如已經寫好了一個處理Web Service請求的action，現在你可能需要將action的不同實例綁定到不同的URL，你也可能為每個action建立一個獨立的timeout值。使用<param>標簽你就可以使用同一個WebServiceAction類來實現你的想法。



??????當action執行時，WebWork會自動根據action映射中指定的值調用相應的setter方法來設置這些參數值。當然這些都是借助與interceptor的魔力。眼尖的人可能發現了一個問題，那就是我們在<param>中配置的可以看作都是字符串，而這里的timeout為long類型，還能正常工作嗎？回答是可以的，這借助了WebWork值得炫耀的自動類型轉換功能，因為來自于外界的輸入參數其實都是字符串形的，而在Java對象內部會有各種各樣復雜程度不一的類型，它們之間的轉換均交由WebWork的自動類型轉換功能來處理，是多么的方便啊！這不也就是我們平時編程中最容易出錯、最煩人和最耗時的工作嗎？這么重要的功能我們當然會在后面專門的一篇中來講述，在這里暫且按下不表。

??????現在你至少應該知道action映射是如何配置了吧，下面我們就開始研究result映射和result類型吧。

??????二、result? 我們怎么顯示呢？

??????在WebWork應用程序中主要要配置兩類與result相關的東西，一個是result類型，一個就是在上面的例子中反復出現的action的result。

??????首先我們來看看如何配置result類型。其實在webwork-default.xml中就配置了很多默認的result類型，一般情況下這些就已經足夠了，當然你也可以配置自己的result類型，和默認的配置方式是一致的。我們來看兩個使用最多的result類型。


??????result-types都是被包含在package中的，作為此package的類型設置，子package可以繼承父package的result-types。因為這里關注的是如何配置result類型，所以class用...來代替。第一個result-typ比第二個多處了default="true"，這個表示此result類型被設置為默認的，當action中配置的result不指定type屬性時就應用此默認result-types。

??????講一個關于result很重要的技巧，運用全局的result映射可以減少重復的配置。告訴你一個最簡單的方法，你沒必要在一開始就想辦法應用此技巧，套用一個很流行的詞匯這叫“過度設計”（當然很明顯的例外），而是當你配置完action如果發現同一個package中多個action配置了同樣的result時，你就可以應用這個技巧。下面我們來看個典型的例子。


??????定義了login和unauthorized，一個對應登錄頁面而另一個對應沒有管理員權限時用戶被“丟去”的地方。顯然這兩種情況是常用的，定義為全局正好合適，省去了很多重復的配置，也顯得更加清晰。

??????在定義全局result的時候最好使用絕對路徑，因為作為全局配置你現在并不能夠確定它在什么context中被調用。所以使用絕對路徑一勞永逸。

??????三、interceptor?? WW城中的大魔法師

??????在決定性的攻城戰中大魔法師可不是隨意使用的，interceptor正是WebWork全面超越其他MVC框架的秘密武器！

??????interceptor是在圍繞action及result的執行過程中釋放魔力的，然而在日常開發新的action的過程中，我們并不需要直接使用它們。典型的做法是創建一組或者一個堆棧的interceptor，并且在全局范圍內將它們應用到action中。就像大魔法師的群療術一樣，一旦釋放全屏補血。

??????在實際開發過程中，一個package可能包含一組interceptor。用一個<interceptors>節點來包含若干個<interceptor>來實現。


??????配置好interceptors后就可以應用到action中了。


??????這個時候當login這個action被調用的時候timer和logger這兩個interceptor也會相應的被調用來施放魔法。我們想象一下如果某個action需要配置一百個interceptor那我們豈不是要在action中寫一百個interceptor這樣的東西，如果你是一個正常的程序員你肯定會瘋掉的。不過還好我們的大魔法師魔力無邊，提供了interceptor-stack這樣的一個東西來一系列的interceptor組合在一起形成一個stack，從而用stack來代替多個獨立的interceptor，這個時候action就不需要做那么傻的事情了。


??????可以看到action在引用一個獨立的interceptor和包含多個interceptor的stack時都是使用interceptor-ref，并不會區別對待，這就使得一個interceptor stack又可以同時包含獨立的interceptor和另外的interceptor stack。

??????是不是非常的靈活，也節省大量的重復代碼。WebWork盡量讓代碼量減少，不重復一句。這也是我們希望看到的，也是我們選擇使用框架的原因。并不是有了框架就能夠去除多變的需求，就能夠編碼如飛；框架僅僅是告訴我們什么不可以做，什么可以做，怎么樣做最好。下面讓我們繼續減少重復配置和代碼。

??????前面的result應用全局的概念來減少配置的方法應該還記得吧，intercetpro同樣也可以。（在coding的時候我們應該把多處的重復匯集到一起，從而減少重復；而在thinking的時候我們應該把一種思維和方法應用到多處去，從而提高質量）我們可以為每一個package建立一個默認的interceptor-ref。


????? 這個時候package中的所有沒有定義interceptor-ref的action都會應用此default-interceptor-ref指定的interceptor。并且一般情況下定義在同一包內的action都會應用相同的interceptor，所以這樣可以節約很多配置和代碼。不過需要注意的是只有沒有定義interceptor-ref的action才會應用這個默認配置，當為action指定了interceptor-ref時，此action只會應用這個interceptor-ref，而不是在default-interceptor-ref的基礎上加上自己定義的interceptor。

??????在后面的筆記中我們還會分別詳細的介紹這三個WebWork中最重要的組成部分，本來打算把webwork.properties的相關配置記一下，好像也沒這個必要，再寫也就是把官方文檔的內容貼在這里，還是有問題就去看官方的文檔好。框架學習要養成多看文檔和API的好習慣，在一定的時候研讀源代碼也會對編程水平有非常大的提高而不僅僅在于使用這個框架了。

??????《WebWork in Action》這本書已經看完很久了，因為種種的原因筆記現在才補上。但在補寫筆記的時候發現了好多書中之前沒有注意到關鍵內容和對以前內容的一個重新理解和衍生。我想這就是所謂的“溫故而知新”吧。

??????下一篇筆記將重點講述WW城中的戰士－－action。不管哪一款網游中，戰士永遠是核心人物，最重要的部分，承擔著最多最重要的任務，并且直接面對敵人。告訴大家如何實現WebWork中的action，以及實現過程中的相關問題和技巧。