Home » Modeling » EMF » creating a String EObject?
| creating a String EObject? [message #394454] |
Wed, 20 July 2005 13:20  |
Eclipse User |
|
|
|
I'm sure I've just missed this somewhere, so my apologies, but I can't
find it.
I have a method foo(EObject param). I would like to call it with a
String value. I can't just say foo("hello"), obviously. So...
How do I create an EObject from a String? I can't find any subtype of
EObject that represents strings, nor any conversion/factory method that
will take a String and produce some EObject.
Many thanks, and apologies again for what I'm certain is an idiotic
question,
Peri
|
|
|
| Re: creating a String EObject? [message #394456 is a reply to message #394454] |
Wed, 20 July 2005 14:56  |
| Eclipse User |
|
|
|
Peri,
What's in the string? Does it need to be parsed? EObjects aren't used
to represent strings. They can have features that hold strings...
It's possible to use org.eclipse.emf.ecore.xml.type.SimpleAnyType to
hold a String; you'd need to create one, set it's instance type to
something like EcorePackage.eINSTANCE.getEString() or
XMLTypePackage.eINSTANCE.getString(), and then set the value. But I
really have no idea what you are trying to accomplish, so I don't know
how to answer this...
Peri Tarr wrote:
> I'm sure I've just missed this somewhere, so my apologies, but I can't
> find it.
>
> I have a method foo(EObject param). I would like to call it with a
> String value. I can't just say foo("hello"), obviously. So...
>
> How do I create an EObject from a String? I can't find any subtype of
> EObject that represents strings, nor any conversion/factory method
> that will take a String and produce some EObject.
>
> Many thanks, and apologies again for what I'm certain is an idiotic
> question,
>
> Peri
|
|
|
| Re: creating a String EObject? [message #394491 is a reply to message #394456] |
Thu, 21 July 2005 18:23 |
| Eclipse User |
|
|
|
Hi Ed,
> What's in the string? Does it need to be parsed?
No, it's just a string value. I have a generic data type that's kind of
like Set (it isn't Set, but Set is simpler and the problem is the
same)--it provides a set of services over most kinds of objects in
general (Sets store objects; we maintain ontologies and other
information about objects, but the type of the object is irrelevant for
our purposes, just as it is for Sets). In Java without EMF, I would
allow the services to be provided for any subtype of java.lang.Object;
for example, I can say s.add("myString") to some Set s. In Java with
EMF, I'd like to allow the services to be provided for any EObject
instead, to ensure that the actual objects for which we provide the
services are serializable. This works fine for most of the types of
objects for which we're providing this service.
However, we ran into a problem with the Java primitive types, like
String. In an EMF world, I don't see how to write the signature of a
method like add() and enable us to pass a String as a value. Our
choices appeared to be:
1. Define it as add(Object o), and have to deal with the
serialization issue on java.lang.Object. This seems like a bad
solution, given that we already know that all of the parameter values
will be serializable (in fact, they're all subtypes of EObject except
for String).
2. Define it as add(EObject o). This seemed like a good solution,
until we couldn't figure out any way to say add("myString").
> EObjects aren't used
> to represent strings. They can have features that hold strings...
> It's possible to use org.eclipse.emf.ecore.xml.type.SimpleAnyType to
> hold a String; you'd need to create one, set it's instance type to
> something like EcorePackage.eINSTANCE.getEString() or
> XMLTypePackage.eINSTANCE.getString(), and then set the value.
Okay. So it sounds like you're saying that if I want to do this, I will
have to "wrap" a String in some EObject (e.g., create a StringObject
type with a String attribute, or put it into an instance of
SimpleAnyType)? Is this the same for all of the Java predefined Object
types (e.g., Int, Char, etc.)?
Thanks again,
Peri
|
|
|
| Re: creating a String EObject? [message #394497 is a reply to message #394491] |
Fri, 22 July 2005 09:48 |
| Eclipse User |
|
|
|
Peri,
Yes, to pass non-EObjects to an EObject API requires wrapping. This
applies for all non-EObjects. You can define your own type specific
wrappers or use something like this as a generic wrapper:
SimpleAnyType wrapper = XMLTypeFactory.eINSTANCE.createSimpleAnyType();
wrapper.setInstanceType(EcorePackage.eINSTANCE.getEInt());
wrapper.setValue(new Integer(42));
Peri Tarr wrote:
> Hi Ed,
>
>
>> What's in the string? Does it need to be parsed?
>
>
> No, it's just a string value. I have a generic data type that's kind
> of like Set (it isn't Set, but Set is simpler and the problem is the
> same)--it provides a set of services over most kinds of objects in
> general (Sets store objects; we maintain ontologies and other
> information about objects, but the type of the object is irrelevant
> for our purposes, just as it is for Sets). In Java without EMF, I
> would allow the services to be provided for any subtype of
> java.lang.Object; for example, I can say s.add("myString") to some Set
> s. In Java with EMF, I'd like to allow the services to be provided
> for any EObject instead, to ensure that the actual objects for which
> we provide the services are serializable. This works fine for most of
> the types of objects for which we're providing this service.
>
> However, we ran into a problem with the Java primitive types, like
> String. In an EMF world, I don't see how to write the signature of a
> method like add() and enable us to pass a String as a value. Our
> choices appeared to be:
>
> 1. Define it as add(Object o), and have to deal with the
> serialization issue on java.lang.Object. This seems like a bad
> solution, given that we already know that all of the parameter values
> will be serializable (in fact, they're all subtypes of EObject except
> for String).
>
> 2. Define it as add(EObject o). This seemed like a good solution,
> until we couldn't figure out any way to say add("myString").
>
>> EObjects aren't used to represent strings. They can have features
>> that hold strings... It's possible to use
>> org.eclipse.emf.ecore.xml.type.SimpleAnyType to hold a String; you'd
>> need to create one, set it's instance type to something like
>> EcorePackage.eINSTANCE.getEString() or
>> XMLTypePackage.eINSTANCE.getString(), and then set the value.
>
>
> Okay. So it sounds like you're saying that if I want to do this, I
> will have to "wrap" a String in some EObject (e.g., create a
> StringObject type with a String attribute, or put it into an instance
> of SimpleAnyType)? Is this the same for all of the Java predefined
> Object types (e.g., Int, Char, etc.)?
>
> Thanks again,
> Peri
|
|
|
| Re: creating a String EObject? [message #394499 is a reply to message #394497] |
Fri, 22 July 2005 12:01 |
| Eclipse User |
|
|
|
Okay, thanks.
I have a far worse problem now, however. I've defined an interface with
the following attribute:
EObject getPropertyValue();
My original markup was this:
/**
* @model type="EObject"
*/
The generated code had compile errors because EMF generated import
statements of the form "import EObject;" So I changed the markup to this:
/**
* @model type="org.eclipse.emf.ecore.EObject"
*/
Same problem. I changed the attribute's type from EObject to
org.eclipse.emf.ecore.EObject; same problem again. I tried eliminating
the markup (I just left it as "@model"); same problem.
What am I doing wrong here?
Thanks,
Peri
Ed Merks wrote:
> Peri,
>
> Yes, to pass non-EObjects to an EObject API requires wrapping. This
> applies for all non-EObjects. You can define your own type specific
> wrappers or use something like this as a generic wrapper:
>
> SimpleAnyType wrapper = XMLTypeFactory.eINSTANCE.createSimpleAnyType();
> wrapper.setInstanceType(EcorePackage.eINSTANCE.getEInt());
> wrapper.setValue(new Integer(42));
>
>
> Peri Tarr wrote:
>
>> Hi Ed,
>>
>>
>>> What's in the string? Does it need to be parsed?
>>
>>
>>
>> No, it's just a string value. I have a generic data type that's kind
>> of like Set (it isn't Set, but Set is simpler and the problem is the
>> same)--it provides a set of services over most kinds of objects in
>> general (Sets store objects; we maintain ontologies and other
>> information about objects, but the type of the object is irrelevant
>> for our purposes, just as it is for Sets). In Java without EMF, I
>> would allow the services to be provided for any subtype of
>> java.lang.Object; for example, I can say s.add("myString") to some Set
>> s. In Java with EMF, I'd like to allow the services to be provided
>> for any EObject instead, to ensure that the actual objects for which
>> we provide the services are serializable. This works fine for most of
>> the types of objects for which we're providing this service.
>>
>> However, we ran into a problem with the Java primitive types, like
>> String. In an EMF world, I don't see how to write the signature of a
>> method like add() and enable us to pass a String as a value. Our
>> choices appeared to be:
>>
>> 1. Define it as add(Object o), and have to deal with the
>> serialization issue on java.lang.Object. This seems like a bad
>> solution, given that we already know that all of the parameter values
>> will be serializable (in fact, they're all subtypes of EObject except
>> for String).
>>
>> 2. Define it as add(EObject o). This seemed like a good solution,
>> until we couldn't figure out any way to say add("myString").
>>
>>> EObjects aren't used to represent strings. They can have features
>>> that hold strings... It's possible to use
>>> org.eclipse.emf.ecore.xml.type.SimpleAnyType to hold a String; you'd
>>> need to create one, set it's instance type to something like
>>> EcorePackage.eINSTANCE.getEString() or
>>> XMLTypePackage.eINSTANCE.getString(), and then set the value.
>>
>>
>>
>> Okay. So it sounds like you're saying that if I want to do this, I
>> will have to "wrap" a String in some EObject (e.g., create a
>> StringObject type with a String attribute, or put it into an instance
>> of SimpleAnyType)? Is this the same for all of the Java predefined
>> Object types (e.g., Int, Char, etc.)?
>>
>> Thanks again,
>> Peri
>
>
|
|
|
| Re: creating a String EObject? [message #394501 is a reply to message #394499] |
Fri, 22 July 2005 12:12 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------000505050901000608000500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Peri,
You need to remove the imports manually, but I assume you know that.
Once you've generated the XyzPackage, there will be an @model
declaration in there for the data type, e.g.,
/**
* Returns the meta object for data type '<em>EBoolean</em>'.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @return the meta object for data type '<em>EBoolean</em>'.
* * @model instanceClass="boolean"*
* @generated
*/
EDataType getEBoolean();
This will continue to give you problems until you remove it. (Or you
could remove that nasty EDataType from the .ecore before you regenerate,
and it will be swept away.)
Peri Tarr wrote:
> Okay, thanks.
>
> I have a far worse problem now, however. I've defined an interface
> with the following attribute:
>
> EObject getPropertyValue();
>
> My original markup was this:
>
> /**
> * @model type="EObject"
> */
>
> The generated code had compile errors because EMF generated import
> statements of the form "import EObject;" So I changed the markup to
> this:
>
> /**
> * @model type="org.eclipse.emf.ecore.EObject"
> */
>
> Same problem. I changed the attribute's type from EObject to
> org.eclipse.emf.ecore.EObject; same problem again. I tried
> eliminating the markup (I just left it as "@model"); same problem.
>
> What am I doing wrong here?
>
> Thanks,
> Peri
>
> Ed Merks wrote:
>
>> Peri,
>>
>> Yes, to pass non-EObjects to an EObject API requires wrapping. This
>> applies for all non-EObjects. You can define your own type specific
>> wrappers or use something like this as a generic wrapper:
>>
>> SimpleAnyType wrapper =
>> XMLTypeFactory.eINSTANCE.createSimpleAnyType();
>> wrapper.setInstanceType(EcorePackage.eINSTANCE.getEInt());
>> wrapper.setValue(new Integer(42));
>>
>>
>> Peri Tarr wrote:
>>
>>> Hi Ed,
>>>
>>>
>>>> What's in the string? Does it need to be parsed?
>>>
>>>
>>>
>>>
>>> No, it's just a string value. I have a generic data type that's
>>> kind of like Set (it isn't Set, but Set is simpler and the problem
>>> is the same)--it provides a set of services over most kinds of
>>> objects in general (Sets store objects; we maintain ontologies and
>>> other information about objects, but the type of the object is
>>> irrelevant for our purposes, just as it is for Sets). In Java
>>> without EMF, I would allow the services to be provided for any
>>> subtype of java.lang.Object; for example, I can say
>>> s.add("myString") to some Set s. In Java with EMF, I'd like to
>>> allow the services to be provided for any EObject instead, to ensure
>>> that the actual objects for which we provide the services are
>>> serializable. This works fine for most of the types of objects for
>>> which we're providing this service.
>>>
>>> However, we ran into a problem with the Java primitive types, like
>>> String. In an EMF world, I don't see how to write the signature of
>>> a method like add() and enable us to pass a String as a value. Our
>>> choices appeared to be:
>>>
>>> 1. Define it as add(Object o), and have to deal with the
>>> serialization issue on java.lang.Object. This seems like a bad
>>> solution, given that we already know that all of the parameter
>>> values will be serializable (in fact, they're all subtypes of
>>> EObject except for String).
>>>
>>> 2. Define it as add(EObject o). This seemed like a good
>>> solution, until we couldn't figure out any way to say add("myString").
>>>
>>>> EObjects aren't used to represent strings. They can have features
>>>> that hold strings... It's possible to use
>>>> org.eclipse.emf.ecore.xml.type.SimpleAnyType to hold a String;
>>>> you'd need to create one, set it's instance type to something like
>>>> EcorePackage.eINSTANCE.getEString() or
>>>> XMLTypePackage.eINSTANCE.getString(), and then set the value.
>>>
>>>
>>>
>>>
>>> Okay. So it sounds like you're saying that if I want to do this, I
>>> will have to "wrap" a String in some EObject (e.g., create a
>>> StringObject type with a String attribute, or put it into an
>>> instance of SimpleAnyType)? Is this the same for all of the Java
>>> predefined Object types (e.g., Int, Char, etc.)?
>>>
>>> Thanks again,
>>> Peri
>>
>>
>>
--------------000505050901000608000500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peri,<br>
<br>
You need to remove the imports manually, but I assume you know that. <br>
<br>
Once you've generated the XyzPackage, there will be an @model
declaration in there for the data type, e.g.,<br>
<blockquote><small> /**<br>
* Returns the meta object for data type
'<em>EBoolean</em>'.<br>
* <!-- begin-user-doc --><br>
* <!-- end-user-doc --><br>
* @return the meta object for data type
'<em>EBoolean</em>'.<br>
<b> * @model instanceClass="boolean"</b><br>
* @generated<br>
*/<br>
EDataType getEBoolean();</small><br>
</blockquote>
This will continue to give you problems until you remove it. (Or you
could remove that nasty EDataType from the .ecore before you
regenerate, and it will be swept away.)<br>
<br>
<br>
Peri Tarr wrote:
<blockquote cite="middbr59f$vhf$1@news.eclipse.org" type="cite">Okay,
thanks.
<br>
<br>
I have a far worse problem now, however. I've defined an interface
with the following attribute:
<br>
<br>
EObject getPropertyValue();
<br>
<br>
My original markup was this:
<br>
<br>
/**
<br>
* @model type="EObject"
<br>
*/
<br>
<br>
The generated code had compile errors because EMF generated import
statements of the form "import EObject;" So I changed the markup to
this:
<br>
<br>
/**
<br>
* @model type="org.eclipse.emf.ecore.EObject"
<br>
*/
<br>
<br>
Same problem. I changed the attribute's type from EObject to
org.eclipse.emf.ecore.EObject; same problem again. I tried eliminating
the markup (I just left it as "@model"); same problem.
<br>
<br>
What am I doing wrong here?
<br>
<br>
Thanks,
<br>
Peri
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">Peri,
<br>
<br>
Yes, to pass non-EObjects to an EObject API requires wrapping. This
applies for all non-EObjects. You can define your own type specific
wrappers or use something like this as a generic wrapper:
<br>
<br>
SimpleAnyType wrapper =
XMLTypeFactory.eINSTANCE.createSimpleAnyType();
<br>
wrapper.setInstanceType(EcorePackage.eINSTANCE.getEInt());
<br>
wrapper.setValue(new Integer(42));
<br>
<br>
<br>
Peri Tarr wrote:
<br>
<br>
<blockquote type="cite">Hi Ed,
<br>
<br>
<br>
<blockquote type="cite">What's in the string? Does it need to be
parsed?
<br>
</blockquote>
<br>
<br>
<br>
No, it's just a string value. I have a generic data type that's kind
of like Set (it isn't Set, but Set is simpler and the problem is the
same)--it provides a set of services over most kinds of objects in
general (Sets store objects; we maintain ontologies and other
information about objects, but the type of the object is irrelevant for
our purposes, just as it is for Sets). In Java without EMF, I would
allow the services to be provided for any subtype of java.lang.Object;
for example, I can say s.add("myString") to some Set s. In Java with
EMF, I'd like to allow the services to be provided for any EObject
instead, to ensure that the actual objects for which we provide the
services are serializable. This works fine for most of the types of
objects for which we're providing this service.
<br>
<br>
However, we ran into a problem with the Java primitive types, like
String. In an EMF world, I don't see how to write the signature of a
method like add() and enable us to pass a String as a value. Our
choices appeared to be:
<br>
<br>
1. Define it as add(Object o), and have to deal with the
serialization issue on java.lang.Object. This seems like a bad
solution, given that we already know that all of the parameter values
will be serializable (in fact, they're all subtypes of EObject except
for String).
<br>
<br>
2. Define it as add(EObject o). This seemed like a good solution,
until we couldn't figure out any way to say add("myString").
<br>
<br>
<blockquote type="cite">EObjects aren't used to represent
strings. They can have features that hold strings... It's possible
to use org.eclipse.emf.ecore.xml.type.SimpleAnyType to hold a String;
you'd need to create one, set it's instance type to something like
EcorePackage.eINSTANCE.getEString() or
XMLTypePackage.eINSTANCE.getString(), and then set the value.
<br>
</blockquote>
<br>
<br>
<br>
Okay. So it sounds like you're saying that if I want to do this, I
will have to "wrap" a String in some EObject (e.g., create a
StringObject type with a String attribute, or put it into an instance
of SimpleAnyType)? Is this the same for all of the Java predefined
Object types (e.g., Int, Char, etc.)?
<br>
<br>
Thanks again,
<br>
Peri
<br>
</blockquote>
<br>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------000505050901000608000500--
|
|
|
Goto Forum:
Current Time: Mon Nov 10 04:13:04 EST 2025
Powered by FUDForum. Page generated in 0.05512 seconds |
Home