|
| Re: Persistent feature of type EJavaObject (i.e. storing a plain java obj in an EMF model) [message #634132 is a reply to message #633987] |
Wed, 20 October 2010 15:13   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Cristian,
Comments below.
Cristian wrote:
> Hello,
>
> I have an EMF class that has an attribute testObj:EJavaObject. This
> (persistent) attribute should be able to hold primitive types (e.g.
> boolean, string, int), or some simple EMF objects (e.g. VisibiliryKind
> enum - from the UML metamodel), or a list of EMF objects.
>
> I noticed that this doesn't seem to work out of the box: setting:
> se.setTestObj("test");
> results in a serialization of this form:
> <packagedElement xmi:type= ..... testObj="ACED000574000474657374">
Yes, it uses java.io.Serializeable. Not so human readable is it?
>
> I know that there are some methods that can serialize/deserialize an
> object to string. Is there something I should do to convince the
> load/save mechanism to use them (instead of the normal java
> serialization - or at least I think that's what happens when "test" ->
> "ACED00...")?
You'd need to define your own datatype and you'd have to keep in mind
issues like, how do you tell the difference between an int value 1
verses a string value "1"...
>
> PS: what I want to achieve is somehow similar with the
> FeatureChange.value attribute (from emf.ecore.change metamodel).
> However, it has some drawbacks I'd like to avoid:
>
> * .value is a derived feature; its hand written implementation
> converts the value to string and stores it in valueString:EString. I'm
> wondering if I could avoid "hand-writing", because for this case it
> impacts in a certain way the general architecture of my app.
>
> * the above implementation uses indeed EcoreUtil.convertToString()
> because it knows the EDataType of the value; it's not necessarily my
> case (or perhaps there's a way of determining the EDataType from a
> Java instance?
On the way out, but on the way in, you'd need to be able to tell both
the data type and the literal value.
>
> Thanks in advance for any hints.
You definitely should think about creating your own EDataType which will
work for a bounded set of possible instance types and serialize in a way
that it can determine the instance type when it deserializes. Another
approach to look at is the SimpleAnyType from the XMLTypePackage. Here
you specify both the EDataType and the value and it serializes both...
> Best regards,
> Cristian.
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Persistent feature of type EJavaObject (i.e. storing a plain java obj in an EMF model) [message #634379 is a reply to message #634132] |
Thu, 21 October 2010 13:34 |
Cristian Spiescu
Messages: 100
Registered: July 2009 |
Senior Member |
|
|
Hello Ed,
You are right! A serialization/deserialization toString() cannot be done without having a datatype (i.e. logic that can properly interpret the string, because as you've said "123" could be an int, a String, an Enum).
In the end, I managed to have both the
* value:Object
* the feature:EStructuralFeature (=> I have the data type)
I am persisting both of them, so when loading, i have the datatype again.
Thanks and best regards,
Cristi.
[Updated on: Thu, 21 October 2010 13:36] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.03804 seconds
] 
Search
Help
Register
Login
Home
