...

Required steps for using ExtVal:

• Download the required ExtVal jar-files or checkout the Source Code and build it. (details)
• Add these jar-files to your classpath (manually or via maven)
• Use the annotations (details)

That's it!

Simple validation

...

public class Person {
{
    @NotEquals("lastName")
    private String firstName;

    private String lastName;
...
    // Getters and setters omitted for brevity
}

The rest is equivalent to the simple validation (just bind the properties to your input components). Note how we refer to the lastName property by simply using the name of the property.

Available annotations

Simple validation

JPA based validation

JPA annotations are used automatically for UI validation as soon as you:

• Add myfaces-extval-core-.jar and myfaces-extval-property-validation-.jar to the classpath
• Use JPA annotations within the model (e.g.: @Column(nullable = false) -> the field is required)

That's it!

(A simple demo is available here: demo_000)

Cross-Validation

Existing/3rd party constraints

ExtVal has no special requirements for annotations. It's the responsibility of the validation strategy to know how to validate the annotation.
So you can use annotations within any layer without introducing an ExtVal dependency below the view layer.
If you would like to validate 3rd party annotations you can provide a mapping. With the same mechanism you can replace existing (ExtVal) validation strategies. Find detailed information below.

Custom annotations

Simple annotations

ExtVal provides the possibility to validate annotations with so called validation strategies.

The simplest case is to create a custom annotation and to use a name convention for the validator (= validation strategy).
The validation strategy has to implement the ValidationStrategy interface. Or you can extend a class which implements this interface in-/directly. (A simple demo is available here: demo_002, demo_006)

With the property validation module, there are two ways to define validation rules. The first is to (re)use JPA annotations, see #JPA based validation. The second is to use ExtVal's simple validation annotations, see #Simple validation and #Cross-Validation.

JPA based validation

JPA annotations are used automatically for UI validation as soon as you:

• Add myfaces-extval-core-.jar and myfaces-extval-property-validation-.jar to the classpath
• Use JPA annotations within the model (e.g.: @Column(nullable = false) -> the field is required)

That's it!
The table below gives an overview of the validations that are generated, based on JPA annotations.

(A simple demo is available here: demo_000)

Simple validation

Cross-Validation

Existing/3rd party constraints

ExtVal has no special requirements for annotations. It's the responsibility of the validation strategy to know how to validate the annotation. So you can use annotations within any layer without introducing an ExtVal dependency below the view layer. If you would like to validate 3rd party annotations you can provide a mapping. With the same mechanism you can replace existing (ExtVal) validation strategies. Find detailed information below.

Custom annotations

Simple annotations

ExtVal provides the possibility to validate annotations with so called validation strategies.

The simplest case is to create a custom annotation and to use a name convention for the validator (= validation strategy). The validation strategy has to implement the ValidationStrategy interface. Or you can extend a class which implements this interface in-/directly. (A simple demo is available here: demo_002, demo_006)

package my.custom.package

//my.custom.package.CustomConstraint

@Target({METHOD, FIELD})
@Retention(RUNTIME)
public @interface CustomConstraint
 {
}

Note that this is just a minimalistic annotation definition. There's nothing ExtVal-specific here.

package //my.custom.package.CustomConstraintValidationStrategy

public class CustomConstraintValidationStrategy implements ValidationStrategy {
{
    public void validate(FacesContext facesContext, UIComponent uiComponent,
                         MetaDataEntry metaDataEntry, Object convertedObject)
    {

        //custom validation logic
 validation logic
    }
}
   }
}

Note that only one method (validate()) has to be implemented. The naming convention here is that the validation strategy has the same name as the custom annotation, with ValidationStrategy appended. The annotation and the validation strategy must also be in the same package.

That's just the simplest case. You can also use one of the other available name conventions or you can provide a custom convention or a custom name mapper or ...

Cross validation annotations

The class below implements the validation strategy for the @Equals annotation. Note that the class can be relatively simple, since the hard work is done for us in the AbstractCompareStrategy.

@SkipValidationSupport
public class EqualsStrategy extends AbstractCompareStrategy {
{
    public boolean useTargetComponentToDisplayErrorMsg(CrossValidationStorageEntry crossValidationStorageEntry)
    {
        return true;
    }

    protected String getValidationErrorMsgKey(Annotation annotation, boolean isTargetComponent)
    {
        return ((Equals) annotation).validationErrorMsgKey();
    }

    public boolean isViolation(Object object1, Object object2, Annotation annotation)
    {
        return object1 != null && !object1.equals(object2);
    }

    public String[] getValidationTargets(Annotation annotation)
    {
        return ((Equals) annotation).value();
    }
}

In case of model aware cross-validation the validation error message is displayed at the source component instead of the target component.
Since the message is still meaningful, there's no need to provide a special reverse message. (This can be changed by returning false in the useTargetComponentToDisplayErrorMsg() method.

Cross validation details

As we've seen before, we can easily reference a property within the same bean by using the property name.

public class Person
{
    @NotEquals("lastName")
    private String firstName;

    private String lastName;
...
}

We can also refer to properties of related beans, as is shown in the example below:

{code:java|title=Referencing a property of a local reference}
public class RegistrationPage
{
    private Person person = new Person();

    @Equals("person.password")
    private String oldPassword;
...
}

It is even possible to use EL-like expressions to refer to properties of beans that will be available at runtime.

public class RegistrationPage
{
    @Equals("#{person.password}")
    private String oldPassword;
...
}
oldPassword;
...
}

Details of the examples

Within the page you just have to bind a property which has a cross-validation constraint.
If both, the source property as well as the referenced target, are bound to input components of the same form, the converted objects are used for validation. In case of a validation error, the validation error message(s) is/are displayed.

...

If the target of the cross-validation isn't bound to an input component of the same form, the model value of the target is used for validation. The property which triggers the cross-validation always "uses" the converted object (not the model value).

That means:

• Normal cross-validation: converted object (constraint source) + converted object (constraint target)
• Model aware cross-validation: converted object (constraint source) + model object (constraint target)

Reverse validation error messages

...

<!-- The name of annotation: @CustomRequired -->

<!-- Part of the Spring configuration: -->

<bean id="customRequiredValidationStrategy" class="..." lazy-init="true">
    <property name="messageResolver" ref="customMsgResolver"/>
    <property name="requiredValidationService" ref="demoRequiredValidationService"/>
</bean>

<bean id="customMsgResolver" 
      class="org.apache.myfaces.extensions.validator.core.validation.message.resolver.DefaultValidationErrorMessageResolver"
      lazy-init="true">

    <!-- With JSF 1.2 you can use the var name of resource-bundle see faces-config.xml -->
    <property name="messageBundleVarName" value="messages"/>
</bean>

<bean id="demoRequiredValidationService" class="..."/>

The bean name follows the available name conventions.
(Also custom name conventions are supported.)

A simple demo is available here: demo_106

"..."/>

The bean name follows the available name conventions.
(Also custom name conventions are supported.)

A simple demo is available here: demo_106

Furthermore, it's possible to provide a Meta-Data Transformer as Spring bean.

Constraint Aspects

Since r3 ExtVal uses the concept of constraint aspects for generic validation parameters (in case of bean-validation it's a subset which is called validation payload).

Available constraint aspects

• ViolationSeverity
• DisableClientSideValidation
• CaseInsensitive

Mapped Constraint Source

The concept is similar to @JoinValidation. However, this version is more type-save and it is supported by the property- as well as the bean-validation module.

Since both modules support the same syntax you will find further information hereFurthermore, it's possible to provide a Meta-Data Transformer as Spring bean.