The Problem

... this version allows you to add general information to a constraint. You can think about it as an extension point for constraints.

Constraint aspects allow to provide a typesafe alternative. So you can provide an ExtVal add-on without knowing the concrete constraint implementation.Only a central logic (e.g. an add-on) has to know what information might be available as parameter at the constraint and how to use this information.The final usage is quite easy (see the next example).

So you can have add-on-X which provides new features and constraints Y (they don't know each other). But you can use the features of add-on-X with constraints Y (if they have an attribute of the type Class<? extends ValidationParameter>[])

How to use constraint parameters

You can see - the final usage is typesafe, shorter and the constraint isn't aware of the specific values behind.So if you have existing constraints you just have to add an attribute of the type Class<? extends ValidationParameter>[] and your constraint can automatically use any feature provided via a parameter implementation of ExtVal or an ExtVal add-on.

Stop reading here if you don't like to implement a custom parameter or if you don't like to query information of a parameter

Before you continue reading - constraint aspects don't replace "domain-attributes".E.g. the values of min and max of @Length are attributes of the constraint which might be different at every usage.Furthermore, they aren't interesting for other constraints like @Equals.So it doesn't make sense to use a generic concept to replace such attributes.

Anyway, there are use-cases for shared features. ExtVal uses this mechanism e.g. for severities. Constraint aspects are interesting for features which allow a small set of possible values and which are interesting for different constraints of the whole application.Without a generic solution you have to introduce one attribute per feature for every use-case at every constraint. And the implementation which uses these information have to be aware of all types of constraints (esp.: if you don't have a fix attribute name for it).

Constraint aspects allow you to extend the functionality of existing constraints.Furthermore, they allow to introduce shared features. The implementations to process the information provided by the aspects/parameters aren't aware of the attribute name of the parameter nor of the concrete type of the constraint, parameter,... That means you provide a generic aspect attribute mechanism once and use it for different constraints and features.

More Examples

You can query the parameters of a constraint at any time. (You just need access to the constraint.)

The important part is: Class< ? extends ValidationParameter >You can choose any attribute-name! (An array isn't required)A parameter implementation has to implement this marker interface. The values within the implementation are marked via @ParameterValue. Optionally you can provide @ParameterKey. If you don't specify an explicit key, the interface extending the ValidationParameter interface is the key.