Java
  Home arrow Java arrow Page 5 - Validator
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? 
JAVA

Validator
By: McGraw-Hill/Osborne
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 22
    2005-09-22

    Table of Contents:
  • Validator
  • Validator Overview
  • Included Validations
  • Creating Form Beans
  • Configuring validation.xml
  • Enabling Client-Side Validations
  • Adding a New Validation Rule
  • Internationalizing Validations
  • Create a validation.xml File

  • 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


    Validator - Configuring validation.xml


    (Page 5 of 9 )

    The validation.xml file is used to declare sets of validations that should be applied to Form Beans. Each Form Bean that you want to validate has its own definition in this file. Inside that definition you specify the validations that you want to apply to the Form Bean’s fields. Following is a sample validation.xml file that illustrates how validations are defined:

    The file is used to declare sets of validations that should be applied to Form Beans. Each Form Bean that you want to validate has its own definition in this file. Inside that definition you specify the validations that you want to apply to the Form Bean’s fields. Following is a sample file that illustrates how validations are defined:

    <!DOCTYPE form-validation PUBLIC
              "-//Apache Software Foundation//DTD Commons
               Validator rules configuration .0//EN"  
     
              "http://jakarta.apache.org/commons/ dtds/validator_1_0.dtd">
    <form-validation>
     
    <formset>
       
    <form name="logonForm">
          <field property="username" depends="required">
            
    <arg0 key="prompt.username"/>
         
    </field>
         
    <field property="password" depends="required">
           
    <arg0 key="prompt.password"/>
          </field>
        </form>
      </formset>
    </form-validation>

    The first element in the validation.xml file is the <form-validation> element. This element is the master element for the file and is defined only once. Inside the <form-validation> element you define <form-set> elements that encapsulate multiple <form> elements. Generally, you will define only one <form-set> element in your file; however, you would use a separate one for each locale if you were internationalizing validations.

    Each <form> element uses the name attribute to associate a name to the set of field validations it encompasses. Validator uses this logical name to map the validations to a Form Bean defined in the struts-config.xml file. Based on the type of Form Bean being validated, Validator will attempt to match the name either against a Form Bean’s logical name or against an action’s path. Inside the <form> element, <field> elements are used to define the validations that will be applied to specified Form Bean fields. The <field> element’s property attribute corresponds to the name of a field in the specified Form Bean. The depends attribute specifies the logical names of validation routines from the validator-rules.xml file that should be applied to the field. The validations specified with the depends attribute will be performed in the order specified and they all must pass.


    Note 

    Detailed information on configuring the validation.xml file is found in Chapter 18.
    Configuring ApplicationResources.properties

    Validator uses Struts’ Resource Bundle mechanism for externalizing error messages. Instead of having hard-coded error messages in the framework, Validator allows you to specify a key to a message in the ApplicationResources.properties file that is returned if a validation fails. Each validation routine in the validator-rules.xml file specifies an error message key with the validator tag’s msg attribute, as shown here:

    Validator uses Struts’ Resource Bundle mechanism for externalizing error messages. Instead of having hard-coded error messages in the framework, Validator allows you to specify a key to a message in the file that is returned if a validation fails. Each validation routine in the file specifies an error message key with the tag’s attribute, as shown here:

    <validator name="required" 
          classname="org.apache.struts.validator.FieldChecks"
             method="validateRequired"
       methodParams="java.lang.Object,
                
               org.apache.commons.validator.ValidatorAction,
               org.apache.commons.validator.Field,
               org.apache.struts.action.ActionErrors, 
               javax.servlet.http.HttpServletRequest"
         
    msg="errors.required">

    If the validation fails when it is run, the message corresponding to the key specified by the msg attribute will be returned.

    The following snippet shows the default set of validation error messages from the ApplicationResources.properties file that comes prepackaged with Struts’ example applications. Each message key corresponds to those specified by the validation routines in the validator-rules.xml file that also comes prepackaged with Struts’ example applications:

    # Error messages for Validator framework validations errors.required={0} is required.
    errors.minlength={0} cannot be less than {1} characters. errors.maxlength={0} cannot be greater than {2} characters. errors.invalid={0} is invalid.
    errors.byte={0} must be a byte.
    errors.short={0} must be a short.
    errors.integer={0} must be an integer.
    errors.long={0} must be a long.
    errors.float={0} must be a float.
    errors.double={0} must be a double.
    errors.date={0} is not a date.
    errors.range={0} is not in the range {1} through {2}. errors.creditcard={0} is not a valid credit card number. errors.email={0} is an invalid e-mail address.

    Notice that each message has placeholders in the form of {0}, {1}, or {2}. At run time, the placeholders will be substituted for another value such as the name of the field being validated. This feature is especially useful in allowing you to create generic validation error messages that can be reused for several different fields of the same type.

    Take for example the required validation’s error message, errors.required:

    errors.required={0} is required.

    When you use the required validation in the validation.xml file, you have to define the value that should be used to substitute {0} in the error message:

    <form name="auctionForm">
      <field property="bid" depends="required">
       
    <arg0 key="prompt.bid"/>
     
    </field>
    </form>

    Error messages can have up to four placeholders: {0}{3}. These placeholders are known as arg0arg3, respectively, and can be specified using the arg0arg3 tags. In the preceding example, the arg0 tag specifies the value that should be used to replace the {0} placeholder. This tag’s key attribute specifies a message key from the ApplicationResources.properties file, such as the one shown next, whose value will be used as the replacement for the placeholder:

    prompt.bid=Auction Bid

    Using a message key for the placeholder value frees you from having to hard-code the replacement value over and over in the validation.xml file. However, if you don’t want to use the Resource Bundle key/value mechanism to specify placeholder values, you can explicitly specify the placeholder value by using the following syntax for the arg0 tag:

    <arg0 key="Auction Bid" resource="false"/>

    In this example, the resource attribute is set to “false”, telling Validator that the value specified with the key attribute should be taken as the literal placeholder value and not as a key for a message in the ApplicationResources.properties file.


    Note 

    Detailed information on the ApplicationResources.properties file is found in Chapter 10.

    More Java Articles
    More By McGraw-Hill/Osborne


     

    Buy this book now. This article is taken from chapter six of the book The Complete Reference Struts, written by James Holmes (McGraw-Hill/Osborne, 2004; ISBN: 0072231319). Check it out at your favorite bookstore. Buy this book now.

    JAVA ARTICLES

    - Deploying Multiple Java Applets as One
    - Deploying Java Applets
    - Understanding Deployment Frameworks
    - Database Programming in Java Using JDBC
    - Extension Interfaces and SAX
    - Entities, Handlers and SAX
    - Advanced SAX
    - Conversions and Java Print Streams
    - Formatters and Java Print Streams
    - Java Print Streams
    - Wildcards, Arrays, and Generics in Java
    - Wildcards and Generic Methods in Java
    - Finishing the Project: Java Web Development ...
    - Generics and Limitations in Java
    - Getting Started with Java Web Development in...







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