@ -752,21 +752,21 @@ public final class CustomPropertyEditorRegistrar implements PropertyEditorRegist
@@ -752,21 +752,21 @@ public final class CustomPropertyEditorRegistrar implements PropertyEditorRegist
<title>Spring 3 Type Conversion</title>
<para>
Spring 3 introduces a <filename>core.convert</filename> package that provides a general type conversion system.
The system defines an SPI to implement type conversion logic, as well as an API to execute type conversions at runtime.
The system defines an API to implement type conversion logic, as well as an API to execute type conversions at runtime.
Within a Spring container, if configured, this system can be used as an alternative to PropertyEditors to convert externalized bean property value strings to required property types.
The public API may also be used anywhere in your application where type conversion is needed.
</para>
<sectionid="core-convert-Converter-SPI">
<title>Converter SPI</title>
<sectionid="core-convert-Converter-API">
<title>Converter API</title>
<para>
The SPI to implement type conversion logic is simple and strongly typed:
The API to implement type conversion logic is simple and strongly typed:
</para>
<programlistinglanguage="java"><![CDATA[
package org.springframework.core.converter;
public interface Converter<S,T> {
T convert(S source) throws Exception;
T convert(S source);
}]]></programlisting>
<para>
@ -774,7 +774,7 @@ public interface Converter<S, T> {
@@ -774,7 +774,7 @@ public interface Converter<S, T> {
Parameterize S as the type you are converting from, and T as the type you are converting to.
For each call to convert(S), the source argument is guaranteed to be NOT null.
Your Converter may throw any Exception if conversion fails.
An IllegalArgumentException is often thrown to report an invalid source value.
An IllegalArgumentException should be thrown to report an invalid source value.
Take care to ensure your Converter implementation is thread-safe.
</para>
<para>
@ -827,7 +827,7 @@ public class StringToEnumFactory implements ConverterFactory<String, Enum> {
@@ -827,7 +827,7 @@ public class StringToEnumFactory implements ConverterFactory<String, Enum> {
this.enumType = enumType;
}
public T convert(String source) throws Exception {
@ -837,8 +837,7 @@ public class StringToEnumFactory implements ConverterFactory<String, Enum> {
@@ -837,8 +837,7 @@ public class StringToEnumFactory implements ConverterFactory<String, Enum> {
<title>ConversionService API</title>
<para>
The ConversionService defines a public API for executing type conversion logic at runtime.
Converters are <emphasis>always</emphasis> executed behind this API.
User code should not depend on the Converter SPI.
Converters are often executed behind this facade interface:
</para>
<programlistinglanguage="java"><![CDATA[
public interface ConversionService {
@ -1462,5 +1461,294 @@ public class MyController {
@@ -1462,5 +1461,294 @@ public class MyController {
</section>
</section>
</section>
<sectionid="org.springframework.mapping">
<title>Spring 3 Object Mapping</title>
<para>
There are scenarios, particularly in large message-oriented business applications, where data and object transformation is required.
For example, consider a complex Web Service where there a separation exists between the data exchange model and the internal domain model used to structure business logic.
In cases like this, a general-purpose data mapping facility can be useful for automating the mapping between these disparate models.
Spring 3 introduces such a facility built on the <linklinkend="expressions-intro">Spring Expression Language</link> (SpEl).
This facility is described in this section.
</para>
<sectionid="mapping-Mapping-API">
<title>Mapper API</title>
<para>
The API to implement data mapping logic is simple and strongly typed:
</para>
<programlistinglanguage="java"><![CDATA[
package org.springframework.mapping;
public interface Mapper<S,T> {
T map(S source, T target);
}]]></programlisting>
<para>
To create your own Mapper, simply implement the interface above.
Parameterize S as the type you are mapping from, and T as the type you are mapping to.
The source and target arguments provided to you should never be null.
Your Mapper may throw any RuntimeException if mapping fails.
Take care to ensure your Mapper implementation is thread-safe.
</para>
<para>
Consider the following hand-coded Mapper example:
</para>
<programlistinglanguage="java">
public class PersonDtoPersonMapper implements Mapper<PersonDto, Person> {
public Person map(PersonDto source, Person target) {
String[] names = source.getName().split(" ");
target.setFirstName(names[0]);
target.setLastName(names[1]);
return target;
}
}</programlisting>
<para>
In this trivial example, the Mapper simply maps the PersonDto's <literal>name</literal> property to the Person's <literal>firstName</literal> and <literal>lastName</literal> properties.
A general purpose object Mapper implementation exists in the <classname>org.springframework.mapping.support</classname> package named <classname>SpelMapper</classname>.
Built on the flexible Spring Expression Language (SpEL), this Mapper is capable of mapping between objects of all types, including JavaBeans, Arrays, Collections, and Maps.
It is also extensible and allows additional MappableTypes to be configured.
</para>
<sectionid="mapping.SpelMapper-usage">
<title>Usage</title>
<para>
To use a SpelMapper with its default configuration, simply construct one and call map:
</para>
<programlistinglanguage="java"><![CDATA[
SpelMapper mapper = new SpelMapper();
mapper.map(aSource, aTarget);
]]>
</programlisting>
<para>
By default, SpelMapper will map the fields on the source and target that have the same names.
If the field types differ, the mapping system will attempt a type coersion using Spring 3's <linklinkend="core.convert">type conversion system</link>.
Nested bean properties are mapped recursively using the same algorithm.
Any mapping failures will trigger a MappingException to be thrown.
If there are multiple failures, they will be collected and returned in the MappingException thrown to the caller.
</para>
<para>
To illustrate this default behavior, consider the following source object type:
In this example, the <literal>number</literal>, <literal>name</literal>, and <literal>address</literal> properties are automatically mapped since they are present on both the source and target objects.
The AccountDto's <literal>address</literal> property is a JavaBean, so its nested properties are also recursively mapped.
Recursively, the <literal>street</literal> and <literal>zip</literal> properties are automatically mapped since they are both present on the nested AddressDto and Address objects.
Nothing is mapped to the Address's <literal>city</literal> and <literal>state</literal> properties since these properties do not exist on the AddressDto source.
</para>
</section>
<sectionid="mapping.SpelMapper-Explicit">
<title>Registering Explicit Mappings</title>
<para>
When default mapping rules are not sufficient, explicit mapping rules can be registered by calling one of the <literal>mapper.addMapping(...)</literal> method variants.
Explicit mapping rules always override the default.
For example, suppose you need to map <literal>AccountDto.name</literal> to <literal>Account.fullName</literal>.
Since the two property names are not the same, default auto-mapping would never be performed.
Handle a situation like this by explicitly registering a mapping rule:
</para>
<programlistinglanguage="java"><![CDATA[
mapper.addMapping("name", "fullName");
]]>
</programlisting>
<para>
In this example, the <literal>name</literal> property will be mapped to the <literal>fullName</literal> property when the mapper is executed.
No default mapping will be performed for the <literal>name</literal> since an explicit mapping rule has been configured for this property.
</para>
<sectionid="mapping.SpelMapper-Explicit-forcing">
<title>Forcing Explicit Mappings</title>
<para>
You can require that all mapping rules must be defined explicitly by disabling the "auto mapping" feature:
</para>
<programlistinglanguage="java"><![CDATA[
mapper.setAutoMappingEnabled(false);
]]>
</programlisting>
</section>
</section>
<sectionid="mapping.SpelMapper-CustomConverter">
<title>Registering Custom Field Converters</title>
<para>
Sometimes you need to apply field specific type conversion or data transformation logic when mapping a value.
Do this by registering a converter with a Mapping:
</para>
<programlistinglanguage="java"><![CDATA[
mapper.addMapping("name", "fullName").setConverter() { new Converter<String,String>() {
public String convert(String value) {
// do transformation
// return transformed value
}
});
]]>
</programlisting>
</section>
<sectionid="mapper.SpelMapper-IgnoringFields">
<title>Ignoring Fields</title>
<para>
Sometimes you need to exclude a specific field on a source object from being mapped.