Re: How to write a simple SDO class for the tutorial?
Sebastien, You're generic implementation is fine as long as TypeHelper.INSTANCE is the right scope where the type is registered. If you aren't interested in supporting dynamic subclasses of static classes, then getStaticType() is always == DataObject.getType(), so you might not even need to implement getStaticType(). Frank Jean-Sebastien Delfino <[EMAIL PROTECTED]> 11/19/2007 11:25 AM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Re: How to write a simple SDO class for the tutorial? kelvin goodson wrote: > I missed you last point in my reply. getStaticType() is required to > underpin fundamental EMF behaviour. Without it EMF's capacity to know > the class of an EObject (which all our DataObjects are derived from) > is broken for all static classes, and that would break many SDO > behaviours, e.g. serialization, copying, and I'm sure lots more. > > Kelvin. > Assuming that my DataObjects are simple classes without interfaces, isn't the type already registered with my DataObject's class? In other words can I implement getStaticType generically as follows: Type getStaticType() { TypeHelper.INSTANCE.getType(this.getClass()); } -- Jean-Sebastien - 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]
Re: How to write a simple SDO class for the tutorial?
kelvin goodson wrote: I missed you last point in my reply. getStaticType() is required to underpin fundamental EMF behaviour. Without it EMF's capacity to know the class of an EObject (which all our DataObjects are derived from) is broken for all static classes, and that would break many SDO behaviours, e.g. serialization, copying, and I'm sure lots more. Kelvin. Assuming that my DataObjects are simple classes without interfaces, isn't the type already registered with my DataObject's class? In other words can I implement getStaticType generically as follows: Type getStaticType() { TypeHelper.INSTANCE.getType(this.getClass()); } -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to write a simple SDO class for the tutorial?
kelvin goodson wrote: Sebastien, There's the basis of a Java interface to SDO generator at [1] but it hasn't been developed to a working state and hasn't been looked since the initial drop of code into Tuscany. It would be great to get this or similar function up and running. If you take a look at the noInterfaces test [2] of the toolsTest project you'll see that we don't need interfaces, we can use classes. I think in the scenario that you paint it's just abut possible you may just about be able to get away without a factory. As evidence I changes the referenced sample [2] to have //com.example.noInterfaces.simple.Quote quote = //(com.example.noInterfaces.simple.Quote)scope.getDataFactory().create(com.example.noInterfaces.simple.Quote.class); com.example.noInterfaces.simple.Quote quote = new Quote(); and the test passed. But this wouldn't be acceptable in general. The major showstopper that occurs to me instantly is having a Type that has a Property of a generated Type. so the call to myComplexType.createDataObject("myPropertyOfGeneratedType"); must have a means to create a child DataObject using the generated class rather than the generic DataObject. It does this by maintaining an association with the Type of the Property and the associated Factory. If the Type already has an association with the corresponding class (and I think it does if the DataObject is represented by a class and not an interface) then again we would not need the factory, right? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to write a simple SDO class for the tutorial?
Hi Sebastien, One thing to note is that the static SDO supported in Tuscany today is an EMF-style pattern that is intended to be the highest performance in-memory static DataObjects. Other less-performant patterns, that use a dynamic (DataObject) proxy, for example, are possible and probably easier achieve without a code generator. There are two features in the SDO 3 charter related to this topic: 1) standard SDO annotations on Java interfaces to define SDO metadata, and 2) unify static SDO with other static bindings like JAXB (this covers POJOs as well). If you want to experiment with some ideas in this area, that would be great. We could use it as input to the SDO 3 discussions when they start. Thanks, Frank. [EMAIL PROTECTED] wrote on 11/19/2007 05:53:25 AM: > I missed you last point in my reply. getStaticType() is required to > underpin fundamental EMF behaviour. Without it EMF's capacity to know > the class of an EObject (which all our DataObjects are derived from) > is broken for all static classes, and that would break many SDO > behaviours, e.g. serialization, copying, and I'm sure lots more. > > Kelvin. > > On 17/11/2007, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > kelvin goodson wrote: > > > If you are discounting using XSD for the source of metadata to > > > describe the SDO types then there is the SDO API provided for dynamic > > > metadata creation. The sample at [1] gives an introduction to this. > > > The paper at [2] discusses the subject also, and the program > > > underlying the discussion in the paper is at [3] (no change > > > monitoring) and [4] (with change monitoring). > > > > > > You say that you want to write the minimum code. There is a quick and > > > simple Tuscany API for simple cases that you could use instead (See > > > the MetaDataBuilder inner class in [5]). Whilst the code to create > > > the type system with this project specific API is simple to understand > > > and implement it has some drawbacks. We don't have a sample program > > > for this, but I believe the DAS uses it) I'm happy to discuss further > > > if you want some more insight into this. > > > > > > Kelvin. > > > > > > > > > [1] http://svn.apache. > org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample. > java > > > [2] http://java.sys-con.com/read/358059_2.htm > > > [3] http://svn.apache. > org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario. > java > > > [4] http://svn.apache. > org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring. > java > > > [5] http://svn.apache. > org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper. > java > > > > > > > > Thanks. > > > > Follow-up questions: > > > > - Is there an SDO Helper that can introspect my handwritten Item Java > > class and drive the calls to the TypeHelper APIs? If not, can I add one? > > > > - I see that I can associate a class with a type, does it have to be an > > interface or can it be a class? > > > > - If it can be a class do I really need a factory class or is the SDO > > runtime able to instantiate the class? > > > > - I see methods like getStaticType on generated SDOs, do I need to > > implement that method in my handwritten SDO and why? > > > > -- > > Jean-Sebastien > > > > > > - > > 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]
Re: How to write a simple SDO class for the tutorial?
I missed you last point in my reply. getStaticType() is required to underpin fundamental EMF behaviour. Without it EMF's capacity to know the class of an EObject (which all our DataObjects are derived from) is broken for all static classes, and that would break many SDO behaviours, e.g. serialization, copying, and I'm sure lots more. Kelvin. On 17/11/2007, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > kelvin goodson wrote: > > If you are discounting using XSD for the source of metadata to > > describe the SDO types then there is the SDO API provided for dynamic > > metadata creation. The sample at [1] gives an introduction to this. > > The paper at [2] discusses the subject also, and the program > > underlying the discussion in the paper is at [3] (no change > > monitoring) and [4] (with change monitoring). > > > > You say that you want to write the minimum code. There is a quick and > > simple Tuscany API for simple cases that you could use instead (See > > the MetaDataBuilder inner class in [5]). Whilst the code to create > > the type system with this project specific API is simple to understand > > and implement it has some drawbacks. We don't have a sample program > > for this, but I believe the DAS uses it) I'm happy to discuss further > > if you want some more insight into this. > > > > Kelvin. > > > > > > [1] > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample.java > > [2] http://java.sys-con.com/read/358059_2.htm > > [3] > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java > > [4] > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring.java > > [5] > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java > > > > > Thanks. > > Follow-up questions: > > - Is there an SDO Helper that can introspect my handwritten Item Java > class and drive the calls to the TypeHelper APIs? If not, can I add one? > > - I see that I can associate a class with a type, does it have to be an > interface or can it be a class? > > - If it can be a class do I really need a factory class or is the SDO > runtime able to instantiate the class? > > - I see methods like getStaticType on generated SDOs, do I need to > implement that method in my handwritten SDO and why? > > -- > Jean-Sebastien > > > - > 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]
Re: How to write a simple SDO class for the tutorial?
Sebastien, There's the basis of a Java interface to SDO generator at [1] but it hasn't been developed to a working state and hasn't been looked since the initial drop of code into Tuscany. It would be great to get this or similar function up and running. If you take a look at the noInterfaces test [2] of the toolsTest project you'll see that we don't need interfaces, we can use classes. I think in the scenario that you paint it's just abut possible you may just about be able to get away without a factory. As evidence I changes the referenced sample [2] to have //com.example.noInterfaces.simple.Quote quote = //(com.example.noInterfaces.simple.Quote)scope.getDataFactory().create(com.example.noInterfaces.simple.Quote.class); com.example.noInterfaces.simple.Quote quote = new Quote(); and the test passed. But this wouldn't be acceptable in general. The major showstopper that occurs to me instantly is having a Type that has a Property of a generated Type. so the call to myComplexType.createDataObject("myPropertyOfGeneratedType"); must have a means to create a child DataObject using the generated class rather than the generic DataObject. It does this by maintaining an association with the Type of the Property and the associated Factory. Regards, Kelvin. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/Interface2JavaGenerator.java [2] http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/tools-test/src/test/java/org/apache/tuscany/sdo/test/GenPatternsTestCase.java?view=markup On 17/11/2007, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > kelvin goodson wrote: > > If you are discounting using XSD for the source of metadata to > > describe the SDO types then there is the SDO API provided for dynamic > > metadata creation. The sample at [1] gives an introduction to this. > > The paper at [2] discusses the subject also, and the program > > underlying the discussion in the paper is at [3] (no change > > monitoring) and [4] (with change monitoring). > > > > You say that you want to write the minimum code. There is a quick and > > simple Tuscany API for simple cases that you could use instead (See > > the MetaDataBuilder inner class in [5]). Whilst the code to create > > the type system with this project specific API is simple to understand > > and implement it has some drawbacks. We don't have a sample program > > for this, but I believe the DAS uses it) I'm happy to discuss further > > if you want some more insight into this. > > > > Kelvin. > > > > > > [1] > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample.java > > [2] http://java.sys-con.com/read/358059_2.htm > > [3] > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java > > [4] > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring.java > > [5] > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java > > > > > Thanks. > > Follow-up questions: > > - Is there an SDO Helper that can introspect my handwritten Item Java > class and drive the calls to the TypeHelper APIs? If not, can I add one? > > - I see that I can associate a class with a type, does it have to be an > interface or can it be a class? > > - If it can be a class do I really need a factory class or is the SDO > runtime able to instantiate the class? > > - I see methods like getStaticType on generated SDOs, do I need to > implement that method in my handwritten SDO and why? > > -- > Jean-Sebastien > > > - > 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]
Re: How to write a simple SDO class for the tutorial?
kelvin goodson wrote: If you are discounting using XSD for the source of metadata to describe the SDO types then there is the SDO API provided for dynamic metadata creation. The sample at [1] gives an introduction to this. The paper at [2] discusses the subject also, and the program underlying the discussion in the paper is at [3] (no change monitoring) and [4] (with change monitoring). You say that you want to write the minimum code. There is a quick and simple Tuscany API for simple cases that you could use instead (See the MetaDataBuilder inner class in [5]). Whilst the code to create the type system with this project specific API is simple to understand and implement it has some drawbacks. We don't have a sample program for this, but I believe the DAS uses it) I'm happy to discuss further if you want some more insight into this. Kelvin. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample.java [2] http://java.sys-con.com/read/358059_2.htm [3] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java [4] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring.java [5] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java Thanks. Follow-up questions: - Is there an SDO Helper that can introspect my handwritten Item Java class and drive the calls to the TypeHelper APIs? If not, can I add one? - I see that I can associate a class with a type, does it have to be an interface or can it be a class? - If it can be a class do I really need a factory class or is the SDO runtime able to instantiate the class? - I see methods like getStaticType on generated SDOs, do I need to implement that method in my handwritten SDO and why? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to write a simple SDO class for the tutorial?
If you are discounting using XSD for the source of metadata to describe the SDO types then there is the SDO API provided for dynamic metadata creation. The sample at [1] gives an introduction to this. The paper at [2] discusses the subject also, and the program underlying the discussion in the paper is at [3] (no change monitoring) and [4] (with change monitoring). You say that you want to write the minimum code. There is a quick and simple Tuscany API for simple cases that you could use instead (See the MetaDataBuilder inner class in [5]). Whilst the code to create the type system with this project specific API is simple to understand and implement it has some drawbacks. We don't have a sample program for this, but I believe the DAS uses it) I'm happy to discuss further if you want some more insight into this. Kelvin. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample.java [2] http://java.sys-con.com/read/358059_2.htm [3] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java [4] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring.java [5] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java On 13/11/2007, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > The online store tutorial currently uses a simple handwritten JavaBean > to represent the Items in the store catalog and shopping cart. I'm able > to flow that Item bean over local calls, WS, Atom and JSON bindings. > > Here's what it looks like: > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tutorial/assets/services/Item.java > Note: the "implements Serializable" is a work around and should be > eventually removed. > > If I want to start using SDO in the tutorial, make that Item an SDO and > write it by hand (with my user hat on, I'm going to assume that I don't > know what XSD is about), what is the minimum code that I need to write? > > Thanks > > -- > Jean-Sebastien > > > - > 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]