利用ActionMapping的命令模式<o:p></o:p>
Struts提供一個公開的基於XML語句的方法來說明請求URI中servlet路徑與適當的請求處理器之間的映射。這個實現與命令模式[Gof]很相似。以下片斷摘自struts-config.xml文件，下列聲明用於建立ActionMapping配置對象，它是<action>元素的運行時表現。<o:p></o:p>
<action-mappings><o:p></o:p>
<action path="/editCustomerProfile"<o:p></o:p>
type="packageName.EditCustomerProfileAction"<o:p></o:p>
name="customerProfileForm"<o:p></o:p>
scope="request"/><o:p></o:p>
</action-mappings><o:p></o:p>
以下簡要說明上述聲明中用到的屬性。<o:p></o:p>
path：HTTP請求中虛擬目錄的相對路徑，用於識別這個動作映射。<o:p></o:p>
type：類名，將用於在處理這個請求的時候建立一個請求處理器實例。<o:p></o:p>
name：JavaBean的邏輯名稱，也叫做表單bean，將用於保存表單數據。表單bean將用這個名稱保存在指定的範圍（scope）中。<o:p></o:p>
scope：保存bean時用請求或會話範圍。<o:p></o:p>
上例中Path屬性映射到HTML文件中<form>元素的action屬性。在上面範例中避免了硬代碼映射到代碼內部而且可以方便的看到HTML表單中的servlet路徑如何映射到請求處理器的實例。另外，應用系統行爲和導航語義可以方便的通過修改動作映射來完成。請求處理器是Struts提供的Action類的子類。<o:p></o:p>
對於HTML<form>標籤，使用自定義的org.apache.struts.taglib.html.FormTag爲action屬性動態生成動態URL可以保護HTML文檔避免修改虛擬目錄或<url-pattern>時的大量變動。對於*.do模式的URL，下面的自定義FormTag <html:form action="/editCustomerProfile?customerType=preferred"> 將使用action屬性包含的如下服務器相關URL動態生成一個HTML <form>標籤：<form action="/contextPath/editCustomerProfile.do?customerType=preferred"/><o:p></o:p>
使用name屬性，行爲映射可以聲明一個特定的JavaBean ，其特性將保存來自HTTP請求的參數，該JavaBean是ActionFrom類的子類。行爲映射聲明中的name屬性是在特定範圍內使用哪個ActionForm類的實例保存的唯一標示。ActionForm子類使用<form-beans>標籤聲明於struts-config.xml文件中，如下：<o:p></o:p>
<form-bean name="customerProfileForm" type="packageName.customerProfileForm"/><o:p></o:p>
參閱“獲取表單數據”章節以得到關於<form-beans>元素和ActionForm類的更多信息。<o:p></o:p>
<o:p> </o:p>
模型與請求處理器的相互作用<o:p></o:p>
Action的一個子類是用於作爲提交的請求和模型之間的適配器。Action子類，也叫做請求處理器，是爲每個請求特別建立的。一個動作最初被RequestProcessor解釋，然後輪流實例化一個相應的請求處理器。這個Action類的對象爲每個請求特別建立，已經在前面章節中的發送者闡述。請求處理器實現了命令模式[Gof]。一個終端請求在請求URL中封裝了欲執行的行爲即servlet路徑，該路經信息隨後被髮送者（RequestProcessor）提取以建立一個相應的請求處理器實例。命令模式消除了用戶界面（UI）對請求處理器的影響。<o:p></o:p>
基本的Action類提供訪問架構相關資源的常用函數以及保存使用其子類的execute(…)方法而產生的錯誤的方法。該錯誤隨即通過採用定製的org.apache.struts.taglib.html.ErrorsTag，被獲取並顯示到HTML表單。請求處理器的execute(…)方法應該包含處理請求參數和相關ActionForm的控制流程，它應該封裝模型相關語義，並且應該在模型操作結果的基礎上提供下一個視圖。請求處理器在第一次建立後就被RequestProcessor捕獲，隨即被設爲對其他的提交請求可用；同樣的，請求處理器必須不含有用戶特定的狀態信息；請求處理器也必須同步化訪問需要串行訪問的資源。對於一個分佈式應用，動作類包括與EJB組件中的事務邏輯相關聯的控制邏輯且一般採用Business Delegate[Core]對象來實現該目的。事務委託保護請求處理器免於處理訪問分佈式組件的複雜度。因爲訪問服務器端組件的邏輯被嵌入到事務委託中，事務委託設計模式促進了請求處理器與服務器端組件的鬆散耦合。請求處理器由表示層工作的開發者編寫，然而事務委託常常由負責建立事務層服務的開發者編寫。對於小型非分佈式應用，動作類或許包含事務邏輯。當分佈式處理不是必需的且事務邏輯被嵌入在請求處理器中時，Data Access Object [Core]可以用於抽象潛在的數據訪問實現，它爲請求處理器與數據訪問層提供了鬆散的耦合，從而保護表示層避免在整合層中改變實現。請求處理器基本的Action類提供部分方便的方法，請查閱API文檔位於：http://jakarta.apache.org/struts/api/index.html。<o:p></o:p>
（待續...）
<o:p>冰雲翻譯，轉載請告知。</o:p>
<o:p>[email protected]</o:p>