Home » Modeling » EMF » migration: EString attribute to ERference
|
| Re: migration: EString attribute to ERference [message #1400384 is a reply to message #1398837] |
Mon, 14 July 2014 05:58   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Felix,
It depends on the string value itself. If it contains a #, it will look
like a proxy URI and be treated as such. If it contains a ":" it will
look like a QName and will be looked up as type type of object to create
for the following value. If it just looks like an ID, then it will be
looked up...
On 11/07/2014 7:24 PM, Felix Dorner wrote:
> Hi,
>
> From version n to version n+1, an EAttribute of type EString is
> changed to be a EReference. The original string attribute is moved
> into a newly allocated object that's then set as the reference value
> (no worries, containment is handled too).
>
> I do this in a customized XMLHandler.handleForwardReferences(), and
> that seems to work for simple test cases. But is there a guarantee
> that it works for arbitrary content, or is there a possibility that
> deserialisation bails out earlier, say because the attribute value
> cannot ever be a reference to another object because of serialization
> constraints for EReferences that I'm unaware of?
>
> Thanks for comments,
> Felix
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: migration: EString attribute to ERference [message #1400496 is a reply to message #1400450] |
Mon, 14 July 2014 09:34 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Felix,
Comments below.
On 14/07/2014 10:03 AM, Felix Dorner wrote:
> Hello,
>
> On 14/07/2014 07:58, Ed Merks wrote:
>> It depends on the string value itself. If it contains a #, it will look
>> like a proxy URI and be treated as such. If it contains a ":" it will
>> look like a QName and will be looked up as type type of object to create
>> for the following value. If it just looks like an ID, then it will be
>> looked up...
>
> Yes I've seen that there's more behind it. Another issue is
> whitespace.. The attribute contains simple text, so each token is
> treated as a separate reference which is not what I want. I checked
> the next method higher up would be setValueFromId. I'll see if I can
> handle it better from there.
Exactly.
>
> A different idea I had was if I could maybe use extended metadata to
> "protect" the reference from being set by mapping it to some dummy
> name, then, record unknown features to conserve the attribute value,
> and set the reference afterwards. Would that make sense to you?
Yes, though probably more direct would have been to leave the old
attribute in the model, deprecate it, make it transient, suppress its
visibility, and then transform the value in that attribute to a
reference, perhaps as a post load step or perhaps directly in the
attribute's setter, all without messing with the deserializer.
>
> Felix
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
Goto Forum:
Current Time: Wed Apr 24 14:26:54 GMT 2024
Powered by FUDForum. Page generated in 0.03309 seconds |
] 
Search
Help
Register
Login
Home
