In the first part, we saw a glimpse of what the Validator framework can do. But that is just the tip of the iceberg. The driving force behind creation of the Validator framework is reusability. This facet of the framework is but one of the many aspects that can not only reduce the web GUI development time but also enforce standards across all interfaces.
Validators: Into the Deep - Email, Mask, Date, and Length Validators (Page 2 of 4 )
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:
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:
Here, the <var-value> child node of <var>tag contains the regular expression to validate the last name.
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.
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:
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: