struts2中一些零碎的边角知识

1、在Result中使用OGNL表达式

实际上除了在jsp里可以使用OGNL表达式之外，在Result的配置里也是支持的，这点在RedirectAction中尤其好用

<result type="redirectAction">
    <param name="actionName">anotherAction</param>
    <param name="param1">hardCodedValue</param>
    <param name="param2">${someValue}</param>
</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

这种设计思路，是值得借鉴的，我想可以参考这种思路，实现可插拔的插件