Kelvin, Frank,
Great - Thanks for all the insight. I wrote
most of the DAS LDAP Design Guide using references
to EMF concepts, so I'll start using this to convert over.
Thanks again,
- Ole
kelvin goodson wrote:
> Ole,
> the HelperContext acts as a high level scope for types. To create
types
> dynamically using the SDO 2.1 API you would get the TypeHelper instance
> from
> a HelperContext instance and use one of the TypeHelper.define
methods to
> create types within the scope of the HelperContext.
>
> There is also Tuscany specific interface on the SDOUtil class that
allows
> creation of types more in the style you show above, using a TypeHelper
> instance to control the scope of the new types. In this case the new
types
> are available to the HelperContext to which the TypeHelper instance
> belongs,
> and all its associated helpers.
>
> The SDO API variant method offers solutions to the issues encountered
when
> creating type systems which have cross references, which can't be
achieved
> with the Tuscany interface. It also deals with achieving a state
whereby a
> newly created type is known to be finalized. The Tuscany API is a
quick
> method for defining types when these considerations are not important.
>
> Regards, Kelvin.
>
> On 09/04/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:
>>
>> Hope it's ok that I piggy back with a somewhat related question.
>>
>> Does SDO a container for Type instances (the equivalent to an EMF
>> EPackage)?
>>
>> In the EMF API I would do something like
>>
>> DataType dataType = EcoreFactory.eINSTANCE.createDataType();
>> //Initialize the dataType
>> //Add it to an ePackage containing all the model's Types
>> ePackage.eClassifiers.add(dataType);
>>
>> Thanks,
>> - Ole
>>
>>
>>
>> Scott Kurz wrote:
>> > Thanks Fuhwei, Frank that helps me under the SDO view of the
built-in
>> > types.
>> >
>> > I wonder how useful it would be to allow WSDL2Java to generate a
Type,
>> > then,
>> > instead of an int or String, when the "-dynamicSDO" option is
chosen.
>> >
>> > There would need to be some runtime databinding-sdo support for this
>> option
>> > too, I'd think.
>> >
>> > Interesting but I'm probably going to drop this train of thought for
>> now...
>> >
>> > Scott
>> >
>> > On 4/9/07, Fuhwei Lwo <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Scott,
>> >>
>> >> SDO built-in types were defined in the sdoModel.xsd under
>> >> tuscany/java/spec/sdo-api/src/main/resources/xml directory. The
>> >> mapping from
>> >> XSD to Java is described in the spec section 9.4.
>> >>
>> >> The instances of SDO built-in types will be instances of
>> >> commonj.sdo.Type.
>> >> So if you have a SDO type for xsd:int, the name of the
>> >> commonj.sdo.Typeinstance will be "Int".
>> >>
>> >> Hope this helps.
>> >>
>> >> Scott Kurz <[EMAIL PROTECTED]> wrote: This is maybe an SDO for
>> dummies
>> >> question.
>> >>
>> >> Are there any built-in SDO types, say, corresponding to int
which I
>> can
>> >> work with as a generic DataObject in the manner that
>> java.lang.Integeris
>> >> a
>> >> java.lang.Object
>> >> corresponding to int? (I'm not seeing anything from a quick
scan of
>> the
>> >> source or spec to suggest that there is.)
>> >>
>> >> Or is the simplest DataObject one can create a user-defined,
>> complexType
>> >> wrappering a single int?
>> >>
>> >> Thanks,
>> >> Scott
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> 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]
