Validators: Into the Deep

Email Validator

One of the validations that is often difficult to implement is email field validation. One must use a character recognition loop or the regular expression to validate an input email id. But the Validator framework has made it as easy as "taking a walk in the park." All one has to do is specify the value of the "depends" attribute as “email.” To elucidate, the following example should be sufficient:

 <field property="customeremail" depends="email">
         <arg0 key="customer.email"/>
     </field>

Similarly, the framework has provided a standard rule for validating credit card numbers. In place of  “email” provide “creditCard” as the value of the "depends" attribute. The following snippet shows a credit card validation:

 <field property="name" depends="required, creditCard">
         <arg0 key="registration.cardnumber"/>
     </field>

Mask Validator

Let's take the case where the first name field cannot contain special characters. If the traditional approach is taken, then I would have to write a JavaScript function that loops through the input, or write a regular expression to check for the presence of special characters. Though the use of a regular expression makes it easier, it still has to be embedded into the JavaScript. So to truly do away with writing JavaScript, the Validator framework provides the mask Validator. With the mask Validator, the rule can be written in the form of a regular expression. Here the <var> element comes into picture again. For example, to validate a field accepting first names, the rule would be:

 <field property="lastname" depends="required,mask">

<msg name="mask" key="registration.lastname.maskmsg"/>

<arg0 key="registration.lastname"/>
   <var>
   <var-name>mask</var-name>
  <var-value>^[a-zA-Z]*$</var-value>
   </var>
   </field>
    
Here, the <var-value> child node of <var>tag contains the regular expression to validate the last name.

Date Validator

Date validation is one of the most difficult validations when implemented using JavaScript. This is not true, however, within the context of the framework. To use the date validation rule, provide “datePattern” as the value of <var-name> and the required pattern as the value of <var-value> as shown in the following code snippet:

 <field property="saledate" depends="required,date">
         <arg0 key="exam.startDate"/>
         <var><var-name>datePattern</var-name>
  <var-value>MM/dd/yyyy</var-value></var>
     </field>

The date Validator uses java.text.SimpleDatePattern to validate the date pattern. Instead of datePattern, datePatternStrict can be used. The difference is that if the later is used, then it also checks the length of the input data. If its length is different from that of the pattern provided, then validation fails.

Length Validator

There are times when the entered data should be of a specified length. This kind of validation is governed by the business rules. But whatever the reason, before the arrival the framework, creating a length validation function was not a walk in the park. The scenario has been changed by the length Validators provided by the framework. There are two kinds of length Validators:

1. minlength Validator
   
2. maxlength Validator

The former checks whether the entered value is smaller than the specified limit, whereas the later validates whether the entry exceeds the maximum specified value. To elucidate, let's go back to the example covering name validation. The rule specifies that length of the entered name should be more than three letters and less than 15. In the lingo of the framework it looks like this:

 <field property="name" depends="required,minlength">
        <arg0 key="customer.name"/>

<arg1 name="minlength" key="${var:minlength}" resource="false"/>

         <var>
          <var-name>minlength</var-name>
          <var-value>3</var-value>
        </var>
    </field>

and for max length the rule is:

<field property="name" depends="required,maxlength">
   <arg0 key="customer.name"/>
   <arg1 name="maxlength" key="${var:maxlength}" resource="false"/>
       <var>

  <var-name>maxlength</var-name>
  <var-value>30</var-value>

    </var>
 </field>

As has been the case with many of the aforementioned rules, variables represented by <var > play an important role. That brings the discussion to the next section: constant and variables.