STRUTS2 Series: (15) a probe into the validator interface

1 defines the validator interface under the Com.opensymphony.xwork2.validator package.

Public interface Validator<t> {//...}

Validator is divided into two main categories:Plain validators and fieldvalidators.

The validators come in both different flavors:a) Plain Validators/non-field VALIDATORSB) fieldvalidators

This article mainly discusses the differences between the two validator of Plain validators and fieldvalidators .

Plain validators (such as the Expressionvalidator) perform validation checks that is not inherently tied to a single specified field. When you declare a plain Validator in Your-validation.xml file, do not associate a "FieldName" attribute with it. (You should avoid using plain validators within the syntax described below.)

Plain validators is not associated with field.

fieldvalidators (such as the Emailvalidator) is designed to perform validation checks in a single field. They require that's specify a "fieldname" attribute in Your-validation.xml file. There is different (but equivalent) XML syntaxes You can use the Declare fieldvalidators (see "vs. Syntax" below).

Fieldvalidators must be validating a field.

Note:note that you don't declare what ' flavor ' of validator you is using the Your-validation.xml file, you just declare The name of the validator to use and Struts would know whether it ' s a "plain validator" or a "fieldvalidator" by looking at The validation class, the validator ' s programmer chose to implement.

Note: You do not need to declare whether you are currently using plain validations, or fieldvalidators,struts will recognize it automatically.

Review: Validation of form data is divided into front-end JavaScript validation and background validation. In Struts2, there are two ways to implement background validation: Using Java code Validation and using XML file validation. This article is to learn about two authentication methods in XML validation (Plain validators and fieldvalidators). The validator interface is the gateway for implementation validation in STRUTS2.

Just talked about this is the way XML validation, then whether it is Plain validators, or fieldvalidators, will be written in the XML file, this raises a question, this. xml file how to name it?

Once you know how the. xml file is named, take a look at the two differences between Plain validators and fieldvalidators : syntax , short-circuiting .

There is places where the differences between the validator flavors is important to keep in mind: (1) when Choosin G The XML syntax used for declaring a validator (either or) (2) When using the short-circuit capability

The structure of this article:

1. Validation of XML file naming conventions

2, Plain validators and fieldvalidators syntax are different

3. Short Circuit of Plain validators and Fieldvalidators

1. Validation of XML file naming conventions

<actionclass>-validation.xml<actionclass>-<actionalias>-validation.xml

to define validation rules for an Action, create a file named actionname-validation.xml . In both cases, actionname is the name of the Action class , and

2, Plain validators and fieldvalidators syntax are different

Classification	tags available for use
Plian validators	<validator>
Fieldvalidators	<validator>
	<field-validator>

There is ways you can define validators in Your-validation.xml file:

<validator>

And

<field-validator>

Keep the following in mind when using either syntax:

2.1. <validator> Label

the <validator> element allows you to declare both types of validators (either a plain validator a fiel D-specific fieldvalidator).

Use the <validator> tag to declare a 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></va Lidator>

Use the <validator> tag to declare a field validator.

<!--declaring a field validator using the <validator> syntax; --><validator type= "Required" > <param name= "fieldName" >bar</param> <message>you must en ter a value for bar.</message></validator>

2.2. <field-validator> Label

The <field-validator> tag is included under the <field> tab, andthe FieldName property of the <field-validator> tag is automatically <field> The label's Name property is populated .

The <field-validator> elements is basically the same as the <validator> elements except tha T they inherit the FieldName attribute from the enclosing <field> element. Fieldvalidators (here Fieldvalidator refers to the category of authentication) defined within a <field-validator> (here the <field-validator> refers to the label) Element'll has their fieldName automatically filled with the value of the parent <field> element ' s fieldName attr Ibute. The reason for this structure are to conveniently group the validators for a particular field under one element, otherwise The FieldName attribute would has to being repeated, over and over, for each individual <validator>.

Hint:it is all better to defined field-validator inside a <field> tag instead of using a <validator> tag a nd supplying fieldName as its param as the XML code itself are clearer (grouping of field is clearer)

Recommendation: Place the <field-validator> tag under the <field> tab, which will make the XML code cleaner.

Note:note this should only use fieldvalidators (not plain validators) within a block. A plain Validator inside a <field> won't be allowed and would generate error when parsing the XML, as it's not a Llowed 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 EMA Il address field empty.</message> </field-validator> <field-validator type= "email" > <messag E>the Email address you entered are not valid.</message> </field-validator> </field>

The following implementations are functionally the same as above.

<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 are not valid.</message ></validator>

3. Short Circuit of Plain validators and Fieldvalidators

(1) In a series of validator, there may be short-circuiting. It is possible to short-circuit a stack of validators.

(2) Plain Validator has higher priority than field-validator. Plain Validator takes precedence over Field-validator.

(3) Plain Validator If a short circuit occurs, it affects all subsequent validator (including Plain Validator and field validator).

(4) If field validator has a short circuit, it will only affect subsequent validator in the current <field> tag.

It is possible to short-circuit a stack of validators. Here are another sample config file containing validation rules from the Xwork test cases:notice that some of the <fiel D-validator> and <validator> elements has 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 is defined and then the field-validator in the order they is defined. Failure of a particular validator marked as short-circuit would prevent the evaluation of subsequent validators and an Erro R (Action error or field error depending on the type of validator) would be added to the validationcontext of the object is ing validated.

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

Plain Validator 1Plain Validator 2Field validators for mail fieldfield validators for email2 field

Since Plain Validator 2 is short-circuited, if it validation failed, it would causes field validators for email field and Field validators for EMAIL2 field to is validated as well.

A Plain Validator (non fieldvalidator) that gets short-circuited would completely break out of the validation stack. No other validators 'll be evaluated and plain validators takes precedence over field validators meaning tha T they get evaluated in the order they is defined before field validators get a chance to be evaluated.

A fieldvalidator that gets short-circuited would only prevent other fieldvalidators for the same field from being Evalu Ated. Note that this "same field" behavior applies regardless of whether the or syntax is used to declare the validation rule. By-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 would be run, even if the "required" validator short-circuits. "Required" validators is Fieldvalidator's and would not short-circuit the plain expressionvalidator because Fieldvalidator s only short-circuit and checks on that same field. Since The plain Validator is not field specific, it's not short-circuited.

Usefull Information:more complicated validation should probably be do in the Validate () method on the action itself (as Suming the action implements Validatable interface which Actionsupport already).

If you want to make more complex validation judgments, you should do so in the Validate () method of the Java code.

STRUTS2 Series: (15) a probe into the validator interface