1、在Result中使用OGNL表達式
實際上除了在jsp裏可以使用OGNL表達式之外，在Result的配置裏也是支持的，這點在RedirectAction中尤其好用
Xml代碼
1. <result type="redirectAction">
2. <param name="actionName">anotherAction</param>
3. <param name="param1">hardCodedValue</param>
4. <param name="param2">${someValue}</param>
5. </result>
上面的param1和param2會成爲請求的參數，其中param1是硬編碼的，而param2是從ValueStack中取出的值
2、在properties文件中使用OGNL表達式
比如在resource.properties中，有一個greeting.word = hello ${user.name}
然後在jsp頁面使用標籤<s:text name="greeting.word" />
3、關於struts2驗證框架的流程
struts2裏的校驗，實際上是由幾個攔截器，和幾個接口共同完成的
如果Action繼承自ActionSupport類，那麼就實現了Validateable接口和ValidationAware接口，提供了validate()方法、hasError()方法，以及一組添加錯誤信息的方法（最常用的是addFieldError()方法）
默認包的攔截器棧有一部分是這樣的：
params-->conversionError-->validation-->workflow
首先params攔截器和conversionError攔截器先起作用，把HTTP請求參數放入ValueStack中，如果有錯誤，會調用ValidationAware接口的添加錯誤的方法（其中一個是addFieldError）
然後到了validation攔截器，它會執行驗證框架，如果有錯誤，也調用ValidationAware上的方法
最後到了workflow攔截器，第一個階段它會判斷Action是否實現了Validateable接口，如果是的話，則調用validate()方法，如果有錯誤，就調用ValidationAware的方法。然後第二階段，它會調用hasError()方法，看看是否有錯誤，如果有的話，返回INPUT
所以，實際上可以同時使用struts2的校驗框架，和Action上的validate()方法。對於workflow攔截器第二階段的工作（檢查錯誤）來說，它並不清楚，錯誤來自於哪裏，是來自於校驗框架，還是來自validate()方法，對workflow攔截器來說沒有區別，只要有錯誤，就返回INPUT
4、關於i18n
使用國際化資源文件，標準的做法是<s:text name="homepage.greeting" />，這裏假設資源文件裏有一個key是homepage.greeting
如果不想用<s:text>標籤的話，應該怎麼辦呢？實際上，<s:text>標籤調用的是TextProvider接口的getText()方法
而ActionSupport實現了TextProvider接口，所以如果Action是繼承自ActionSupport，那麼它也就實現了TextProvider接口。同時，Action對象會被放入值棧，所以用OGNL表達式，是可以直接取到資源文件中的國際化文本的，方法是
${getText("homepage.greeting")}
以上這句OGNL表達式，效果相當於<s:text name="homepage.greeting" />
5、struts2插件加載體現的一種設計思路
struts2加載配置是遵循如下順序：
struts-default.xml->struts-plugin.xml-->struts.xml
其中，struts-default是框架默認提供的，struts.plugin是插件提供的，struts是用戶自定義的
struts2框架啓動時，會收集以上所有配置文件，然後進行聚合彙總，得到一個總體的配置信息
這種思路很常見，比如MAVEN，也是首先提供了一個超級POM，和項目自定義POM進行聚合
CSS也是這樣，首先瀏覽器有一個默認CSS（這也是一個控件爲什麼在各瀏覽器顯示不一致的原因之一，更根本的原因是瀏覽器對CSS的實現本身就不一致），然後開發者定義的CSS也有層級關係。瀏覽器將所有CSS彙總之後，計算出一個元素的最終CSS
這種設計思路，是值得借鑑的，我想可以參考這種思路，實現可插拔的插件