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]
