Jump to: navigation, search

Difference between revisions of "EclipseLink/UserGuide/MOXy/Type Level/Handling Inheritance"

m
Line 7: Line 7:
 
|apis= * [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/oxm/annotations/XmlDiscriminatorNode.html XmlDiscriminatorNode]
 
|apis= * [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/oxm/annotations/XmlDiscriminatorNode.html XmlDiscriminatorNode]
 
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/oxm/annotations/XmlDiscriminatorValue.html XmlDiscriminatorValue]
 
* [http://www.eclipse.org/eclipselink/api/latest/org/eclipse/persistence/oxm/annotations/XmlDiscriminatorValue.html XmlDiscriminatorValue]
}}
+
}}  
= Handling Inheritance =
+
  
EclipseLink MOXy provides several ways to represent your inheritance hierarchy in XML.
+
= Handling Inheritance  =
  
 +
EclipseLink MOXy provides several ways to represent your inheritance hierarchy in XML.
  
== Using xsi:type ==
+
<br>
  
By default, EclipseLink will use the '''xsi:type''' attribute to represent inheritance in XML.
+
== Using xsi:type ==
  
In this example an abstract super class ('''ContactInfo''') contains all types of contact information. '''Address''' and '''PhoneNumber''' are the concrete implementations of '''ContactInfo'''.
+
By default, EclipseLink will use the '''xsi:type''' attribute to represent inheritance in XML.
 +
 
 +
In this example an abstract super class ('''ContactInfo''') contains all types of contact information. '''Address''' and '''PhoneNumber''' are the concrete implementations of '''ContactInfo'''.  
  
 
<source lang="java">
 
<source lang="java">
Line 36: Line 38:
 
   
 
   
 
}
 
}
</source>
+
</source>  
  
 
+
<br> Because the '''Customer''' object can have different types of contact information, its property refers to the superclass.  
Because the '''Customer''' object can have different types of contact information, its property refers to the superclass.
+
  
 
<source lang="java">
 
<source lang="java">
Line 49: Line 50:
 
   
 
   
 
}
 
}
</source>
+
</source>  
  
 
+
<br> Marshalling an example '''Customer''' would produce the following XML:  
Marshalling an example '''Customer''' would produce the following XML:
+
  
 
<source lang="xml">
 
<source lang="xml">
Line 62: Line 62:
 
   </contactInfo>
 
   </contactInfo>
 
</customer>
 
</customer>
</source>
+
</source>  
  
Note the '''xsi:type''' attribute on the '''contactInfo''' element.
+
Note the '''xsi:type''' attribute on the '''contactInfo''' element.  
  
 +
<br>
  
== Using Substitution Groups ==
+
== Using Substitution Groups ==
  
Another way to model inheritance in XML is through XML Schema's ''substitution groups'' functionality. Using this approach, the element name itself determines which subclass to use.
+
Another way to model inheritance in XML is through XML Schema's ''substitution groups'' functionality. Using this approach, the element name itself determines which subclass to use.  
  
Taking the same example from above, we will add '''@XmlRootElement''' annotations to each of the subclasses, which will act as the inheritance indicator.
+
Taking the same example from above, we will add '''@XmlRootElement''' annotations to each of the subclasses, which will act as the inheritance indicator.  
  
 
<source lang="java">
 
<source lang="java">
Line 92: Line 93:
 
   
 
   
 
}
 
}
</source>
+
</source>  
  
 
+
<br> Using this approach, marshalling an example '''Customer''' would produce the following XML:  
Using this approach, marshalling an example '''Customer''' would produce the following XML:
+
  
 
<source lang="xml">
 
<source lang="xml">
Line 103: Line 103:
 
   </address>
 
   </address>
 
</customer>
 
</customer>
</source>
+
</source>  
  
Note that the '''Address''' object is marshalled to the '''address''' element.
+
Note that the '''Address''' object is marshalled to the '''address''' element.  
  
 +
<br>
  
== Using @XmlDiscriminatorNode / @XmlDiscriminatorValue ==
+
== Using @XmlDiscriminatorNode / @XmlDiscriminatorValue ==
  
You can also use the MOXY-specific '''@XmlDiscriminatorNode''' and '''@XmlDiscriminatorValue''' annotations available in EclipseLink 2.2 to represent inheritance. With this approach, you can select the attribute to represent the subtype.
+
You can also use the MOXY-specific '''@XmlDiscriminatorNode''' and '''@XmlDiscriminatorValue''' annotations available in EclipseLink 2.2 to represent inheritance. With this approach, you can select the attribute to represent the subtype.  
  
