About the Validator Library

The x1seven Validator Library provides a small set of re-usable classes that help you to apply the Validator Object pattern to your Java applications.

Using this library you can apply validation rules at any layer in your application, and always return multiple errors back to the user interface via the ValidationException.

This library doesn't provide a framework for defining rules. If you're looking for something like that, try Apache Commons Validator.

Brendon Matheson has written an article discussing the Validator Object pattern and detailing the use of the x1seven Validator Library to achieve validation that meets requirements of useability, defensiveness and architectural suitability.

The Validator library, like all x1seven Elements components, is provided under the Lesser GNU Public License version 2.1.

About x1seven Elements

The x1seven Elements projekt provides small focused components that make it easier to build enterprise applications.

All of the components in the x1seven Elements projekt are open-source under the LGPL version 2.1. This license allows x1seven Elements components to legally be used and distributed in other open-source and commercial projekts.

Typical Usage

The x1seven Valdator library promotes a pattern as much as it provides a small framework. The key to the pattern is moving your validation logic into stateless Validator service objects. These objects should expose validate() methods that are overloaded to cover all the different validation scenarios you might have.

When validation rule violations are found, your validate() methods should accumulate messages for the user in a Messages collection. Once all relevant validation rules have been applied, if any messages were generated then the Validator service object should create and throw a ValidationException that holds your Messages object.

The following cut-down code sample demonstrates how Validator objects provide overloaded validate() methods that delegate to one another to carry out the full set of validation rules. It also shows how messages are collected in a Messages object with the ValidationException only finally being created when we are sure we are going to throw it. This is important because instancing Exception's is expesive due to the amount of context information that must be gathered for an Exception object.

public class WidgetValidator extends Object {

    public void validate(
        String length,
        String width,
        String height) throws ValidationException {

        Messages messages = new Messages();

        // Perform data type validation and convert
        // Strings to Doubles
        // ...

        // Delegate to carry out further validation
        validate(messages, lengthDbl, widthDbl,
            heightDbl);

    }

    public void validate(
        Messages messages,
        Double length,
        Double width,
        Double height) throws ValidationException {

        // Perform business validation on the length,
        // width and height
        // ...

        // If any validation error messages have been
        // logged, throw a ValidationException to
        // return them back to the user interface
        if(messages.hasMessages()) {
            throw new ValidationException(messages);
        }

    }
}

ValidationExceptions should be caught by the user interface, and the messages within rendered for the user. If your user interface is implemented using Struts then the ActionMessagesConverter class can be used to translate from x1seven Validator Library messages to Struts ActionMessages. The standard Struts <html:errors> JSP tags can then be used to render the messages to the user.

For a full discussion, please see Brendon Matheson's article.