Validator overview
Without Validator, you have to write all code required to verify the form data and put it in the validate () method of the Form Bean object. For each form bean domain you want to verify it, you need to write logical code to implement verification. In addition, you must write a code to store an error message when verifying fails.
With Validator, you don't have to write any code used to verify or store the error message in the Form Bean. Instead, the Form Bean provides an ActionForm subclass of Validator, which provides validation or storage of error messages.
The Validator framework can be installed as a pluggable verification routine system that can be used for Form Bean authentication. Each verification routine is just a Java method, responsible for performing a specific type of verification task, verifying may pass, or fail. By default, Validator is packaged together with several useful verification routines, which can meet the verification requirements in most cases. However, if the Validator Frame does not provide the verification routine you need, you can create custom authentication routines and insert it into the framework. In addition, Validator also supports authentication of server-side and client (JavaScript), and Form Bean only provides server-side verification interfaces.
Validator uses two XML configuration files to determine which authentication routine installed and how to apply them to a given application. The first configuration file validator-rules.xml Description should be inserted into the verification routine in the frame, and provide the name of each verified logic. The Validator-Rules.xml file also defines the client JavaScript code for each verification routine. You can configure the validator to let it send this JavaScript code to your browser so that you can verify that you can do it on the client and server.
The second profile validation.xml determines which verification routine application to which Form bean. Definition in the file Using the logical name of the Form Bean given by the struts-config.xml file and the logical name of the verification routine given by the Validator-Rules.xml file to associate both.
Using the Validator framework includes the two profiles that enable Validator plugins, configure Validator, and create form beans for the ActionForm subclass of Validator. How to configure and use Validator in detail below.
Enable Validator plugin
Although the Validator framework is provided with Struts, the Validator is not enabled in the default condition. To enable Validator, add the following plugin definition to your application's struts-config.xml file.
Value = "/ Web-INF / Validator-rules.xml, / web-inf / Validation.xml "/> This definition tells Struts to load and initialize the Validator plugin for your application. When initialization, the plugin is loaded with the path name property specified by the path name property, with a comma-separated Validator configuration file list. The path to each profile should be specified in a related path to the web application, as shown in the example. Note that your application's struts-config.xml file must match the Struts Configuration Document Type Definition (Struts Configuration Document Type Definition, DTD), and the latter specifies the order of elements in the file. So, you must define the validator plugin to place the appropriate location. Make sure the easiest way to arrange the elements in the file is to use tools such as Struts Console, which automatically format your profile to keep consistent with DTD. Configure validator-rules.xml The Validator framework can be set to insertable system whose verification routine is only a Java method inserted into the system to perform specific validation. Validator-rules.xml file is instructions inserted into the validation routine for validation. The Struts sample application has a pre-configured copy of this file. In most cases, you don't have to modify this pre-configured copy unless you want to add your customized verification to this frame. Listing 1 is an example validator-rules.xml file that explains how to insert the authentication routine into the Validator. Each verification routine in the validator-rules.xml file has its own definition, which is declared with the Validator tag, and uses the Name property to specify the logical name for the verification routine, and specify the class and method of the routine. The logical name of this routine is supplied to other routines in the file and verification definition in the Validation.xml file is used to reference the routine. Note that the Validator tag is equipped in the JavaScript tag, the JavaScript tag is used to define the client JavaScript code to perform the same verification as the server side on the client. Provided verification program By default, Validator includes several basic authentication routines, you can use them to handle most authentication issues. These routines have logical names, such as Required (for input required values), CREDITCARD (for entering credit card number), email (for entering email address values), and so on. Create Form Bean In order to use Validator, your application's form bean must return to a subclass of the ActionForm of Validator, not the ActionForm itself. Validator's ActionForm subclass provides an implementation process of ActionForm's validate () method (which is embedded in the Validator framework). You don't have to write verification code from your head and put it into the validate () method. On the contrary, you can completely ignore the method, because Validator provides you with verification code. Similar to the core features provided by Struts, Validator provides two ways to choose from to create form beans. The first way you can choose is to create a specific Form Bean object below: Package com.jamesholmes.minihr; Import org.apache.struts.validator .Validatorform; Public class logonform extends validatorform { PRIVATE STRING UserName; PRIVATE STRING Password; Public string getUsername () { Return UserName; } Public void setusername (String Username) { THIS.USERNAME = UserName; } Public string getpassword () {return password; } Public void setpassword (String Password) { this.password = password; } } This class is similar to you not using the class created by Validator, but it provides ValidatorForm instead of an actionform. This class does not provide an implementation process for ActionForm's empty reset () and validate () methods because ValidatorForm provides the corresponding process. Methods of configuring this specific FORM bean in the struts-config.xml file is the same as the configuration of the regular form bean: TYPE = "com.jamesholmes .minihr.logonform "/> The logical name specified by the form marked to a particular form bean is the name used when defining the validation in the validation.xml file, as shown below:
PUBLIC "- // Apache Software Foundation // DTD Commons Validator Rules Configuration 1.0 // en " "http://jakarta.apache.org/ Commons / DTDS / Validator_1_0.dtd ">> Depends = "Required"> Validator uses the value of the Name property of the form mark to match the name of the authentication definition with the name of the defined Form bean to apply. The second method that can be selected when creating a Form bean is to define a dynamic Form Bean in the struts-config.xml file, as shown below: TYPE = "Org.apache . Struts.validator.Dynavalidatorform "> TYPE = "java.lang.string" /> TYPE = "java.lang.string" /> Dynamic Form Bean does not require a specific Form Bean object; in contrast, to define the properties and types of Form Beans, and Struts creates Form Bean for you. Validator allows you to use this concept, just like this concept in core Struts. The only difference between using Validator is to specify that form bean is org.apache.struts.validator.dyNavalidatorForm type, not org.apache.struts.Action.DynaActionform type. The logical name assigned to the dynamic Form bean is the name used when defining the validation in the validation.xml file. Validator uses the names that match the name to the Form Bean. In addition to the two standard methods of creating Form Beans, Validator also provides a high-level feature that links multiple authentication definitions to a FORM bean definition. When you use ValidatorForm or DynavalidatorForm's Form Bean, Validator uses the logical name of the Form Bean in the struts-config.xml file, map the FORM BEAN to the validation definition in the validation.xml file. This mechanism is very useful in most cases, but at some point, Form Bean is shared in multiple operations. One operation may use all domains of the Form Bean, while another can only use one subset of these domains. Because the verification definition is connected to the Form Bean, only the operation of one subset of the domain cannot bypass the verification of the unused domain. When verifying the Form Bean, an error message is generated for unused domains, because Validator does not know that the unused domain is not verified, it simply thinks it as missing or invalid. In order to solve this problem, Validator provides two additional Actionform subclasses that allow you to associate validation and operations instead of being associated with Form Beans. This way you can use the form bean to specify which verification is used for the form bean. For specific Form Beans, you have to declare the org.apache.struts.valiDator.validatorActionform subclass like this: Public Class Addressform Extends ValidatorActionform { ... } For dynamic form beans, define the type of Org.apache.Struts.validator.DynavalidatorActionform for the Form.Apache.Struts.valiDator.DynavalidatorActionForm in the struts-config.xml file, as shown below: Type = "org.apache.struts .validator.dynavalidatorActionform ">> ... In the validation.xml file, map a set of verifications to an action path instead of being mapped to the Form Bean name, because if you define the Create Address and Edit Address two operations (they use the same form bean), then each There will be a unique operand name as follows: TYPE = "com.jamesholmes .minihr.createaddressAction "name =" addressform "/> TYPE = "com.jamesholmes .minihr.editaddressaction " Name = "addressform" /> The following Validation.xml file segment shows two sets of verification, which are used for the same FORM BEAN, but there are different operation paths: Depends = "Required"> Depends = "Required"> Because the Form bean either belongs to the ValidatorActionform subclass, you or if you belong to the DynavalidatorActionform subclass, Validator knows that the logical name of the Form Bean is found in the logical name of the Form Bean with an operation path. Configure the validation.xml file The Validation.xml file is used to declare a set of validations that will be applied to the Form Beans. Each Form Bean to be verified has its own definition in this file. In this definition, specify the verification of the domains to be applied to the Form Bean. Below is an example of a validation.xml file, explaining how to define authentication:
PUBLIC "- // Apache Software Foundation // DTD Commons Validator Rules Configuration 1.0 // en " "http://jakarta.apache.org/ Commons / DTDS / Validator_1_0.dtd ">> Depends = "Required"> Depends = "Required"> The first element of the validation.xml file is form-validation. This element is the main element of the file and is only defined once. Define the Form-Set element within the Form-Validation element, which includes multiple form elements. In general, only one FORM-SET element is defined in the file, but if it is necessary to verify, it is necessary to use an Form-set element separately in each place. Each form element uses the NAME attribute to associate the name with the domain verification set therebetween. Validator uses this logical name to map these validates to a Form Bean defined in the struts-config.xml file. Depending on the type of Form Bean to be verified, the Validator strides the name to match the name of the logical name or operation path of the Form Bean. In the form element, the field element defines the verification of the specific domain to be applied to the Form Bean. The Property property of the Field element corresponds to the domain name in a particular Form bean. Depends properties Use the validator-rules.xml file to specify the logical name of the verification routine, which will be applied to domain verification. Configuring ApplicationResources.properties Validator uses the Struts resource binding mechanism to embody the error message. No need to hard coding the error message in the frame, Validator allows you to specify a key value for a message in the ApplicationResources.properties file. If the verification fails, the key value will be returned. Each verification routine in the Validator-Rules.xml file specifies the key value of the error message with the Validator tagged MSG property, as shown below: ClassName = "Org.apache .struts.validator.fieldchecks " Method = "ValidateRequired" Methodparams = "java.lang . Object, Org.apache.commons.validator .ValiDatoryAction, Org.apache.commons .valiDator.field, org.apache.struts .act.actionerrors, javax.servlet .http.httpservletRequest " Msg = "ErrorS.Required"> If the verification fails when verifying the routine runtime, the message corresponding to the key value specified by the MSG property is returned. The following segments show the default message set at the time of validation error from the ApplicationResources.Properties file, which is provided by the Struts sample application. The key value of each message corresponds to the message specified by the verification routine by the validator-rules.xml file, supplied by the Struts sample application. # Iremor Messages for Validator Framework Validations Errors.Required = {0} is required. . 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.0. 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. Note that each message has a placeholder, the form is {0}, {1} or {2}. During operation, the placeholder is replaced by another value, such as the name of the verified domain. This feature is particularly useful, which enables you to create a general authentication error message that can be reused by several different domains. For example, the following is given an error message error message error message error: Errors.Required = {0} is required. When you use the Required authentication in the validation.xml file, you must define the value used to replace the {0} in the error message, as shown below: Error messages can have 4 placeholders: {0} and {3}. These placeholders are called Arg0 to Arg3, respectively, you can specify them by using Arg0 ~ Arg3 tags. In the above example, the Arg0 flag specifies the value for replacing the {0} occupancy. The key attribute of this tag specifies a message key value from the ApplicationResources.properties file, which is used to replace the placeholder, as shown below: Next step Read more articles about Validator Jakarta.apache.org/commons/Validator About struts console www.jamesholmes.com/struts Prompt.bid = Auction BID This method allows you to repeat your replacement value in the validation.xml file in the validation.xml file. However, if you don't want to use the key value / value mechanism of Resource Bundle to specify the value of the placeholder, you can use the ARG0 tag to explicitly specify the value of the placeholder: In this example, the value of the Resource property is set to false to inform the Validator to specify the value specified by the key attribute as the value of the placeholder, instead of a key value of the message in the ApplicationResources.properties file. Enable client verification In addition to providing a framework for simplifying a server-side form data verification process, it also provides methods for performing client authentication. Each authentication routine defined in the Validator-Rules.xml file can specify the JavaScript code, which can be run in the browser (on the client), thereby performing the same verification process as the server side. . This form is not allowed to be submitted unless all forms are verified. To enable client authentication, you must put the JavaScript tag of Struts HTML TAG Library (Tag Library) in JSP, as shown below: The JavaScript tag requires the form of the form definition name given in the validation.xml file to specify the list definition name given to the list of validation.xml files to specify the list of validation.xml files for the form that you want to perform verification. Depends = "Required"> Depends = "Required"> All validations of the specified server side will run on the client for the form definition. Since the client verifies to execute with JavaScript, there can be a variety of ways to do not perform it. To ensure that the verification process can always run, whether you choose to enable client authentication, Validator executes these validates on the server. in conclusion The Validator Framework provides configurable systems for the verification of form data, which adds a lot of valuable features to the core Struts framework. By using the Validator framework for your application, you can save time and simplify the development process of the Struts application.
