Miro,
You're right. The generated method is a little more complicated than I
said. The generated getCircle() method would actually look something like
this:
Circle getCircle() { if (getContainmentProperty() !=
getProperty_Circle_points()) return null; return (Circle)getContainer(); }
And the getPolygon() method, if also requested, would look like this:
Polygon getPolygon() { if (getContainmentProperty() !=
getProperty_Polygon_points()) return null; return (Polygon)getContainer();
}
Note that EMF works exactly this way.
Frank
"Miro Kandic \(mkandic\)" <[EMAIL PROTECTED]> wrote on 09/17/2007 02:42:10
PM:
> Frank,
>
> maybe solution for the representation of composition (containment)
> in XSD and SDO is not so simple.
> Recall that one class in UML class diagram can be part of many
> compositions but instance of that class, in the run-time, can be
> part of only one whole/assembly object (well known example with
> class Point that can be part in run-time of either Polygon or Circle
> but not both in the same time).
>
> So this would not be solution for this design problem:
> <xsd:element name="points" type="impl:Point"
> sdojava:getContainer="getCircle" minOccurs="0" maxOccurs="unbounded" />
>
> because we do not know what is class of point's container in advance.
>
> ((DataObject)point.getContainer() should return object either of
> Circle or Polygon type and one of static API methods point.
> getCyrcle() or point.GetPolygon() will return null and other method
> will return something.
>
> I am developing DAS for JPA (EJB 3.0) where DAS accepts set of EJB-
> QL queries and returns SDO DataGraph (also applyChanges in opposite
> direction) and developing that graph-to-graph transformation of
> POJOs graph (not tree) to SDO graph (should be graph not tree) I saw
> couple of missing peaces in SDO specification and technology and I
> will try to compile that and come back as soon as I can.
>
> Regards,
> Miro.
>
>
>
> Miro Kandic
> (408)525-2596
>
>
>
> -----Original Message-----
> From: Frank Budinsky [mailto:[EMAIL PROTECTED]
> Sent: Mon 9/17/2007 11:01 AM
> To: [email protected]
> Subject: RE: XSD2JavaGenerator and non-containment references
>
> Miro,
>
> You are right. Bidirectional references are broken in Tuscany. They seem
> to have been broken when we switched over to the new (noEMF) codegen
> patterns. I guess nobody uses them much and we don't have a test case.
Can
> you please open a JIRA bug report to track this?
>
> I understand your point about wanting a static (non SDO dependent) way
to
> navigate to the container. I think this is something that we should try
to
> change in the next version of SDO. Maybe something like this:
>
> <xsd:element name="lines" type="impl:SoL"
> sdojava:getContainer="getOrder" minOccurs="0" maxOccurs="unbounded" />
>
> Maybe for now in Tuscany, we could just always generate a static method
> for getContainer equal to "get" + <container type name>. For example, we
> would generate:
>
> SoH getSoH() { return (SoH)getContainer(); }
>
> in class SoLImpl. This wouldn't be standard SDO, but a generator is
> allowed to generate additional implementation-specific methods and still
> be considered compliant.
>
> Frank
>
> "Miro Kandic \(mkandic\)" <[EMAIL PROTECTED]> wrote on 09/17/2007
01:09:38
> PM:
>
> > Frank,
> >
> > actually XSD2JavaGenerator does not work in the case of any
> > association type that is navigable from both sides.
> > I have intentionally, just to test generator, made Customer-SoH
> > association navigable from both sides and generated code again
> > cannot be compiled.
> >
> > Regarding your comments on bidirectional references and
> > containments, I know I can get container using dynamic SDO API but I
> > don't want to see in a code that implements business logic any code
> > that is related to protocols or data implementation technologies.
> > Packing data to SOAP envelop or sendig data over IIOP is job of
> > stubs and scaletons and main stream priogrammer should not ever cast
> > object to classes related to those techologies. Based on the same
> > principales, business programmer should not be avere that object
> > he/she is dealing with is actually instance of some Hybernate proxy
> > or SDO DataObject and should not ever cast those objects to
> > mentioned classes unless he/she develops some tools or similar
> > generic software.
> > And I do not want to use any dynamic API if I don't have to, so I
> > prefer to have typed Java API and SDO specification explicitally
> > lists that support as one of the major requirements. So SDO should
> > support static API defined by XSD schema.
> > I think Java business programmer should be familiar with UML class
> > diagrams that define domain and should get only corresponding POJOs
> > to deal with. Code dealing with data transport or object
> > distribution or data persistance, where BTW one technology is "cool"
> > today and next day another one, should be hidden in adapters,
> > skeletons and stubs.
> >
> > Next is complete XSD built automatically from attached UML.
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <!--
> Attention: Generated code! Do not modify by hand!
> > Generated by: XmlSchema.vsl in andromda-xmlschema-cartridge.
> > -->
> > <xsd:schema
> > targetNamespace="http://www.cisco.com/odns/soa";
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> > xmlns:sdo="commonj.sdo" xmlns:sdoxml="commonj.sdo/xml"
> > xmlns:impl="http://www.cisco.com/odns/soa";
> > elementFormDefault="qualified">
> >
> > <xsd:import namespace="commonj.sdo/xml"
> schemaLocation="sdoXML.xsd"/>
> >
> > <xsd:complexType name="Address">
> > <xsd:sequence>
> > <xsd:element name="street" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="city" type="xsd:string" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="Customer">
> > <xsd:sequence>
> > <xsd:element name="orders" type="xsd:IDREF" sdoxml:
> > propertyType="impl:SoH"
> > sdoxml:oppositeProperty="customer" minOccurs="0"
> > maxOccurs="unbounded" />
> > <xsd:element name="name" type="xsd:string" minOccurs="1"
> > maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="Part">
> > <xsd:sequence>
> > <xsd:element name="uom" type="xsd:string" minOccurs="1"
> > maxOccurs="1"/>
> > <xsd:element name="aggState" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="Product">
> > <xsd:complexContent>
> > <xsd:extension base="impl:Part">
> > <xsd:sequence>
> > <xsd:element name="description" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > </xsd:sequence>
> > </xsd:extension>
> > </xsd:complexContent>
> > </xsd:complexType>
> >
> > <xsd:complexType name="SoH">
> > <xsd:sequence>
> > <xsd:element name="customer" type="xsd:IDREF" sdoxml:
> > propertyType="impl:Customer"
> > sdoxml:oppositeProperty="orders" minOccurs="1"
> > maxOccurs="1" />
> > <xsd:element name="lines" type="impl:SoL" minOccurs="0"
> > maxOccurs="unbounded" />
> > <xsd:element name="number" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="receivedDate" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="SoL">
> > <xsd:sequence>
> > <xsd:element name="product" type="xsd:IDREF" sdoxml:
> > propertyType="impl:Product"
> > sdoxml:oppositeProperty="soLs" minOccurs="1"
> maxOccurs="1" />
> > <xsd:element name="soLineSch" type="impl:SoLSch"
> > minOccurs="0" maxOccurs="unbounded" />
> > <xsd:element name="quantity" type="xsd:double"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="requestedDate" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="SoLSch">
> > <xsd:sequence>
> > <xsd:element name="requestedDate" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="quantity" type="xsd:double"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="modifiedBy" type="xsd:string"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="created" type="xsd:date"
> > minOccurs="1" maxOccurs="1"/>
> > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > maxOccurs="1"/>
> > </xsd:sequence>
> > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > </xsd:complexType>
> >
> > <xsd:element name="DataGraphRootEl" type="impl:DataGraphRoot"/>
> > <xsd:complexType name="DataGraphRoot">
> > <xsd:sequence>
> > <xsd:element name="customer" type="impl:Customer"
> > minOccurs="0" maxOccurs="unbounded" />
> > <xsd:element name="product" type="impl:Product"
> > minOccurs="0" maxOccurs="unbounded" />
> > <xsd:element name="part" type="impl:Part" minOccurs="0"
> > maxOccurs="unbounded" />
> > <xsd:element name="soH" type="impl:SoH" minOccurs="0"
> > maxOccurs="unbounded" />
> > </xsd:sequence>
> > </xsd:complexType>
> >
> > </xsd:schema>
> >
> >
> >
> > Miro
> >
> >
> >
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:[EMAIL PROTECTED]
> > Sent: Mon 9/17/2007 7:49 AM
> > To: [email protected]
> > Subject: Re: XSD2JavaGenerator and non-containment references
> >
> > Miro,
> >
> > Both sides of a relationship defined with sdoXML:oppositeProperty need
> to
> > be non-containment references. All containment references are
implicitly
> > bidirectional (the reverse is the elements container), so you wouldn't
> > really want to use an IDREF element anyway - it's just duplicate
> > information.
> >
> > To get the SoH from an SoL, you can call:
> >
> > SoH soh = (SoH)sol.getContainer();
> >
> > You could manually add a getOrder() (convenience) method in the
> generated
> > class like this:
> >
> > SoH getOrder() { return (SoH)getContainer(): }
> >
> > EMF has a way to generate this kind of method for you, but there's no
> > support for this in SDO.
> >
> > Frank.
> >
> > "Miro Kandic \(mkandic\)" <[EMAIL PROTECTED]> wrote on 09/14/2007
> 08:40:40
> > PM:
> >
> > > I am having a problem with new XSD2JavaGenerator (M2 was OK) and it
> > > generates code that cannot be compiled in case when container
> > > element has non-containment reference to the container.
> > > Entire xsd file is attched.
> > > In this case I want to use static API and I want to get sales order
> > > header (SoH) from its lines (SoL) using the same Java code (getter)
> > > as in case when I use corresponding POJO's.
> > > It works fine if property is non-containment reference to no
> > > container class (SoL references product or SoH references Customer).
> > >
> > > I am a new in this community and I do not know if this is considered
> > > as a bug who and how should open it. Please, advise.
> > >
> > > <xsd:complexType name="SoH">
> > > <xsd:sequence>
> > > <xsd:element name="customer" type="xsd:IDREF" sdoxml:
> > > propertyType="impl:Customer" sdoxml:oppositeProperty="soHs"
> > > minOccurs="1" maxOccurs="1" />
> > > <xsd:element name="lines" type="impl:SoL" minOccurs="0"
> > > maxOccurs="unbounded" />
> > > <xsd:element name="number" type="xsd:string"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="receivedDate" type="xsd:date"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="modifiedBy" type="xsd:string"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="created" type="xsd:date"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > > maxOccurs="1"/>
> > > </xsd:sequence>
> > > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > > </xsd:complexType>
> > >
> > > <xsd:complexType name="SoL">
> > > <xsd:sequence>
> > > <xsd:element name="order" type="xsd:IDREF" sdoxml:
> > > propertyType="impl:SoH" sdoxml:oppositeProperty="lines"
> > > minOccurs="1" maxOccurs="1" />
> > > <xsd:element name="product" type="xsd:IDREF" sdoxml:
> > > propertyType="impl:Product" sdoxml:oppositeProperty="soLs"
> > > minOccurs="1" maxOccurs="1" />
> > > <xsd:element name="soLineSch" type="impl:SoLSch"
> > > minOccurs="0" maxOccurs="unbounded" />
> > > <xsd:element name="quantity" type="xsd:double"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="requestedDate" type="xsd:date"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="modifiedBy" type="xsd:string"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="lastUpdated" type="xsd:dateTime"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="created" type="xsd:date"
> > > minOccurs="1" maxOccurs="1"/>
> > > <xsd:element name="id" type="xsd:long" minOccurs="1"
> > > maxOccurs="1"/>
> > > </xsd:sequence>
> > > <xsd:attribute name="xmlId" type="xsd:ID"/>
> > > </xsd:complexType>
> > >
> > > Regards,
> > > Miro
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
