You are welcome. Now, if you are still happy by tomorrow (after you have
tried your more complex use cases), I'd appreciate if you helped us a
little bit by providing us with some input for e.g. a HOW-TO document
for using Castor in a polymorphic situation. Is that something I can
count on ?

Werner

Ander Garcia Gangoiti wrote:
> Thanks for your help. I have managed to map a simple case using
> polymorphism, tomorrow aI will try a more advanced example that address my
> needs.
> 
> Regards
> 
> Ander 
> 
> -----Mensaje original-----
> De: Werner Guttmann [mailto:[EMAIL PROTECTED] 
> Enviado el: martes, 22 de mayo de 2007 15:44
> Para: [email protected]
> Asunto: AW: [castor-user][xml] conditional unmarshalling
> 
> Ander,
> 
> Castor supports polymorphism out of the box without having to resort to
> (such conditional) constructs as shown below. In other words, imagine you’d
> have XML similar to 
> 
> <beings>
>     <person>
>         <name>Ander</name>
>     <person>
> </contact>
> <contact type="pet">
>     <animal>
>         <type>dog</type>
>         <name>Fibi</name>
>     <animal>
> </beings>
> 
> Given there’s complete class mappings for <person> and <animal> classes,
> Castor will be able to deal with this automagically. Have a look at 
> 
> http://www.castor.org/xml-mapping.html#5.-xsi:type
> 
> in particular for a more detailed explanation.
> 
> Werner
> 
> 
> ________________________________________
> Von: Ander Garcia Gangoiti [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 22. Mai 2007 10:06
> An: [email protected]
> Betreff: [castor-user][xml] conditional unmarshalling
> 
> Dear All
>  
> I have an xml file similar to the following one, where a nested element
> depends on and attribute of its father :
>  
> <contact type="friend">
>     <person>
>         <name>Ander</name>
>     <person>
> </contact>
> <contact type="pet">
>     <animal>
>         <type>dog</type>
>         <name>Fibi</name>
>     <animal>
> </contact>
>  
> I would like to express:
> if (contact_type =friend)
>     marshall/unmarshall person
> if (contact_type =pet)
>     marshall/unmarshall pet
>  
> Is it possible to express this conditional marshalling on the mapping file?
> Is there any other way to do it?
>  
> Thank you very much
>  
> Ander
> 
> ________________________________________
> De: Justin Permar [mailto:[EMAIL PROTECTED] Enviado el: martes, 22 de
> mayo de 2007 5:40
> Para: [email protected]
> Asunto: [castor-user] code generation: schema type restriction "re-defines"
> the type of an attribute from the base type All,
> 
> I am using Castor to generate classes directly from a rather large and
> complex schema. I use automatic conflict resolution set to true as part of
> the following binding properties:
> 
> org.exolab.castor.builder.javaclassmapping=type
> org.exolab.castor.builder.javaVersion=5.0
> org.exolab.castor.builder.automaticConflictResolution=true
> 
> Nearly all the code that is generated works very well, but there is just one
> type of definition in the schema that Castor seems to have a bit of trouble
> with.
> 
> I have a type that is defined as follows:
> 
> <xs:complexType name="ON" mixed="true">
>                         <xs:annotation>
>                                     <xs:documentation>
>                                     A name for an organization. A sequence
> of name parts.
>                                     </xs:documentation>
>                         </xs:annotation>
>                         <xs:complexContent mixed="true">
>                                     <xs:restriction base="EN">
>                                                 <xs:sequence>
>                                                             <xs:choice
> minOccurs="0" maxOccurs="unbounded">
>                                                                        
> <xs:element name="delimiter">
>                                                                             
>         <xs:complexType mixed="true">
>                                                                             
>                     <xs:complexContent mixed="true">
>                                                                             
>                                 <xs:restriction base="en.del">
>                                                                             
>                                             <xs:attribute name="partType"
> type="cs_OrganizationNamePartType" fixed="DEL"/>                   <!—This
> partType “overrides” the partType in en.del with a new type
> cs_OrganizationNamePartType ?
>                                                                             
>                                 </xs:restriction>
>                                                                             
>                     </xs:complexContent>
>                                                                             
>         </xs:complexType>
>                                                                        
> </xs:element>
>                         … <!—snip ?
> </xs:complexType>
> 
> Note that the above element named “delimiter” is a restriction of a type
> named “en.del”. This type is defined as follows:
> 
>             <xs:complexType name="en.del" mixed="true">
>                         <xs:complexContent mixed="true">
>                                     <xs:restriction base="ENXP">
>                                                 <xs:attribute
> name="partType" type="cs_EntityNamePartType" fixed="DEL"/> 
> <!—cs_EntityNamePartType is the type specified for this attribute here ?
>                                     </xs:restriction>
>                         </xs:complexContent>
>             </xs:complexType>
> 
> Notice that attribute “partType” is defined in the “en.del” complexType and
> also “re-defined” in “delimiter” element in the complex type “ON”. I say
> re-defined because the type of the attribute named “partType” is
> “cs_EntityNamePartType” in the “en.del” complex type, whereas it is of type
> “cs_OrganizationNamePartType” in the “delimiter” attribute in the complex
> type named “ON”.
> 
> I’m sure you can already tell that this is quite “suspicious”!
> 
> When I try to generate code for the ON complex type, there is something like
> this that is the output:
> 
> public class ONDelimiter extends castor.test.En_del implements
> java.io.Serializable {
> 
> 
>       //----------------/
>      //- Constructors -/
>     //----------------/
> 
>     public ONDelimiter() {
>         super();
>        
> setPartType(castor.test.types.Cs_OrganizationNamePartType.valueOf("DEL"));  
>   ///ERROR!!!!
>         setContent("");
>     }
> 
> … <snip>
> 
> Now, the En_del class is generated with a method of the following signature:
> 
>     /**
>      * Field _partType.
>      */
>     private castor.test.types.Cs_EntityNamePartType _partType =
> castor.test.types.Cs_EntityNamePartType.valueOf("DEL");
> 
> 
>       //----------------/
>      //- Constructors -/
>     //----------------/
> 
>     public En_del() {
>         super();
>         setPartType(castor.test.types.Cs_EntityNamePartType.valueOf("DEL"));
>         setContent("");
>     }
> 
> 
>       //-----------/
>      //- Methods -/
>     //-----------/
> 
>       <snip!>
> 
>     /**
>      * Returns the value of field 'partType'.
>      * 
>      * @return the value of field 'PartType'.
>      */
>     public castor.test.types.Cs_EntityNamePartType getPartType(
>     ) {
>         return this._partType;
>     }
> 
>       <snip!>
> 
>     /**
>      * Sets the value of field 'partType'.
>      * 
>      * @param partType the value of field 'partType'.
>      */
>     public void setPartType(
>             final castor.test.types.Cs_EntityNamePartType partType) {
>         this._partType = partType;
>     }
> 
> <snip!>
> 
> Of course the ONDelimiter class extends from the En_del class. The En_del
> class has a field named _partType that is of type
> castor.test.types.Cs_EntityNamePartType. Because ONDelimiter subclasses
> En_del, it can’t set _partType to a
> castor.test.types.Cs_OrganizationNamePartType instance like it attempts to
> in the ONDelimiter constructor. And the ONDelimiter class has no field of
> that type either.
> 
> If it helps, here are the definition of Cs_EntityNamePartType and
> Cs_OrganizationNamePartType snippets of the schema:
> 
>             <xs:simpleType name="cs_EntityNamePartType">
>                         <xs:restriction base="cs">
>                                     <xs:enumeration value="FAM"/>
>                                     <xs:enumeration value="GIV"/>
>                                     <xs:enumeration value="PFX"/>
>                                     <xs:enumeration value="SFX"/>
>                                     <xs:enumeration value="DEL"/>
>                         </xs:restriction>
>             </xs:simpleType>
> 
>             <xs:simpleType name="cs_OrganizationNamePartType">
>                         <xs:restriction base="cs_EntityNamePartType">
>                                     <xs:enumeration value="PFX"/>
>                                     <xs:enumeration value="SFX"/>
>                                     <xs:enumeration value="DEL"/>
>                         </xs:restriction>
>             </xs:simpleType>
> 
> 
> 
> I’m hoping that you might be able to help me with either a workaround
> (changing the code directly is ok with me because this is the only type of
> error in the Castor-generated code). I say “type” of error because this
> schema has this kind of definition a number of places and the errors are all
> similar. Of course, if there is a modification to the binding file that I
> can make for either of these types then that is better! One idea might be to
> not have one type extend from another, and just have all the classes
> separate concrete classes. Is that a possibility in Castor?
> 
> Thank you in advance for taking some time with this matter. I appreciate any
> feedback and/or help you can give me.
> 
> ----------------------------------------------
> Justin Permar
> Research Programmer
> Department of Biomedical Informatics
> The Ohio State University
> 


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply via email to