Custom Validation of annotations

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

Custom annotations

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)

If you don't like the default conventions, you can provide a custom name mapper, or a custom information provider bean, or you provide a mapping between annotations and the validation strategies (via properties file or ExtVal Java API), or ...

Minimal implementation

//my.custom.package.CustomConstraint

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

//my.custom.package.CustomConstraintValidationStrategy
public class CustomConstraintValidationStrategy implements ValidationStrategy
{
    void validate(FacesContext facesContext, UIComponent uiComponent,
                  MetaDataEntry metaDataEntry, Object convertedObject)
    {
        //custom validation logic
    }
}

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 ...

Hints
It's recommended to use AbstractValidatorAdapter or AbstractAnnotationValidationStrategy instead of ValidationStrategy.

In ExtVal r3+ validation strategies don't have to be aware of empty/null values. So it's safe to delegate to legacy JSF validators.
If a validation strategy should validate such values, it's possible to annotate the validation strategy with NullValueAwareValidationStrategy and/or EmptyValueAwareValidationStrategy.

Existing annotations

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.

Provide/replace validation strategy mappings

If you don't like to use the name mapping concept, you can provide static mappings between annotations and validation strategies.
Use the convention for a mapping file (org.apache.myfaces.extensions.validator.custom.strategy_mappings.properties) (it's customizable)

or use the ExtVal Java API:

Register a resource-bundle file which contains an annotation/validation strategy mapping:

StaticConfiguration<String, String> staticConfig = new StaticResourceBundleConfiguration();
staticConfig.setSourceOfMapping("[custom package + name of the properties file.]");
ExtValContext.getContext().addStaticConfiguration(StaticConfigurationNames.META_DATA_TO_VALIDATION_STRATEGY_CONFIG, staticConfig);

It's also used internally to provide the JPA based validation support. So you can find an example at the PropertyValidationModuleStartupListener.
A similar approach is used internally by the annotation based config extension

This approach is more typesafe - a simple example:

StaticInMemoryConfiguration staticConfig = new StaticInMemoryConfiguration();
staticConfig.addMapping(CustomConstraint.class.getName(), CustomValidator.class.getName());
ExtValContext.getContext().addStaticConfiguration(StaticConfigurationNames.META_DATA_TO_VALIDATION_STRATEGY_CONFIG, staticConfig);

(If you also don't like the approach above, you can implement your own ValidationStrategyFactory to introduce your own concept.)

Extensions/Validator/ValidateAnnotations (last edited 2010-01-06 18:03:59 by GerhardPetracek)