服务器端的校验有两种,一种是重写ActionSupport的validate方法,另外一种是使用xwork验证框架(网上一般都直接说struts验证框架)。其中后者比较简单(通过xml配置验证条件),适合大多数情况下使用。今天,我们就来做个简单的例子。废话不多说,步骤如下:
1. 新建一个Web项目,名为StrutsValidatorDemo。在index.jsp中创建我们要验证的输入框以及“确定”按钮,代码就不贴了。其中,输入框name为username,表单的action填什么后面我会说。
index.jsp
2. 由于要使用Struts框架,所以加入外部jar包,网上说搭建Struts需要六个jar包,但是实际我做的时候发现不止,反正具体情况自己看log吧。
所需jar包
3. 配置web.xml文件。我们就用传统的流行的方法配置,不解释。
web.xml
4. 创建一个UsernameAction类来处理username的提交,这里就不用MVC了,很简单的代码。具体代码如下:
UsernameAction.java
我们让UsernameAction类继承了ActionSupport这个类(虽然这不是必须的,但这样做你可以享受到ActionSupport这个父亲的“存款”,何乐而不为呢)。鉴于Struts2中可以自定义请求调用方法(只要返回类型为String),因此这里我们不用execute方法(虽然使用execute方法可以一定程度上偷懒)。
注意点:一定不要忘了定义属性的get方法,因为xwork验证框架会调用到它,如果你偷懒的话,会付出很多找错的代价。我就因为这个问题找了半天才找到。
5. 配置struts.xml文件
首先,它存放的部位一定要正确,默认是在/WEB-INF/classes里面加载的,也就是说你得把它放在src下。
struts.xml
在struts.xml中,我们配置了一个名为usernameAction的Action,它的method属性为submit,就是说如果我们在前台表单中这个设置action=“usernameAction.action”,默认会调用usernameAction的submit方法。当然你也可以以这样的方式指定action=“usernameAction!submit.action”。
这里,我们老老实实把index.jsp中form的action属性写为“usernameAction!submit.action”,这样做清晰明了无歧义,有助于促进社会和谐发展,为什么不呢。
6. 接下来就是校验xml文件的书写了。
我们的Action类名叫UsernameAction,所以校验xml文件名必须叫UsernameActionValidation(这是校验框架的规定,不鸟它你就别用它)。
UsernameAction-validation.xml
如上所示,我们为username创建了校验规则(顺带说一下,struts校验框架有两种方式,字段校验和非字段校验,以field和validator标签来进行区分。这里用的是字段校验,也是极力推荐的方式)。这个xml中的各个标签,我们可以在dtd中看到。怎么看xwork-validator-1.0.2.dtd?点开xwork-core-2.2.3.jar这个jar包,就可以看到xwork2.2.3的目录结构,其中有各种dtd的定义。打开xwork-validator-1.0.2.dtd,你甚至可以看到使用这个dtd的DOCTYPE的定义。
<field name="username">的意思就是对username进行校验,这个username必须是对应action类的一个字段。而每一段<field-validator type="…">则是对username的一个验证,如上述xml所示,对username这个字段我们创建了三个验证,第一个是验证是否为空,第二个验证是否长度是6~10之间,第三个验证是否只包含字母,数字和下划线。应该说结构很清晰,内容很明显。<message>里面存放如果验证不通过要显示的错误信息,它最终被添加到fielderror中,而它应该是一个键值对的映射,下面是接口ValidationAware的一段代码。
也许你会说这个xml中的type和param name我都不知道啊!在哪可以找呢。那么我可以告诉你一种方法。同样点开xwork-core-2.2.3.jar这个jar包,再点开com.opensymphony.xwork2.validator.validators,这里存放了xwork给我们提供的验证类。打开default.xml这个文件,我们可以很惊讶的发现,原来这里配置了xwork提供的验证类的映射,就跟我们配置的struts相似。下面展示这个文件的一部分代码:
xwork-core-2.2.3.jar/com.opensymphony.xwork2.validator.validators/default.xml
<validator name="stringlength" class="com.opensymphony.xwork2.validator.validators.StringLengthFieldValidator"/>
<validator name="regex" class="com.opensymphony.xwork2.validator.validators.RegexFieldValidator"/>
看到没,我们写的validation.xml中的type就对应了上面的name,而这个name决定了验证框架会调用哪个类来实现验证。好,我们现在就看看stringlength这个那么所对应的类,揪出来看一看瞧一瞧。
xwork-core-2.2.3.jar/com.opensymphony.xwork2.validator.validators/StringLengthFieldValidator.java
从这段代码可以很easy的看出我们设置的param name就是这里的字段。。。吗?不是的,而是set方法中的参数名。我再把长度验证的代码贴出来,我们仔细研究一下下,
<field-validator type="stringlength">
<param name="minLength">6</param>
<param name="maxLength">10</param>
<param name="trim">true</param>
<message>the length of username should be between ${minLength} and ${maxLength}</message>
</field-validator>
由于代码中doTrim字段是private的,所以外部不能访问,要通过set来访问,但是set方法中形参名为trim,所以param 的name我们应该写成trim而不是doTrim,否则就出错了。当然对于偷懒的人可以发现doTrim这个字段默认是true,也就是说<param name="trim">true</param>这一行可以不用写。看validate这个方法就知道这段代码的作用了,那就是验证字符串长度嘛,而doTrim这个字段是用来决定是不是先把字符串给“剃头”的,这个字段肯定是要设为true的,不然长度验证就没有意义了,举个很简单的例子,如果doTrim为false,要验证的长度是6~9,那么输入六到九个空格都是正确的(只不过累了点)。
好了,浪费了这么多口水,对于validation这个xml大家应该有所了解了吧!
7. 一切似乎准备就绪,那么我宣布激动人心的时刻到来了(别激动的太早,我想说的是你的项目部署了吗?),然后闭上你的眼睛,启动你家的汤姆猫(首先要确保它身体健康无错误),然后在浏览器的url栏中输入已经烂在脑海中的地址http://localhost:8080/外加StrutsValidatorDemo。
8. 然后一个华丽风骚的页面出现了,哈哈。
下面对它进行考查,方案有四种:
一号作战方案:直接submit
二号作战方案:分别输入‘aa’和‘aaaaaabbbbbb’,点击submit
三号作战方案:输入‘aaa!aaa’,点击submit
四号作战方案:输入‘_a_a_a_a’,点击submit
五号作战方案:输入‘中文弄死你’,点击submit
六号作战方案:残忍点,在url中直接输入http://localhost:8080/StrutsValidatorDemo/usernameAction!submit.action?username=(上述各种情况)。这也是xwork验证框架作为一款服务器端验证框架的关键作用。
结论:经过一系列作战方案,都达到了我们预期的目标,即搭建的验证框架起作用了,也是正确的。