Hi,
assuming that you are using Castor's code generator to generate Java
code from the XML schema definitions (correct me if I am wrong here),
you'll get a batch of Java POJOs that more or less mirror the structures
defined in your schema.
Given that you've got some complexity in there (uses of choices and
sequences and a mix thereof); I'd suggest that you keep things separated
from your domain model. If the XML schema was e.g. part of a WADL
definition, specifying the payload of various REST resources, I'd treat
the generated Java classes as DTOs only, and internally map them to a
model POJO that I'd use (amongst other things) to persist to a database
using Hibernate.
Given that there's always a gap between e.g. the XML schema
specification and your requirements with regards to persistence (domain
model in general), I am always in favour of keeping things apart and
live with the minor overhead of having to convert/map between DTOs and
domain classes.
Does this make sense ?
Kind Regards
Werner
On 18.06.2012 16:45, rednix wrote:
Hi,
I'm struggling with a mapping/unmarshalling of a XML which contains a
sequence with an optional element.
Here is the XSD part for the list:
<xs:element name="relations" maxOccurs="1" minOccurs="0"
type="relationsType">
</xs:element>
<xs:complexType name="relationsType">
<xs:annotation>
<xs:documentation xml:lang="en">Either a set of a lead
project and a
lead-sourcing scope or a set of cosourced projects with an optional sourcing
scope.</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="1" maxOccurs="1">
<xs:sequence minOccurs="1" maxOccurs="1">
<xs:element name="leadProject" type="projectType"
minOccurs="1"
maxOccurs="1"/>
<xs:element name="leadSs" maxOccurs="1" minOccurs="1"
type="ssRefType"/>
</xs:sequence>
<xs:sequence maxOccurs="500" minOccurs="1">
<xs:element name="coProject" maxOccurs="1"
minOccurs="1"
type="projectType">
<xs:annotation>
<xs:documentation
xml:lang="en">CoProject (short for co-sourced
project) names and identifies a co-sourced project.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="coSs" maxOccurs="1" minOccurs="0"
type="ssRefType">
</xs:element>
</xs:sequence>
</xs:choice>
</xs:complexType>
The element coSs is optional and may occur 0 or 1 times.
Here is a snippet of the corresponding XML:
<sourcingScope>
<relations>
<coProject name=">project "full" name<"
short="project short name" id="PROJ_ID"/>
<coSs number="9876-12" id="54987321"/>
<coProject name="blubberbla" short="blubberbla short name"
id="blubber_bla"/>
<coProject name="CoSourced01Vu" short="MVP 02 w/ VU"
id="PROJ_ID_01"/>
<coSs number="9999-99" id="12345678"/>
</relations>
</sourcingScope>
I want coProject and coSs be coupled together on the Java side in one object
in the list. The coupling is defined by the order of the elements. So the
first obj in the list would have PROJ_ID and 54987321; second only
blubber_bla without a coSs info and the third processed like the 1st one.
The thing with the lead choice is an additional case (then there are no
co-elements and exactly two lead elements).
The Java list element (which is actually a hibernate domain object) looks
like this:
public class VuRelation implements java.io.Serializable {
private Long id; // internal id
private SourcingScope sourcingScope; // ref to parent
// set for lead-sourcing
private String leadVuId;
private String leadVuNr;
private String leadProjectId;
private String leadProjectShortName;
private String leadProjectName;
// set for co-sourcing
private String coVuId;
private String coVuNr;
private String coProjectId;
private String coProjectShortName;
private String coProjectName;
... and linked in the main object like this:
public class SourcingScope implements java.io.Serializable {
private Set<VuRelation> relations = new HashSet<VuRelation>();
}
How should the castor mapping look like for this case? How can I "tell"
castor to encapsulate certain elements on the same hierarchy xml level into
one object (combined with optional elements)?
Any help is appreciated!
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
