Concepts provided by ExtVal

Here you will find an overview of the most important concepts of ExtVal. You will find much more details, if you have a look at the implementation.

Anyway, most of the time you will use only a subset of the information you will find below.

Basic concepts in ExtVal

• Zero configuration
• Optional configuration
• Extensibility

Zero configuration

You can provide custom ExtVal artifacts via conventions. Optionally you can customize these conventions.
The usage of conventions is intended only for the final web-application(s).

You will find the available conventions at InformationProviderBean (customizable) and InternalConventionProvider.
Conventions provided by the InternalConventionProvider aren't customizable. However, therefore you will find alternative mechanisms such as custom name mappers.

Optional configuration

If you don't like conventions (or you would like to overrule them), you can also use the ExtVal Java API or configuration (e.g. via web.xml ).

Furthermore, if you implement a validation module, it's recommended not to customize conventions and to be careful with using them.
Some of these mechanisms are intended only for the final web-application(s). If you implement such a module use the ExtVal Java API + a startup listener or an alternative approach such as the annotation based config and java based config extensions for ExtVal.

• It's a module provided as jar file which can be used by different web-applications.

Extensibility

You can extend and/or customize ExtVal in many respects. There are custom name mappers, factories and much more.
If you implement your own renderer interceptor, you can build up your own infrastructure with your own mechanisms. (That's very simple but normally you don't do that. It's a very advanced topic. In such a case you can also deregister the very basic ExtVal validation mechanism - the ValidationInterceptor. So you avoid the overhead of the default implementation and you can just plug in your own validation infrastructure.) Anyway, normally you just use small extension points. ExtVal provides a rich validation infrastructure. You can use, extend and/or customize easily.

Available mechanisms

The most popular mechanisms of ExtVal are:

• Validation strategy
• Message resolver
• Startup listener
• Meta data transformer
• Component initializer
• Processed information recorder
• Renderer interceptor
• Validation exception interceptor
• Metadata extraction interceptor (since 1.x.2)
• Constraint Aspects/Parameters (since x.x.3)
• Validation interceptors (since x.x.3)
• Generic Storages (since x.x.3)
• Constraint severity (since x.x.3)
• Meta-data storage filters (since x.x.3)

Most of the time you will just use the annotations of ExtVal. So you don't need these mechanisms.
Just use the annotations and the rest is done by ExtVal.
To provide custom messages is also a frequent use-case. You will find more details at Custom Messages.
So you need these mechanisms just if you would like to implement more advanced use-cases.
Validation strategies and message resolvers are also frequently used mechanisms to implement custom validation. The other mechanisms are advanced mechanisms.

Validation strategy

Provides logic to validate annotations.

Message resolver

Returns an internationalized validation error message.

Startup listener

Provides the possibility to customize/extend ExtVal at startup.

Meta data transformer

Transforms information provided by annotations to a more generic representation.
e.g. @Required, @Column(nullable = false), @Length(minimum = 1),... result in the abstract information that the input is required.

Component initializer

Mechanism to initialize a component before it gets rendered. The initialization is done based on the abstract meta-data provided by meta-data transformers.
Example use-case: join client-side validation mechanisms of component libs. (e.g. see the TrinidadComponentInitializer)

Processed information recorder

Mechanism which allows to implement concepts like cross-validation. Such a recorder gets called after conversion and before validation.

Renderer interceptor

Mechanism to intercept renderer methods.

Validation exception interceptor

Allows to intercept validator exceptions thrown by ExtVal validation strategies.
Example use-case: replacing the label-placeholder within the validation message with the value of the label (e.g. see HtmlCoreComponentsValidationExceptionInterceptor)

Metadata extraction interceptor (since 1.x.2)

Mechanism which allows to add/change/remove meta-data entries for the target property after the meta-data extraction and before validation is processed.

Constraint Aspects/Parameters (since x.x.3)

Mechanism which allows to add typesafe parameters in a generic way. Details see: here

Validation interceptors (since x.x.3)

Mechanism which allows to implement global as well as (constraint) local interceptors (before and after validation). They get invoked in any case.

Generic Storages (since x.x.3)

Mechanism which allows to implement storages with different scopes and functionality but a generic mechanism to manage them. Developers can resolve and reset storages via a generic api. To identify a storage a storage-type and storage-name is required. So it's possible to have multiple storages with the same type.

Constraint severity (since x.x.3)

Allows e.g. to show validation warnings instead of errors. It's available via Constraint Aspects/Parameters.

Meta-data storage filters (since x.x.3)

Allows to filter (add/remove/change) meta-data before it gets added to the meta-data storage (=basic cache) directly after the extraction process. The meta-data storage is a cache to improve the performance of the extraction process. So all dynamic mechanisms of ExtVal (e.g. metadata extraction interceptors) are compatible.