Home » Modeling » GMF (Graphical Modeling Framework) » Unresolvable transient references in notation model(Cannot reopen diagram after save, due to an edge that references transientChildren.)
| Unresolvable transient references in notation model [message #999656] |
Sat, 12 January 2013 19:54  |
 Greg Jansen
Messages: 22
Registered: July 2010 |
Junior Member |
|
|
When I try to reopen my diagram after saving, it fails saying there are unresolvable references. These references come from an edge I see in the XML which refers to transientChildren. I am assuming that those children were not persisted, but I wonder why the edge is persisted as it has not been customized in any way.
Now, I have to disclose the special context for this problem. This only happens after a certain element is added to the diagram after having been copied from another model. I call it a template element. I added a tool to the palette which triggers normal CreateElementRequests with an extra parameter containing the template object. I then override the CreateCommand to detect the template parameter and add a copy of the template instead of a new element.
Here is the code for that:
protected CommandResult doExecuteWithResult(IProgressMonitor monitor, IAdaptable info) throws ExecutionException {
CreateElementRequest request = ((CreateElementRequest) getRequest());
MetadataBlock newElement = null;
if (request.getParameters().containsKey("templateElement")) {
EObject template = (EObject) request.getParameter("templateElement");
EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
newElement = (MetadataBlock)copier.copy(template);
copier.copyReferences();
} else {
newElement = CrosswalkFactory.eINSTANCE.createMetadataBlock();
}
Dictionary owner = (Dictionary) getElementToEdit();
owner.getBlocks().add(newElement);
doConfigure(newElement, monitor, info);
((CreateElementRequest) getRequest()).setNewElement(newElement);
return CommandResult.newOKCommandResult(newElement);
}
The unresolvable references to transientChildren only happen if a template object (MetadataBlock) is the first element added to the container, Dictionary in this case. If I add a normal new element to the Dictionary first, then add the template element as above, the problem does not occur.
Here is the XML which references transient children:
<edges type="4001" source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0" target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
<styles xsi:type="notation:RoutingStyle"/>
<styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
<element xsi:nil="true"/>
<bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0, 0, 0]$[0, 0, 0, 0]"/>
</edges>
If I add a normal element to the container first, then this edge does not seem to appear in the XML. Is there something I can do to remove this extra decor from notation on save. Not sure why it is being saved in one case and not the other.
Any help with this mystery is greatly appreciated.
Greg
|
|
|
| Re: Unresolvable transient references in notation model [message #999795 is a reply to message #999656] |
Sun, 13 January 2013 06:05  |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unresolvable transient references in notation model [message #999798 is a reply to message #999656] |
Sun, 13 January 2013 06:05 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unresolvable transient references in notation model [message #999801 is a reply to message #999656] |
Sun, 13 January 2013 06:05 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unresolvable transient references in notation model [message #999805 is a reply to message #999656] |
Sun, 13 January 2013 06:05 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unresolvable transient references in notation model [message #999809 is a reply to message #999656] |
Sun, 13 January 2013 06:05 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unresolvable transient references in notation model [message #999813 is a reply to message #999656] |
Sun, 13 January 2013 06:05 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unresolvable transient references in notation model [message #999817 is a reply to message #999656] |
Sun, 13 January 2013 06:05 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unresolvable transient references in notation model [message #999821 is a reply to message #999656] |
Sun, 13 January 2013 06:05 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unresolvable transient references in notation model [message #999826 is a reply to message #999656] |
Sun, 13 January 2013 06:05 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unresolvable transient references in notation model [message #999830 is a reply to message #999656] |
Sun, 13 January 2013 06:05 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unresolvable transient references in notation model [message #999835 is a reply to message #999656] |
Sun, 13 January 2013 06:05 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unresolvable transient references in notation model [message #999840 is a reply to message #999656] |
Sun, 13 January 2013 06:05 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unresolvable transient references in notation model [message #999845 is a reply to message #999656] |
Sun, 13 January 2013 06:05 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.
On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: Unresolvable transient references in notation model [message #1000349 is a reply to message #1000150] |
Mon, 14 January 2013 15:13 |
Greg Jansen
Messages: 22
Registered: July 2010 |
Junior Member |
|
|
Yes to non-containment references. The element I use as a template contains other elements that reference structural features in another model. (This template is used to build an XML-like structure, based on a schema generated model. It then let's the end user map data into the XML-like structure and generates XML.)
So here is exactly what is being copied:
MetadataBlock
0..* elements (containment)
MappedElement
1 mappedFeature (EReference to EStructuralFeature in separate model)
0..* mappedAttributes
MappedAttribute
1 mappedFeature (EReference to EStructuralFeature in separate model)
? input (EReference to an InputField as below)
0..* inputs
TextInputField
So there are two types of non-containment references within the MetadataBlock, which is what I've been calling the template. One type refers to structural features in a separate model. Another type links a mapped attribute to the TextInputField within the same enclosing MetadataBlock. The attribute-to-input link is an edge that is normally displayed in the diagram.
Since I haven't included it before, here is the error message with the unresolvable path:
Unresolved reference '/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0'. (platform:/resource/greg/my.form, 50, 234)
I have also attached the contents of my.form after saving and closing the diagram. It contains just the one copied MetadataBlock element in the model. You can see the edge element in the notational model. This is the same one edge visible in the diagram and mentioned above. The transient children it refers to are also part of the notation model.
When I create a diagram with the same structure using only new elements and not any copies, the edge is persisted but only references normal, non-transient, children.
In answer to your question about switching the element in the CreateElementRequest.. I think in GMF that property of the request, i.e. setNewElement(), is meant to be set in this context. It was being set here before I customized the generated class. It is passed along from this point to be used by later commands in the pipeline, including any edit advice.
I do think this is a fairly GMF-specific issue, since I am not directly copying any notation objects that might refer to this template object. I had assumed that all those notation objects were being created when the view was synchronized after the create command had finished. I probably need to know more about that part of the GMF pipeline.
thanks again,
Greg
Attachment: my.form
(Size: 3.33KB, Downloaded 220 times)
|
|
| | |
| Re: Unresolvable transient references in notation model [message #1000619 is a reply to message #1000349] |
Tue, 15 January 2013 05:28 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
Comments below.
On 14/01/2013 4:13 PM, Greg Jansen wrote:
> Yes to non-containment references. The element I use as a template contains other elements that reference structural features in another model.
Where do the actual referenced objects reside, i.e., where are they
contained?
> (This template is used to build an XML-like structure, based on a schema generated model. It then let's the end user map data into the XML-like structure and generates XML.)
>
> So here is exactly what is being copied:
>
> MetadataBlock
> 0..* elements (containment)
> MappedElement
> 1 mappedFeature (EReference to EStructuralFeature in separate model)
> 0..* mappedAttributes
> MappedAttribute
> 1 mappedFeature (EReference to EStructuralFeature in separate model)
> ? input (EReference to an InputField as below)
> 0..* inputs
> TextInputField
>
>
> So there are two types of non-containment references within the MetadataBlock, which is what I've been calling the template. One type refers to structural features in a separate model. Another type links a mapped attribute to the TextInputField within the same enclosing MetadataBlock.
That's likely the one that's causing problem...
> The attribute-to-input link is an edge that is normally displayed in the diagram.
>
> Since I haven't included it before, here is the error message with the unresolvable path:
> Unresolved reference '/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0'. (platform:/resource/greg/my.form, 50, 234)
>
> I have also attached the contents of my.form after saving and closing the diagram. It contains just the one copied MetadataBlock element in the model. You can see the edge element in the notational model. This is the same one edge visible in the diagram and mentioned above. The transient children it refers to are also part of the notation model.
>
> When I create a diagram with the same structure using only new elements and not any copies, the edge is persisted but only references normal, non-transient, children.
>
> In answer to your question about switching the element in the CreateElementRequest.. I think in GMF that property of the request, i.e. setNewElement(), is meant to be set in this context. It was being set here before I customized the generated class. It is passed along from this point to be used by later commands in the pipeline, including any edit advice.
Okay.
>
> I do think this is a fairly GMF-specific issue, since I am not directly copying any notation objects that might refer to this template object. I had assumed that all those notation objects were being created when the view was synchronized after the create command had finished. I probably need to know more about that part of the GMF pipeline.
It doesn't sound like you set breakpoint as suggested. It sounds like
your copy has references to these transient things. That wouldn't
surprise me if you told it not to resolve proxies while copying. I
don't expect such a resolve if you actually resolved the proxies. Have
you looked (with the debugger) at the result of the copy? Does it
contain references to the original objects where you would expect a
reference to the copied thing (specifically for "another type links a
mapped attribute to the TextInputField within the same enclosing
MetadataBlock").
>
> thanks again,
> Greg
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Unresolvable transient references in notation model [message #1000622 is a reply to message #1000371] |
Tue, 15 January 2013 05:32 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Greg,
Comments below.
On 14/01/2013 5:00 PM, Greg Jansen wrote:
> Could this have something to do with the useOriginalReferences option,
> currently set to true?
Not likely.
> Would that mean the internal reference within the copied object would
> not be a copy somehow, but instead be the original EReference object?
> Perhaps that would explain the weird edge?
Copying walks the containment structure and produces copies for all
these things, building a map at the same time. When copyReferences is
called, it hooks up all the cross references. Before any such reference
is set in the copy, it checks if the referenced object is copied as well
and redirects the reference to that copy, rather than the original.
That should work well for your case...
>
> I have useOriginalReferences set to true b/c without that option I
> lose my other important references, the ones that refer to structural
> features in another model.
Yes, it will drop all references to things not in the copy, which is
definitely not what you want.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
| Re: Unresolvable transient references in notation model [message #1032029 is a reply to message #1006513] |
Tue, 02 April 2013 13:41 |
Greg Jansen
Messages: 22
Registered: July 2010 |
Junior Member |
|
|
I was able to solve this problem in the end. The trick was to find the right CanonicalEditPolicy and to specify that the child view elements are persistent.
protected void refreshSemantic() {
if (resolveSemanticElement() == null) {
IAdaptable elementAdapter = new CanonicalElementAdapter(
next.getModelElement(), hint);
CreateViewRequest.ViewDescriptor descriptor = new CreateViewRequest.ViewDescriptor(
- elementAdapter, Node.class, hint, ViewUtil.APPEND, false,
+ elementAdapter, Node.class, hint, ViewUtil.APPEND, true,
host().getDiagramPreferencesHint());
viewDescriptors.add(descriptor);
}
Previously the links were being persisted without their endpoints. Now the views for all the linkable things are persistent.
thanks again for all the help,
Greg
|
|
|
Goto Forum:
Current Time: Wed Feb 05 13:03:24 GMT 2025
Powered by FUDForum. Page generated in 0.04834 seconds |
] 
Search
Help
Register
Login
Home
