Validators: Introducing Struts Validator Framework - Validator Framework-What is it?
(Page 2 of 4 )
The Validator framework is part of the Struts framework. More specifically it is a part of the Jakarta commons project. The aim of the Commons project was to provide reusable components for J2EE. Apart from logging needs, validation is an area that requires reusable components. The Validator framework provides reusability by combining the best from both worlds -- XML’s declarative approach and Java’s programmatic approach. Following are the core components of this framework:
- Validators
- Configuration Files
- Resource Files/Bundles
- JSP Custom Tags
- Validator Form Classes
Let's take a detailed look at each of these.
Validators
Each validation rule is represented by a Java class. When the framework makes a call to the Java class, the rule represented by the class is executed. Such classes are called Validators. Basic Validators provided by the framework include CreditCard, date, email, and so on.
Configuration Files
Because the framework makes use of the declarative approach, there is no need to embed the logic inside the application itself. This is achieved by using rules and details configured in external files. Actually there are only two files used for configurations of validation logic. They are the validator-rules.xml file and the validation.xml file.
Validator-rules.xml File:
This file contains all the possible validations available to an application. These validations are present as definitions in this file. The controlling document of Validator-rules.xml is Validator-rules_1_1.dtd. Hence all the elements defined in this file are defined according to the above DTD. The contents of the XML file are too long to be described here in their entirety. So I will describe one of the elements representing one the most common validations: required. The required validation is applied to mandatory fields, such as the user's social security number or, for that matter, date of birth. The piece of code given below illustrates how this is provided by the Validation framework.
<form-validation>
<global>
<validator name="required"
classname="org.apache.struts.util.StrutsValidator"
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"/>
</global>
</form-validation>
The reusable validation logic, or the Validator, is the child of the <global> node,
which in turn is the child of the <form-validation> tag. All of the Validators that are
available to an application come under the <global> tag. Since the validation is
based on the form data, it becomes a subset of the <form-validation> tag.
The <validator> has many attributes. These are described below:
Name: The name of the Validator is provided by the name attribute. It is this attribute that the framework uses to identify the Validator. This name is used to tell which element of the form needs to be validated in the Validation.xml file. Here the name is “required,” indicating it is for mandatory fields.
- Classname: Next comes the class that contains the logic of the validation. When the name is used within the Validation.xml file, the framework maps it with the classname attribute to instantiate the corresponding class implementing the logic. Since the “required” rule is already provided by the Commons project, the classname is “org.apache.struts.util.StrutsValidator.”
- Method: The name of the method that contains the logic is given in this attribute. The method is implicitly called by the framework. This is really helpful while developing custom Validators.
- Methodparams: The parameters that have to be passed into the method given in the method attribute are provided through this attribute. The last four values, i.e. org.apache.commons.validator.ValidatorAction, org.apache.commons.validator.Field, org.apache.struts.action.ActionErrors and javax.servlet.http.HttpServletRequest remain same in every Validator. But the occurrence of the first parameter i.e. java.lang.Object can vary according to the number of fields that take part in validation. For example, let's take the rule that the maximum temperature should always be greater than the minimum temperature. In this case there will be two occurrences of java.lang.Object specifying that the validation requires data from two fields.
- Msg: This attribute is self explanatory. The value of this attribute determines the message to be displayed when the validation fails.
Validation.xml File:
This file contains the rules that are used by the application. The name of this file is not specific. It can be given any name. Also, the contents of this file can be placed within the Validator-rules.xml file. It is here that the rules defined within the valuator-rules.xml are coupled with the components of application. In the case of Struts, the rules are applied to the data fields (or instance variables) of ActionForm objects. There will be more on validation.xml and its configurations in the last segment of this tutorial, where an actual application will be set up and configured for the framework.
Resource Bundle
Resource Bundle forms the base of localization. In Struts, the framework itself is designed in such a way that each of its components have the localization feature embedded in it. Validator framework is no exception. For a given Validator, the error messages created when the rule fails come from the resource bundles. For the common Validators provided by the Validator framework, the default messages can be placed in the Struts application’s message resources. Some of these messages are:
#Error messages used by the Validator
errors.required={0} is required.
errors.minlength={0} can not be less than {1} characters.
errors.maxlength={0} can not be greater than {1} characters.
errors.invalid={0} is invalid.
The parameter in place of {0} and {1} is inserted automatically by the framework when the rules fail. The value corresponding to the parameters comes from the Validator-rules.xml and validation.xml files.
JSP Custom Tags
The Struts framework comes with a handy set of custom tags. The <errors> and <javascript> tags of the Struts HTML category of tags are the most useful of the lot in the case of validations. The former is for server-side validation while the latter is for client side validation.
Validator Form Class
In Struts data is passed from the JSP page (view layer) to Action class (controller layer) by means of ActionForm objects. To impose the rules, the standard Struts ActionForm won’t suffice. For this to happen the ActionForm class designed specifically for the Validator framework must be used. It comes in two varieties- ValidatorForm and DynaValidatorForm. The former is used in place of ActionForm while the latter is used with the DynaActionForm. Whatever the variety being used, two methods are present in both of them- reset() and validate(). Using these, the framework performs the validation. ActionForm objects are also known as form beans.
Now that the theory behind the Validator framework is over, let's move on to a practical example.
Next: Validator Framework- A Real world Example >>
More JavaScript Articles
More By A.P.Rajshekhar
/ 74 
