<init>

Default implementation of the MessageCodesResolver interface.

Will create two message codes for an object error, in the following order (when using the prefixed formatter):

• 1.: code + "." + object name
• 2.: code

Will create four message codes for a field specification, in the following order:

• 1.: code + "." + object name + "." + field
• 2.: code + "." + field
• 3.: code + "." + field type
• 4.: code

For example, in case of code "typeMismatch", object name "user", field "age":

• 1. try "typeMismatch.user.age"
• 2. try "typeMismatch.age"
• 3. try "typeMismatch.int"
• 4. try "typeMismatch"

This resolution algorithm thus can be leveraged for example to show specific messages for binding errors like "required" and "typeMismatch":

• at the object + field level ("age" field, but only on "user");
• at the field level (all "age" fields, no matter which object name);
• or at the general level (all fields, on any object).

In case of array, List or java.util.Map properties, both codes for specific elements and for the whole collection are generated. Assuming a field "name" of an array "groups" in object "user":

• 1. try "typeMismatch.user.groups[0].name"
• 2. try "typeMismatch.user.groups.name"
• 3. try "typeMismatch.groups[0].name"
• 4. try "typeMismatch.groups.name"
• 5. try "typeMismatch.name"
• 6. try "typeMismatch.java.lang.String"
• 7. try "typeMismatch"

By default the errorCodes will be placed at the beginning of constructed message strings. The messageCodeFormatter property can be used to specify an alternative concatenation MessageCodeFormatter.

In order to group all codes into a specific category within your resource bundles, e.g. "validation.typeMismatch.name" instead of the default "typeMismatch.name", consider specifying a prefix to be applied.

Author
Juergen Hoeller

Author
Phillip Webb

Author
Chris Beams

Since
1.0.1