JavaScript
  Home arrow JavaScript arrow Validators: Concluding Remarks
Dev Articles Forums 
ADO.NET  
Apache  
ASP  
ASP.NET  
C#  
C++  
ColdFusion  
COM/COM+  
Delphi-Kylix  
Design Usability  
Development Cycles  
DHTML  
Embedded Tools  
Flash  
Graphic Design  
HTML  
IIS  
Interviews  
Java  
JavaScript  
MySQL  
Oracle  
Photoshop  
PHP  
Reviews  
Ruby-on-Rails  
SQL  
SQL Server  
Style Sheets  
VB.Net  
Visual Basic  
Web Authoring  
Web Services  
Web Standards  
XML  
Mobile Linux 
App Generation ROI 
IBM® developerWorks 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
JAVASCRIPT

Validators: Concluding Remarks
By: A.P.Rajshekhar
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 9
    2005-09-28

    Table of Contents:
  • Validators: Concluding Remarks
  • Creating Custom Validators
  • Define the validation logic
  • Create an entry in the Validator-rules.xml

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    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.

    More JavaScript Articles
    More By A.P.Rajshekhar


       · HiThis is the last part of my three part article on Struts validators. Please...
       · You ARE indeed able to have 3 or more test cases represented in an validwhen...
     

    JAVASCRIPT ARTICLES

    - Comparing Fields and Customizing Error Messa...
    - Checking Numbers and File Extensions with jQ...
    - Validating Digits and Dates with jQuery`s Va...
    - Validating Ranges, Emails, and URLs with jQu...
    - More Uses for the jQuery Tooltip Plug-in`s b...
    - Building Image-Based Tooltips with the jQuer...
    - Using the jQuery Tooltip Plug-in`s bodyHandl...
    - Using Rangelength, Min and Max with the Vali...
    - Using Minlength and Maxlength with the Valid...
    - Modifying Tooltip Coordinates with the jQuer...
    - Applying a Fade Out Effect with the jQuery T...
    - Tracking Mouse Movements with the jQuery Too...
    - Checking Online Forms with the Validator jQu...
    - Nested JavaScript Functions as Objects
    - The jQuery Tooltip Plug-in







    © 2003-2009 by Developer Shed. All rights reserved. DS Cluster 2 Hosted by Hostway
    For more Enterprise Application Development news, visit eWeek