Struts2系列：（15）对于Validator接口的探究

Posted 2020-07-31

1在com.opensymphony.xwork2.validator包下定义了Validator接口。

public interface Validator<T> {
    //...
}

validator分为两大类：Plain Validators和FieldValidators。

The validators come in two different flavors:

a)Plain Validators / Non-Field validators
b)FieldValidators

这篇文章主要讨论Plain Validators和FieldValidators这两种validator的不同之处。

Plain Validators (such as the ExpressionValidator) perform validation checks that are not inherently tied to a single specified field. When you declare a plain Validator in your -validation.xml file you do not associate a "fieldname" attribute with it.(You should avoid using plain Validators within the syntax described below.)

Plain Validators与field没有联系。

FieldValidators (such as the EmailValidator) are designed to perform validation checks on a single field. They require that you specify a "fieldname" attribute in your -validation.xml file. There are two different (but equivalent) XML syntaxes you can use to declare FieldValidators (see " vs. syntax" below).

FieldValidators则一定是对某个field进行验证。

NOTE:Note that you do not declare what "flavor" of validator you are using in your -validation.xml file, you just declare the name of the validator to use and Struts will know whether it‘s a "plain Validator" or a "FieldValidator" by looking at the validation class that the validator‘s programmer chose to implement.

注意：不需要声明当前正在使用Plain Validations，还是FieldValidators，Struts会自动识别。

---

回顾：表单数据的验证分为前台javascript验证和后台验证。在Struts2中，实现后台验证的方法有两种方式：使用Java代码验证和使用XML文件验证。本文是针对XML验证的中的两种验证方式（Plain Validators和FieldValidators）进行学习。而Validator接口是Struts2中的实现验证的入口。

刚刚谈到这是XML验证的方式，那么无论是Plain Validators，还是FieldValidators，都会写在xml文件当中，这就引出一个问题，这个.xml文件该如何命名呢？

知道了.xml文件如何命名之后，就接着看看Plain Validators和FieldValidators之间的两个不同之处：语法、短路。

There are two places where the differences between the two validator flavors are important to keep in mind:
（1）when choosing the xml syntax used for declaring a validator (either or ) 
（2）when using the short-circuit capability

本文结构：

1、验证的xml文件命名规则 

2、Plain Validators和FieldValidators的语法不同

3、Plain Validators和FieldValidators的短路

1、验证的xml文件命名规则 

<actionClass>-validation.xml
<actionClass>-<actionAlias>-validation.xml

To define validation rules for an Action, create a file named ActionName-validation.xml in the same package as the Action. You may also create alias-specific validation rules which add to the default validation rules defined in ActionName-validation.xml by creating another file in the same directory named ActionName-aliasName-validation.xml. In both cases, ActionName is the name of the Action class, and aliasName is the name of the Action alias defined in the xwork.xml configuration for the Action.

2、Plain Validators和FieldValidators的语法不同

分类	可使用的标签
Plian Validators	<validator>
FieldValidators	<validator>
	<field-validator>

There are two ways you can define validators in your -validation.xml file:

<validator>

和

<field-validator>

Keep the following in mind when using either syntax:

2.1、<validator>标签 

The <validator> element allows you to declare both types of validators (either a plain Validator a field-specific FieldValidator).

使用<validator>标签声明一个plian validator。

<!-- Declaring a plain Validator using the <validator> syntax: -->

<validator type="expression>
      <param name="expression">foo gt bar</param>
      <message>foo must be great than bar.</message>
</validator>

使用<validator>标签声明一个field validator。

<!-- Declaring a field validator using the <validator> syntax; -->

<validator type="required">
     <param name="fieldName">bar</param>
     <message>You must enter a value for bar.</message>
</validator>

2.2、<field-validator>标签 

<field-validator>标签包含在<field>标签之下，<field-validator>标签的fieldName属性会自动被<field>标签的name属性所填充。

The <field-validator> elements are basically the same as the <validator> elements except that they inherit the fieldName attribute from the enclosing <field> element. FieldValidators（这里的FieldValidator是指验证的分类） defined within a <field-validator>（这里的<field-validator>是指标签） element will have their fieldName automatically filled with the value of the parent <field> element‘s fieldName attribute. The reason for this structure is to conveniently group the validators for a particular field under one element, otherwise the fieldName attribute would have to be repeated, over and over, for each individual <validator>.

HINT: It is always better to defined field-validator inside a <field> tag instead of using a <validator> tag and supplying fieldName as its param as the xml code itself is clearer (grouping of field is clearer)

推荐：将<field-validator>标签放置到<field>标签之下，这样会使xml代码更整洁。

NOTE: Note that you should only use FieldValidators (not plain Validators) within a block. A plain Validator inside a <field> will not be allowed and would generate error when parsing the xml, as it is not allowed in the defined dtd (xwork-validator-1.0.2.dtd)

 Declaring a FieldValidator using the <field-validator> syntax:

 <field name="email_address">
   <field-validator type="required">
       <message>You cannot leave the email address field empty.</message>
   </field-validator>
   <field-validator type="email">
       <message>The email address you entered is not valid.</message>
   </field-validator>
 </field>

下面的实现的功能和上面是一样的。

<validator type="required">
  <param name="fieldName">email_address</param>
  <message>You cannot leave the email address field empty.</message>
</validator>
<validator type="email">
  <param name="fieldName">email_address</param>
  <message>The email address you entered is not valid.</message>
</validator>

3、Plain Validators和FieldValidators的短路

（1）在一系列的validator中，是可能存在短路的。It is possible to short-circuit a stack of validators.

（2）Plain validator比field-validator的优先级要高。Plain validator takes precedence over field-validator.

（3）Plain validator如果发生短路，它会影响后续的所有validator（包括Plain validator和Field validator）。

（4）如果Field Validator发生短路，它只会影响当前<field>标签内的后续validator。

It is possible to short-circuit a stack of validators. Here is another sample config file containing validation rules from the Xwork test cases: Notice that some of the <field-validator> and <validator> elements have the short-circuit attribute set to true.

<!-- START SNIPPET: exShortCircuitingValidators -->
<!DOCTYPE validators PUBLIC
       "-//Apache Struts//XWork Validator 1.0.3//EN"
       "http://struts.apache.org/dtds/xwork-validator-1.0.3.dtd">
<validators>
 <!-- Field Validators for email field -->
 <field name="email">
     <field-validator type="required" short-circuit="true">
         <message>You must enter a value for email.</message>
     </field-validator>
     <field-validator type="email" short-circuit="true">
         <message>Not a valid e-mail.</message>
     </field-validator>
 </field>
 <!-- Field Validators for email2 field -->
 <field name="email2">
    <field-validator type="required">
         <message>You must enter a value for email2.</message>
     </field-validator>
    <field-validator type="email">
         <message>Not a valid e-mail2.</message>
     </field-validator>
 </field>
 <!-- Plain Validator 1 -->
 <validator type="expression">
     <param name="expression">email.equals(email2)</param>
     <message>Email not the same as email2</message>
 </validator>
 <!-- Plain Validator 2 -->
 <validator type="expression" short-circuit="true">
     <param name="expression">email.startsWith(‘mark‘)</param>
     <message>Email does not start with mark</message>
 </validator>
</validators>
<!-- END SNIPPET: exShortCircuitingValidators -->

Plain validator takes precedence over field-validator. They get validated first in the order they are defined and then the field-validator in the order they are defined. Failure of a particular validator marked as short-circuit will prevent the evaluation of subsequent validators and an error (action error or field error depending on the type of validator) will be added to the ValidationContext of the object being validated.

In the example above, the actual execution of validator would be as follows:

Plain Validator 1
Plain Validator 2
Field Validators for email field
Field Validators for email2 field

Since Plain Validator 2 is short-circuited, if its validation failed, it will causes Field validators for email field and Field validators for email2 field to not be validated as well.

A plain Validator (non FieldValidator) that gets short-circuited will completely break out of the validation stack. No other validators will be evaluated and plain validators takes precedence over field validators meaning that they get evaluated in the order they are defined before field validators get a chance to be evaluated.

A FieldValidator that gets short-circuited will only prevent other FieldValidators for the same field from being evaluated. Note that this "same field" behavior applies regardless of whether the or syntax was used to declare the validation rule. By way of example, given this -validation.xml file:

<validator type="required" short-circuit="true">
  <param name="fieldName">bar</param>
  <message>You must enter a value for bar.</message>
</validator>

<validator type="expression">
  <param name="expression">foo gt bar</param>
  <message>foo must be great than bar.</message>
</validator>

both validators will be run, even if the "required" validator short-circuits. "required" validators are FieldValidator‘s and will not short-circuit the plain ExpressionValidator because FieldValidators only short-circuit other checks on that same field. Since the plain Validator is not field specific, it is not short-circuited.

Usefull Information: More complicated validation should probably be done in the validate() method on the action itself (assuming the action implements Validatable interface which ActionSupport already does).

如果要进行更复杂的验证判断，则应该在Java代码的validate()方法中进行实现。