Home » Modeling » EMF » Automatic population of transient attributes
|
| Re: Automatic population of transient attributes [message #1059562 is a reply to message #1059559] |
Mon, 20 May 2013 13:12   |
 Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Ben,
Comments below.
On 20/05/2013 3:01 PM, Ben Cox wrote:
> Hi all,
>
> I've got a problem in that our model objects are identified purely by
> their human-readable name. This becomes a problem in our forms-based
> editor when someone renames an object and its name becomes (perhaps
> just temporarily) the same as one of the other objects - and now any
> other links that point to that object are ambiguous.
Is that because there are unresolved proxies using that name as an ID?
> Continuing to rename the object then means that all of the links get
> 'dragged' along, so that none point to the other object any more - and
> the model has become wrecked.
That sounds like an issue involving unresolved proxies. Perhaps it's
just a matter of ensuring that all proxies are resolved before you begin
renaming things, e.g., calling EcoreUtil.resoveAll on the resource or
resource set...
>
> A way I thought of to stop this problem would be to have transient
> UUIDs auto-generated for the objects and transient UUID references to
> those objects created as the model was loaded from the workspace into
> memory.
What's the nature of these "references". Are EMF proxies involved?
> Then, the createSetCommand(...) method overrides in my ItemProviders
> would be able to search by UUID instead of by string identifiers, and
> (within an editor session) consistency would be maintained.
Are you doing some type of "manual" searching?
>
> I'm trying to work out, though - where should I put the code to do the
> population of UUIDs and the resultant UUID references? I could do it
> in the editor's code, I suppose... but is there anywhere in EMF's
> generated classes I could override for better results?
I think I'd like to understand better the nature of the problem before
helping make a particular solution work... In general it seems better
to ensure you have direct references to the objects, so that might be as
simple as ensure that all proxies have been resolved so that changes to
the "ID" don't result in subsequent proxy resolves being misdirected...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Automatic population of transient attributes [message #1059572 is a reply to message #1059562] |
Mon, 20 May 2013 14:14 |
Ben Cox
Messages: 17
Registered: June 2012 |
Junior Member |
|
|
Hi Ed,
comments inline.
>> Hi all,
>>
>> I've got a problem in that our model objects are identified purely by
>> their human-readable name. This becomes a problem in our forms-based
>> editor when someone renames an object and its name becomes (perhaps
>> just temporarily) the same as one of the other objects - and now any
>> other links that point to that object are ambiguous.
>Is that because there are unresolved proxies using that name as an ID?
Would that it used EMF's references already! No, it doesn't have unresolved proxies because the model doesn't use references (as far as EMF knows about them) at the moment. The model is one that has been generated from a pre-existing XSD, and doesn't have EMF-style references - hence, in a previous thread, I asked about how to make side-effects occur when one value gets changed, and you pointed me to the createSetCommand method that I could override in the ItemProviders (which is working well, apart from in this case - thanks!). Attempting to retro-fit EMF to the XSD in general works well, but it does have some problems, like this.
>> Continuing to rename the object then means that all of the links get
>> 'dragged' along, so that none point to the other object any more - and
>> the model has become wrecked.
>That sounds like an issue involving unresolved proxies. Perhaps it's
>just a matter of ensuring that all proxies are resolved before you begin
>renaming things, e.g., calling EcoreUtil.resoveAll on the resource or
>resource set...
I think probably not, in my case. I'd probably better give a simplified example:
<objectType1 name="hello" />
<objectType1 name="helloThere" />
<objectType2 name="apple" objectType1="hello" />
<objectType2 name="banana" objectType1="hello" />
<objectType2 name="cherry" objectType1="helloThere" />
<objectType2 name="date" objectType1="helloThere" />
Here, instances of objectType1 have a name. Instances of objectType2 have a reference (not a real EMF reference, just a string) to an objectType1.
Now, suppose your editor has a Text that allows you to alter an objectType1's name, and you want to alter "helloThere" to "help". You do this by backspacing. With each modification, the ObjectType1ItemProvider#createSetCommand searches for any objectType2s with a matching objectType1 attribute and creates a CompoundCommand that also modifies them. "helloThere" -> "helloTher" -> "helloThe" -> "helloTh" -> "helloT" -> "hello"... and here's where it goes wrong. When you do the next backspace, ALL of the objectType2s will be modified to point to the objectType1 "hell", because, at that particular point, they ALL pointed to something named "hello". Suddenly, objectType2s point to one of your objectType1s, and none to the other objectType1. While it's not valid, in our model, to have two objectType1s with the same name (we have a constraint to avoid this), it does temporarily happen while editing.
>>
>> A way I thought of to stop this problem would be to have transient
>> UUIDs auto-generated for the objects and transient UUID references to
>> those objects created as the model was loaded from the workspace into
>> memory.
>What's the nature of these "references". Are EMF proxies involved?
>> Then, the createSetCommand(...) method overrides in my ItemProviders
>> would be able to search by UUID instead of by string identifiers, and
>> (within an editor session) consistency would be maintained.
>Are you doing some type of "manual" searching?
Yes, absolutely. Fun. :-S
>>
>> I'm trying to work out, though - where should I put the code to do the
>> population of UUIDs and the resultant UUID references? I could do it
>> in the editor's code, I suppose... but is there anywhere in EMF's
>> generated classes I could override for better results?
>I think I'd like to understand better the nature of the problem before
>helping make a particular solution work... In general it seems better
>to ensure you have direct references to the objects, so that might be as
>simple as ensure that all proxies have been resolved so that changes to
>the "ID" don't result in subsequent proxy resolves being misdirected...
Hopefully that's clarified the matter a bit - as you can see, it's a bit horrible! I think we need to ensure we have references that EMF understands in order to get it working and to better identify objects even when they temporarily point to something with the same name. However, this information must not be persisted, in order to maintain compatibility of XML.
|
|
|
| Re: Automatic population of transient attributes [message #1059585 is a reply to message #1059572] |
Mon, 20 May 2013 15:30 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Ben,
Comments below.
On 20/05/2013 4:14 PM, Ben Cox wrote:
> Hi Ed,
>
> comments inline.
>
>>> Hi all,
>>>
>>> I've got a problem in that our model objects are identified purely
>>> by their human-readable name. This becomes a problem in our
>>> forms-based editor when someone renames an object and its name
>>> becomes (perhaps just temporarily) the same as one of the other
>>> objects - and now any other links that point to that object are
>>> ambiguous.
>> Is that because there are unresolved proxies using that name as an ID?
>
> Would that it used EMF's references already! No, it doesn't have
> unresolved proxies because the model doesn't use references (as far as
> EMF knows about them) at the moment. The model is one that has been
> generated from a pre-existing XSD, and doesn't have EMF-style
> references - hence, in a previous thread, I asked about how to make
> side-effects occur when one value gets changed, and you pointed me to
> the createSetCommand method that I could override in the ItemProviders
> (which is working well, apart from in this case - thanks!). Attempting
> to retro-fit EMF to the XSD in general works well, but it does have
> some problems, like this.
>
>>> Continuing to rename the object then means that all of the links get
>>> 'dragged' along, so that none point to the other object any more -
>>> and the model has become wrecked.
>> That sounds like an issue involving unresolved proxies. Perhaps it's
>> just a matter of ensuring that all proxies are resolved before you
>> begin renaming things, e.g., calling EcoreUtil.resoveAll on the
>> resource or resource set...
>
> I think probably not, in my case. I'd probably better give a
> simplified example:
>
> <objectType1 name="hello" />
> <objectType1 name="helloThere" />
>
> <objectType2 name="apple" objectType1="hello" />
I see. So name isn't of type ID in the schema with objectType1 of type
IDREF...
> <objectType2 name="banana" objectType1="hello" />
> <objectType2 name="cherry" objectType1="helloThere" />
> <objectType2 name="date" objectType1="helloThere" />
>
> Here, instances of objectType1 have a name. Instances of objectType2
> have a reference (not a real EMF reference, just a string) to an
> objectType1.
> Now, suppose your editor has a Text that allows you to alter an
> objectType1's name, and you want to alter "helloThere" to "help". You
> do this by backspacing. With each modification, the
> ObjectType1ItemProvider#createSetCommand searches for any objectType2s
> with a matching objectType1 attribute and creates a CompoundCommand
> that also modifies them. "helloThere" -> "helloTher" -> "helloThe" ->
> "helloTh" -> "helloT" -> "hello"... and here's where it goes wrong.
I suppose you're doing this with data binding...
> When you do the next backspace, ALL of the objectType2s will be
> modified to point to the objectType1 "hell", because, at that
> particular point, they ALL pointed to something named "hello".
> Suddenly, objectType2s point to one of your objectType1s, and none to
> the other objectType1. While it's not valid, in our model, to have two
> objectType1s with the same name (we have a constraint to avoid this),
> it does temporarily happen while editing.
I see.
>
>>>
>>> A way I thought of to stop this problem would be to have transient
>>> UUIDs auto-generated for the objects and transient UUID references
>>> to those objects created as the model was loaded from the workspace
>>> into memory.
>> What's the nature of these "references". Are EMF proxies involved?
>>> Then, the createSetCommand(...) method overrides in my ItemProviders
>>> would be able to search by UUID instead of by string identifiers,
>>> and (within an editor session) consistency would be maintained.
>> Are you doing some type of "manual" searching?
>
> Yes, absolutely. Fun. :-S
>
>>>
>>> I'm trying to work out, though - where should I put the code to do
>>> the population of UUIDs and the resultant UUID references? I could
>>> do it in the editor's code, I suppose... but is there anywhere in
>>> EMF's generated classes I could override for better results?
>> I think I'd like to understand better the nature of the problem
>> before helping make a particular solution work... In general it seems
>> better to ensure you have direct references to the objects, so that
>> might be as simple as ensure that all proxies have been resolved so
>> that changes to the "ID" don't result in subsequent proxy resolves
>> being misdirected...
>
> Hopefully that's clarified the matter a bit - as you can see, it's a
> bit horrible! I think we need to ensure we have references that EMF
> understands in order to get it working and to better identify objects
> even when they temporarily point to something with the same name.
> However, this information must not be persisted, in order to maintain
> compatibility of XML.
I see. Where/how are you planning to store the UUIDs and the
references to them? Why not add a transient reference (unfortunately
you can't do that via annotations in the schema) and populate those
references right after loading, i.e., essentially resolving all the
names once in the beginning? You might specialize the logic for
retrieving the value of the objectType1 attribute so it's computed from
the transient reference's name feature...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Sep 19 10:30:27 GMT 2024
Powered by FUDForum. Page generated in 0.04361 seconds |
] 
Search
Help
Register
Login
Home
