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]
