Struts1.X中ActionForm的争议
其实对于用Struts1.X进行开发过的人已经知道:ActionForm是Struts1.X中争议最大的一部分
ActionForm本身是一个抽象类,若想将客户端提交的信息自动变成对象赋予到Java类中
就必须提供一个自定义类,让它继承ActionForm,并提供相应的属性,然后自动set和get
该Formbean总是与我们自定义的JavaBean有些重复,所以它是受到最大争议的一部分
在Struts2中就取消了ActionForm,它直接用一个Action来实现ActionForm的功能
客户端提交的信息,如uname,它会自动调用Action的setUname()赋值到uname属性中
Struts2中Action类的简述
在Struts1中,若我们自己建一个Action的话,就一定要继承Struts1.X中提供的Action方可
在Struts2中,它的Action就完全是一个POJO类,是类似于JavaBean的一个类
它不需要依赖于Struts2的任何类文件,也不依赖于Servlet的API,它是很独立的一个文件
它是个非常干净的POJO,它将由Struts2自动调用,完成对客户端提交的信息的自动赋值
然后,在页面中取值的时候,也会自动调用Action中的getXxx()方法
Struts2和Struts1.X中Action的不同
Struts1.X就只有一个Action,它是单例的,因此它里面不能放置存储状态性的东西
Struts2在默认情况下,每发送过来一次请求,它都会生成一个Action实例
因此Struts2的请求之间是独立的互不干扰的,因此它是线程安全的
我们可以在Action中写一个构造方法,然后在构造方法的方法体中输出一个句话
接着到页面中提交几次请求,随后在控制台查看输出,即可测试它是否为每个请求都产生一个实例
Struts2中的ActionSupport
当Struts2的Action继承ActionSupport后,就可以直接使用Struts2提供的一些内置功能
在大多数的项目开发中,实际上也是直接继承ActionSupport类,来方便程序的编写
ActionSupport类中提供的validate()方法,可以用来判断值是否为空,或长度范围等等
validate()适合简单的验证,而不适合处理含有业务逻辑的判断
当客户端信息发送到Acton中后,首先会执行validate()方法,接下来才是执行execute()方法
通过查看源码可知:ActionSupport类中的validate()方法的方法体为空
也就是说,如果不重写validate()方法,那么validate()也会执行,但是什么都不会做
ActionSupport类中提供的addFieldError()方法,可以对指定字段增加一个向用户提示的错误信息
它的原形是这样的public void addFieldError(String fieldName, String errorMessage)
第一个参数是页面中表单里的输入域的name值,如<input>或者<s:textfield/>等等
第二个参数是提示信息。该提示信息显示在第一个参数所对应的字段的正上方居中位置
这里实际就可以完成一个国际化处理,即把errorMessage真正内容写在一个properties文件中
然后只需要在errorMessage的位置指定它在国际化资源文件中的key即可
通过查看源码可知:如果将错误消息添加到FieldError中,实际上是添加到了一个Map中
这个Map的key就是属性的名字,它的value就是增加的错误消息,这是它的底层的实现方式
使用<param />节点为Struts2中的Action的属性注值
Struts2中的ForwardAction简单示例
Struts2中的DefaultAction简单示例