| Altering XMLResource to create inter-EObject links bottom-up [message #656003] |
Wed, 23 February 2011 17:25  |
 Ben Tenne
Messages: 50
Registered: October 2009 |
Member |
|
|
Hi,
If I have a model where A contains B and B has a name, then I might end up with XML like this:
<A>
<B>
<name>Keith</name>
</B>
</A>
Deserialization creates objects from this, as follows:
1. Create A
2. Create B
3. Assign B to A
4. Set B.name
Is there any easy way I could reverse the order of steps 3 and 4? i.e. Have all inter-EObject links deferred and created bottom-up once all objects have been created and had their attributes populated?
Why do I ask? When I assign one EObject to another (e.g. B to A), I want set-by-value semantics, so I've got custom code in my A.setB(...) method that copies B and assigns the copy instead. Of course, that means step 4, above, is then operating on an instance of B that is not the one that's been added to A.
Thanks for any suggestions.
Cheers,
Ben.
|
|
|
| Re: Altering XMLResource to create inter-EObject links bottom-up [message #656010 is a reply to message #656003] |
Wed, 23 February 2011 17:55  |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Ben,
Comments below.
Ben Tenne wrote:
> Hi,
>
> If I have a model where A contains B and B has a name, then I might
> end up with XML like this:
>
>
> <A>
> <B>
> <name>Keith</name>
> </B>
> </A>
>
>
> Deserialization creates objects from this, as follows:
>
> 1. Create A
> 2. Create B
> 3. Assign B to A
> 4. Set B.name
>
> Is there any easy way I could reverse the order of steps 3 and 4?
No.
> i.e. Have all inter-EObject links deferred and created bottom-up
> once all objects have been created and had their attributes populated?
>
> Why do I ask? When I assign one EObject to another (e.g. B to A), I
> want set-by-value semantics, so I've got custom code in my A.setB(...)
> method that copies B and assigns the copy instead.
Sounds like bad news to me. The framework will not expect this
behavior. It's likely to make undo not work well in the editor, for example.
> Of course, that means step 4, above, is then operating on an instance
> of B that is not the one that's been added to A.
Another example where the framework will not work well.
>
> Thanks for any suggestions.
Best not try to work against the grain but rather with it.
>
> Cheers,
> Ben.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
| Re: Altering XMLResource to create inter-EObject links bottom-up [message #656231 is a reply to message #656127] |
Thu, 24 February 2011 16:09 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Ben,
No, that should be fine. As long as the value is .equals.
Ben Tenne wrote:
> Thanks for the advice, Ed.
>
> I have a related question. We've also customized the setter behaviour
> for EAttributes backed by XMLGregorianCalendar. This is given that
> assignments to EAttributes are generally considered to be by-value,
> but XMLGregorianCalendar is the exception to the rule, in that it has
> mutators such as setYear(...). In such setters, I add code at the
> start, something like: newValue=(XMLGregorianCalendar)newValue.clone();
>
> Would you imagine this causing any problems for the framework?
>
> Ben.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04837 seconds
] 
Search
Help
Register
Login
Home
