Spring Framework Official Document Learning (iv) validation, Data Binding, Type Conversion

Objective

In the Spring Framework official documentation, the three were put together, but there was no explanation why they were put together. Probably the default is that the reader is a person with relevant experience, but that is not the case, for example, me. Fortunately, bored head to see again, and check the data and knock code, finally understand.

In fact, to put it bluntly, we use an example to explain:

Assume that an existing app that functions is to receive the birthday you enter and then show your age. It seems that the app only uses the current date minus the date you entered is age, it should be simple, right? Unfortunately, that is not the case.

Here are three questions:

Question one: We enter the string forever, the string needs to be converted into a date format to be used by our app. --corresponding type conversion

Question two: How do we enter the date of the string to be used for the app backend logic? --corresponding data binding

Problem three: People's age is limited, can not be negative, not too large (for example, more than 200). --corresponding check

The same problem arises in the interaction between the browser and the server, as requests and responses are mostly parsed into strings.

Now, you should have understood the relationship between validation, Data Binding, Type conversion, and they are independent but co-compatible with each other.

Premise

Before you know more, you should know two key concepts: JavaBean and properties.

JavaBean is a simple class, non-parametric construct, naming convention (setter/getter)-its standard is provided by Oracle! See JavaBeans or JavaBean wiki.

The corresponding part of the Setter/getter is called the Property (attribute).

In addition, the Org.springframework.beans package complies with the JavaBean standard provided by Oracle. But JavaBean and spring beans are not the same concept!

Well, there's time to study the JavaBean spec.

Overview

Now let's look at the specific definitions and the tools available in spring:

Validation Checksum : Checks the property. --"whose property?" It's JavaBean! 】

Spring provides a validator interface that can be used on any layer.

Data binding: Binds data to the property. --"whose property?" It's JavaBean! 】

Spring provides databinder to perform specific data binding work.

Validator and DataBinder are in the Org.springframework.validation package.

Type Conversion : Converts an object of one type to an object of another type, such as between a string and a date. --"Who's the type?" The Property! 】

Spring provides the PropertyEditors as well as the Core.convert package and format package. The latter two are introduced in Spring 3 and can be seen as a substitute for propertyeditor and simpler.

Notice that none of these three are actually operating the property of the JavaBean.

So the question comes again, how does spring operate JavaBean and its property? The answer is through the Beanwrapper interface and its implementation of Beanwrapperimpl, which internally through the propertyeditors to parse and format the property.

Beanwrapper this thing is very low-level concept, users generally do not have to use it directly, understand can.

Another, PropertyEditor is part of JavaBeans specification!

Depth

Here's a look at the specific uses of these tools in spring:

1, Validator, see the source, this interface only two methods, supports (class<?> clazz) used to determine whether to support a class; Validate (Object target, Errors Errors) is used for validation and is reported to errors if there is an error message--Recommended for use with tool class Validationutils.

Implement this interface to define your own validator, with the following code:

[][][][][][] Olw

Note that if it is a validation of a composite class, it can also inject existing validator-reuse, high efficiency.

2. Resolving code to error message

If we want to output error message via Messagesource, we will use the error code before filling it in.

When we call errors's reject method directly or indirectly, its implementation will not only register our incoming code, but also register some additional error code. The error code for the specific registration is determined by Messagecodesresolver.

By default, Defaultmessagecodesresolver is used, which not only registers your incoming code, but also registers the field name!

For example, if you use Rejectvalue ("Age", "Too.darn.old"), you will not only register "Too.darn.old", but also register "Too.darn.old.age" and "Too.darn.old.age.int".

More strategies are seen in the Javadoc of Messagecodesresolver and Defaultmessagecodesresolver.

The above two, how to say, does not involve reflection and so on. This is different from the following, say it in advance.

3, Beanwrapper, located in the Org.springframework.beans bag.

According to its Javadoc, Beanwrapper provides functions including: Set/get property values (single/multiple), get property descriptor, and query to determine whether the property is readable or writable. Nested property is also supported. The addition of standard JavaBeans propertychangelisteners and vetoablechangelisteners is also supported, eliminating the need to encode in the target class (this is not nonsense, like an AOP listener). Finally, the setting of indexed properties is supported.

Beanwrapper are generally not used directly in code, but are used in DataBinder and beanfactory.

In addition, as the name implies, Beanwrapper works by wrap a bean to perform the operation.

Here's a look at the specific features:

3.1. Setting and getting basic and nested properties

is the Set/get property values (Basic and nested), which is done through the Beanwrapper setpropertyvalues () and Getpropertyvalues () methods-see Javadoc.

Here are a few conventions that need to be highlighted:

Expression	Explain
Name	Property name.
Account.name	Nested property name
ACCOUNT[2]	The 3rd element of the Indexed property account
Account[companyname]	Map

This section does not provide source code reading, because we do not have the basic use of it. Just understand.

3.2, built-in propertyeditor implementation

I must say again, PropertyEditor is part of JavaBeans specification! Fully qualified name: Java.beans.PropertyEditor.

It is an interface (that is, abstract), so you need to provide the implementation for use. So spring provides a bunch of implementations.

Spring Framework Official Document Learning (iv) validation, Data Binding, Type Conversion