org.springframework.validation Documentation Differences

This file contains all the changes in documentation in the package org.springframework.validation as colored differences. Deletions are shown like this, and additions are shown like this.

If no deletions or additions are shown in an entry, the HTML tags will be what has changed. The new HTML tags are shown in the differences. If no documentation existed, and then some was added in a later version, this change is noted in the appropriate class pages of differences, but the change is not shown on this page. Only changes in existing text are shown here. Similarly, documentation which was inherited from another class or interface is not shown here.

Note that an HTML error in the new documentation may cause the display of other documentation changes to be presented incorrectly. For instance, failure to close a <code> tag will cause all subsequent paragraphs to be displayed differently.

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 {@code errorCode}s will be placed at the beginning of constructed message strings. The messageCodeFormatter property can be used to specify an alternative concatenation format.

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

Extended variant of the Validator interface, adding support for validation 'hints'. @author Juergen Hoeller @author Sam Brannen @since 3.1

Validate the supplied {@code target} object, which must be of a type of Class for for which the .supports(Class) method typically has (or would) returnreturns {@code true}.

The supplied errors instance can be used to report any resulting validation errors.

This variant of {@code validate()} supports validation hints, such as validation groups against a JSR-303 provider (in thiswhich case, the provided hint objects need to be annotation arguments of type {@code Class}).

Note: Validation hints may get ignored by the actual target {@code Validator}, in which case this method is supposed to beshould behave just like its regular .validate(Object, Errors) sibling. @param target the object that is to be validated (can be {@code null}) @param errors contextual state about the validation process (never {@code null}) @param validationHints one or more hint objects to be passed to the validation engine @see ValidationUtils