Using the Validator framework in Struts

　Every application has the responsibility to ensure that the data they insert into the backend database is legal and valid. After all, if the data these applications rely on is compromised, it will be catastrophic, and the application can still What do you do to keep yourself functioning properly? For example, in an application that uses a formal relational database, each field in the database has its own rules and constraints to ensure that the data stored in it is correct to a certain extent. Any application that uses backend repository data is responsible for protecting the integrity of the data they submit.
　
　 Any attempt to insert or update data that does not meet the standards will likely be discovered and rejected. This kind of detection may be spread throughout every corner of the application, and some verification may be performed at the presentation layer. At the business logic layer, business logic objects generally also have business logic verification, and data must also be checked in the background database.
　
　Unfortunately, because this kind of verification is ubiquitous in the application, it causes the application to verify the data to a certain extent in the code redundancy. This is not what the application wants, because this duplication of work in multiple places makes the deployment and maintenance of the application take more time. If these validation rules can be reused throughout the application, it will make the application more flexible. In other words, deployment will be faster, customization will be easier, and the program will be more flexible.
　
　Jakarta Commons Project Validator Framework Introduction
　 Validator is an open source project created by David Winterfeldt, and it is also a sub-project of Jakarta Commons. The Commons project mainly provides some reusable components like Validator. Other well-known Commons components include BeanUtils, Digester, Logging framework, etc. Validator version 1.0 was released in early November 2002.
　　
　Benefits of using Validator
　　.Using the Validator framework has many advantages over generally defining validation rules in the application code, such as:
　　.Validation rules can be defined for the application in one place;
　　.Validation rules and applications are Loosely coupled;
　 . Server-side and client-side validation rules can be defined in the same place;
　 . Configuring new validation rules or modifying existing validation rules becomes easier;
　 . Supports internationalization;
　 . Supports regular expressions;
.Can be used for web applications or standard java applications;
　 .Using a declarative method instead of programming;
In addition, the biggest feature of Validator is that it supports pluggability. Later in the article you will see how to use the built-in validation rules of the Validator framework to better complete your work, and more importantly, the Validator framework allows you to customize the validator and insert it into the framework.
　
　The relationship between Struts and Validator
　It should be pointed out that the Validator framework itself is built on the Struts framework. David Winterfeldt, the creator of Validator, discovered in the process of using Struts that the same validation rules need to be used repeatedly in many ActionForm classes, which results in a lot of code redundancy. So he decided to create the Validator framework to eliminate this redundancy, and Validator was born.
　
Although the Validator architecture was originally born for the Struts architecture, it is designed and constructed to be used independently of the Struts architecture. This feature allows you to use this framework in any application, regardless of whether it is Struts-based or not. Just because you don't use the Struts framework will not affect the effect of the Validator architecture on your application. In fact, this is why Validator is part of the Jakarta Commons project and not directly part of the Struts project.
　
Now, let’s integrate this framework into web applications like Struts-based architecture. At the end of the article we will introduce how to apply it to other types of applications, such as EJB-based applications.
　　
　Overview of Validator components
　　The Validator architecture consists of the following components:
　　Validators; A Validator is to execute a Validation rules are a Java class called by the Validator framework. The framework calls this Validaotor class based on the method signature defined in the configuration file. Typically, each Validator class provides a separate validation rule, which can then be combined into more complex rule sets.
　
　Note: Sometimes for convenience, a Validator class can also define multiple validation rules, and each rule is a static method and does not contain any client state information.
　
　The framework provides 14 default validation rules. Sometimes these rules are also called the "basic rules" of the Validator framework. These basic rules are as shown in Table 1:
　Name　　　　　　　　　　　　　
byte, short, integer, Verify whether the value can be converted into the corresponding basic data type
Long, float, double
creditCard Verify whether the input field is a legal credit card number
date Verify whether the input field is a legal date
email Verify the input Check whether the input field can successfully match a regular expression
maxLength Check whether the length of the value is less than or equal to the given maximum length
minLength Check whether the length of the value is greater than or equal to the given minimum length
range Check Whether the range of values ​​is between the maximum value and the minimum value
　required　　　Verify whether the input field is not empty, or whether the length of the value that does not contain spaces is greater than zero
　Table 1
　As you can see in Table 1, the Validator framework Provides most of the validation rules required by web applications. You can use these existing validation rules to create your own validation profiles. Even so, as we mentioned earlier and will talk about later, you can feel free to add more Validators according to your needs.
　
　Now, let us discuss how to configure and use these basic Validators in an application based on Struts architecture.
What makes the Validator framework flexible is that all validation rules and their specific details are implemented through configuration declarations in external files. Your application does not need to know these specific validation rules. This feature allows you to extend and modify the ruleset without touching your application's source code. This is very important if you want to personalize each installation or when your needs change.
　If you use the Validator framework of Struts 1.1, you will use two configuration files, one is called validator-rules.xml and the other is called validation.xml; in fact, you can also name them arbitrarily, or even put them Merged into one XML file. However, you'd better keep them separate as they each have their own uses.
　
　Note: If you download Validator from the Jakarta website, these two files are not included. These two files can only be found in the Struts download that includes the Validator framework.
　The validator-rules.xml file
　The validator-rules.xml file defines the Validators that the application can use. validator-rules.xml acts as a template, defining the Validators that may be used by all applications.
　
Note: This xml file and another xml file we will discuss below should be placed where the class loader can find them. When we use the Validator framework in a web application, the correct location should be under WEB-INF.
　The validator-rules.xml file is subject to the management of validator-rules_1_1.dtd, which can be downloaded from jakarta.apache.org/struts/dtds/validator-rules_1_1.dtd. We don't want to spend too much time studying the specific details of this file, we only give some basic introduction here.
　　The most important elements in the validator-rules.xml file are contained in the element, for example, Example 1:
　　Example 1: A simple validator-rules.xml file
　
　 　ValidatorAction,
　　　　　 org.apache.commons.validator.Field,
　　　　 org.apache.struts.action.ActionErrors,
　　　　 javax.servlet.http.HttpServletRequest"
　　 msg="errors.required"/ >
　　
　　　　 classname="org.apache.struts.util.StrutsValidator"
　　 method="validateMinLength"
　　 methodparams="java.lang.Object,
　　　 org.apache.commons.validator.ValidatorAction,
　　　 org. apache. commons.validator.Field,
　　　　　 org.apache.struts.action.ActionErrors,
　　global>

　　
　
　
Each Validator used by the application corresponds to a element. In Example 1, we show you two Validators, one is the request Validator and the other is the minimum length Validator. The element supports many attributes. These properties are necessary to tell the framework which correct class and method this Validator should call. For example, the request Validator element in Example 1 indicates that this Validator will call the validateRequest() method of the org.apache.struts.util.StrutsValidator class. Validator may also depend on another Validator. For example, the minimum length Validator in Example 1 is an example. It contains a depends attribute, which is used to indicate that this Validator will depend on the requesting Validator. The msg attribute specifies a resource binding with a key value that the framework will use to generate the correct error message. The use of resource binding is beneficial for localization of error messages.
　　The element also supports the sub-element, allowing you to specify a javascript function to be run by the client. This way server-side and client-side validation can be specified in the same place, which makes maintenance of the application simple.
　
　Validation.xml file
　The second configuration file of the Validator framework is this file called validation.xml. In fact, you can name it whatever you like. The above is the content of using the Validator framework in Struts. For more related articles, please pay attention to the PHP Chinese website (www.php.cn)!