Using the same example from above, the '''ContactInfo''' class uses the '''@XmlDiscriminatorNode''' annotation to specify the XML attribute ('''classifier''') that will hold the subclass indicator. '''Address''' and '''PhoneNumber''' are annotated with '''@XmlDiscriminatorValue''', indicating that class' indicator name ('''address-classifier''' and '''phone-number-classifier''').
+
Using the same example from above, the '''ContactInfo''' class uses the '''@XmlDiscriminatorNode''' annotation to specify the XML attribute ('''classifier''') that will hold the subclass indicator. '''Address''' and '''PhoneNumber''' are annotated with '''@XmlDiscriminatorValue''', indicating that class' indicator name ('''address-classifier''' and '''phone-number-classifier''').  
  
 
<source lang="java">
 
<source lang="java">
Line 134: Line 135:
 
   
 
   
 
}
 
}
</source>
+
</source>  
  
 
+
<br> An example '''Customer''' would then produce the following The above sample produces the following XML:  
An example '''Customer''' would then produce the following The above sample produces the following XML:
+
  
 
<source lang="xml">
 
<source lang="xml">
Line 145: Line 145:
 
   </contactInfo>
 
   </contactInfo>
 
</customer>
 
</customer>
</source>
+
</source>  
 
+
Notice that '''Address''' is marshalled to the '''contactInfo''' element. Its '''classifier''' attribute contains the discriminator node value '''address-classifier'''.
+
  
 +
Notice that '''Address''' is marshalled to the '''contactInfo''' element. Its '''classifier''' attribute contains the discriminator node value '''address-classifier'''.
  
 +
<br>
  
 
{{EclipseLink_MOXy
 
{{EclipseLink_MOXy
Line 155: Line 155:
 
|previous= n
 
|previous= n
 
|up=      [[EclipseLink/UserGuide/MOXy|MOXy User Guide]]
 
|up=      [[EclipseLink/UserGuide/MOXy|MOXy User Guide]]
|version=2.2.0 DRAFT}}
+
|version=2.2.0}}

Revision as of 11:38, 4 May 2011

EclipseLink MOXy

Handling Inheritance

EclipseLink MOXy provides several ways to represent your inheritance hierarchy in XML.


Using xsi:type

By default, EclipseLink will use the xsi:type attribute to represent inheritance in XML.

In this example an abstract super class (ContactInfo) contains all types of contact information. Address and PhoneNumber are the concrete implementations of ContactInfo.

public abstract class ContactInfo {
}
 
public class Address extends ContactInfo {
 
   private String street;
   ... 
 
}
 
public class PhoneNumber extends ContactInfo {
 
   private String number;
   ...
 
}


Because the Customer object can have different types of contact information, its property refers to the superclass.

 
@XmlRootElement
public class Customer {
 
   private ContactInfo contactInfo;
   ... 
 
}


Marshalling an example Customer would produce the following XML:

<customer>
   <contactInfo 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:type="address">
      <street>323 Main Street</street>
   </contactInfo>
</customer>

Note the xsi:type attribute on the contactInfo element.


Using Substitution Groups

Another way to model inheritance in XML is through XML Schema's substitution groups functionality. Using this approach, the element name itself determines which subclass to use.

Taking the same example from above, we will add @XmlRootElement annotations to each of the subclasses, which will act as the inheritance indicator.

public abstract class ContactInfo {
}
 
@XmlRootElement
public class Address extends ContactInfo {
 
   private String street;
   ... 
 
}
 
@XmlRootElement
public class PhoneNumber extends ContactInfo {
 
   private String number;
   ...
 
}


Using this approach, marshalling an example Customer would produce the following XML:

<customer>
   <address>
      <street>323 Main Street</street>
   </address>
</customer>

Note that the Address object is marshalled to the address element.


Using @XmlDiscriminatorNode / @XmlDiscriminatorValue

You can also use the MOXY-specific @XmlDiscriminatorNode and @XmlDiscriminatorValue annotations available in EclipseLink 2.2 to represent inheritance. With this approach, you can select the attribute to represent the subtype.

Using the same example from above, the ContactInfo class uses the @XmlDiscriminatorNode annotation to specify the XML attribute (classifier) that will hold the subclass indicator. Address and PhoneNumber are annotated with @XmlDiscriminatorValue, indicating that class' indicator name (address-classifier and phone-number-classifier).

@XmlDiscriminatorNode("@classifier")
public abstract class ContactInfo {
}
 
@XmlDiscriminatorValue("address-classifier")
public class Address extends ContactInfo {
 
   private String street;
   ... 
 
}
 
@XmlDiscriminatorValue("phone-number-classifier")
public class PhoneNumber extends ContactInfo {
 
   private String number;
   ...
 
}


An example Customer would then produce the following The above sample produces the following XML:

<customer>
   <contactInfo classifier="address-classifier">
      <street>323 Main Street</street>
   </contactInfo>
</customer>

Notice that Address is marshalled to the contactInfo element. Its classifier attribute contains the discriminator node value address-classifier.


Eclipselink-logo.gif
Version: 2.2.0
Other versions...