Validators: Concluding Remarks
(Page 1 of 4 )
This article discusses two facets of the Struts-Validation framework. The first one deals with complex rules, while the second concerns information for creating custom rules that could be hooked up with the Validation framework.
In the previous article I discussed the different validation scenarios covered by the Validation framework. The scenarios included the simplest yet the most frequently recurring validations. In limiting the discussion to the most common requirements related to data input, I have kept the complex yet most important pieces of the puzzle (at least to the newly converted) out of the picture. The first piece deals with complex rules, including comparing the values of two fields where each field value is valid when simple single field multi-validation rules are applied. The second piece contains information for creating custom rules that could be hooked up with the Validation framework. In this article, the last part of this series, I will be discussing these two facets of the Struts-Validation framework. So let's get started.
Complex rule Validations with validwhen
One of the recurring themes in validation is comparing the values of two fields to arrive at the decision of whether the values entered are valid or not. The best examples of such cases include password confirmation and date comparisons. In the traditional approach to the problem, a JavaScript has to be written to do these tasks. But when working with the Validator framework, there is no requirement for custom JavaScript development, even in cases involving complex rules. The solution provided by the framework is the rule known as validwhen.
The core of the validwhen Validator is the value test of the <var> node. The <var-vlue> child tag contains an expression whose outcome decides the validity of the input. The outcome of the expression is/must be always boolean. The valid values that the expression can take are:
- String literals, i.e. both single quoted and double quoted literals.
- Integer values/literals. They can be decimal, octal or hexadecimal formats.
- null that can be used to test against a value to check whether the gathered value is null.
- Other fields, if field-value comparison is being done. To achieve this, the other field can be referenced by using the name of the field.
- Indexed fields. They can be accessed by using an explicit integer for indexing, e.g. -itemIds[2]. Also, if used without an explicit index (e.g.- itemIds[]), the current index would be used to access the value.
- To access the value of the field being currently validated, the literal *this*. The * is a part of the literal.
To elucidate this further let's take a look at an example.
<field property="emailAddress" depends="validwhen">
<arg0 key="registration.emailAddress"/>
<var>
<var-name>test</var-name>
<var-value>
((sendNewsletter == null) or (*this* != null))
</var-value>
</var>
</field>
Let's suppose that the registration form which we developed in the last part contains a checkbox asking whether the user would like to have a newsletter delivered to them. If the option is selected, the email field should not be left blank. To apply this rule validwhen is used.
The <var-value> tag corresponding to the <var-name>test</var-name> contains the expression to evaluate this rule. The expression ((sendNewsletter == null) or (*this* != null)) can be read as, this field is valid when the sendNewsletter is not null, or the field value is not null. In other words, the validation should succeed only if either the checkbox is not ticked and the email field is null or the checkbox is selected and the value of the email field is not null.
In short, when the framework encounters a rule such as (sendNewsletter == null) , it interprets it as “if the value of the field sendNewsletter id is null, then the value of this field (validating) must also be null. In such a case only, the validation is valid.” Thus, by using the validwhen Validator, complex rules for which generic JavaScript was never possible, could be applied without much ado.
While working with validwhen, certain rules concerned with the "grammar" of the expression have to be kept in mind. They are:
- Comparisons must be enclosed within brackets. This applies to each comparison. The expression given in the above example illustrates this perfectly. It contains two comparisons and both are enclosed within the brackets.
- When using "and, or" operators for joining comparisons, it must be kept in mind that only two comparisons may be joined in such a way. That means an expression such as ((sendNewsletter == null) or (*this* != null) and (age!=null)) is invalid.
- If the values to be compared can be converted to int data type, then numeric comparison is done, otherwise string comparison is applied.
That’s about all there is for the validwhen Validator. So now that you have seen how easy it is to use Validators, it's time to create a custom Validator and hook it up with the Validator framework.
Next: Creating Custom Validators >>
More JavaScript Articles
More By A.P.Rajshekhar
/ 9 
