Home arrow JavaScript arrow Page 2 - Validators: Into the Deep

Validators: Into the Deep

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.

Author Info:
By: A.P.Rajshekhar
Rating: 5 stars5 stars5 stars5 stars5 stars / 14
September 13, 2005
  1. · Validators: Into the Deep
  2. · Email, Mask, Date, and Length Validators
  3. · Constants and Variables
  4. · Registration Form: Putting it All Together

print this article

Validators: Into the Deep - Email, Mask, Date, and Length Validators
(Page 2 of 4 )

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"/>

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"/>

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"/>
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"/>

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"/>


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"/>



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. 

blog comments powered by Disqus

- Project Nashorn to Make Java, JavaScript Wor...
- JavaScript Virus Attacks Tumblr Blogs
- Google Releases Stable Dart Version, JavaScr...
- Khan Academy Unveils New JavaScript Learning...
- Accessing Nitro? There`s an App for That
- JQuery 2.0 Leaving Older IE Versions Behind
- Fastest JavaScript Engine Might Surprise You
- Microsoft Adjusting Chakra for IE 10
- Brendan Eich: We Don`t Need Google Native Cl...
- An Overview of JavaScript Statements
- An Overview of JavaScript Operators
- Overview of JavaScript Variables
- More of the Top jQuery Social Plugins
- The Top jQuery Social Plugins
- More of the Top jQuery Slider Plugins

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials