Validators: Concluding Remarks - Create an entry in the Validator-rules.xml

(Page 4 of 4 )

The third and final step is to create an entry in the Validator-rules.xml. Now that the implementation part is over, let's see how to hook it up with the Validator framework. To do this I have to add this entry into the validator-rules.xml:

<validator name="phone"
                 classname="ap.mail.PhoneRules"
                 method="validatePhone"
                 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.phone">
</validator>

The above code has to be added after the <global> element of the Validator-rules.xml. The name attribute is given the value by which the custom rule would be used. The value is ‘phone’. Next the fully qualified Java class name of the class is supplied to the classname parameter. Next comes the method attribute. It expects the name of the method containing the validation logic. After that the parameters being passed have to be given in the methodParams attribute. The last attribute tells about the resource key of the message that would be used to display the message present in the Resource Bundle. Here the key is errors.phone.

This is how the custom rule is implemented. The above rule can be used as follows:

<field property="phone"
          depends="required,phone">
          <arg0 key="registration.phone" />
</field>

and add the corresponding error message to the application.properties file:

errors.phone={0} must be a valid phone number

Parting Thoughts

Though the framework makes validations (both server and client side) very easy to implement, the following points must be kept in mind:

1. Server-side validation is recommended over client-side validation. The reasons for this are reliability and security. Server-side validation reduces the problems concerned with JavaScript based validation.
   
   
2. If client-side validation is being used, keep a fall-back plan to validate the values entered in case JavaScript has been disabled or some other ‘unforeseen’ event happens.
   
   
3. Last but not least try to use recurring rules, like certain pattern matching fields, by declaring them in <constants>.

This brings us to the end of the discussion on the Validator framework. This framework acts as a mediator between a Java application and JavaScript. It not only reduces development time but also provides a standard way to approach standard validation based problems. I hope the tutorial was helpful. Till next time.

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

Comments On: Validators: Concluding Remarks

· 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...   >>> Post your comment now!