Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 14:54 Go to next message
Greg Jansen is currently offline 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 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #999798 is a reply to message #999656] Sun, 13 January 2013 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #999801 is a reply to message #999656] Sun, 13 January 2013 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #999805 is a reply to message #999656] Sun, 13 January 2013 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #999809 is a reply to message #999656] Sun, 13 January 2013 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #999813 is a reply to message #999656] Sun, 13 January 2013 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #999817 is a reply to message #999656] Sun, 13 January 2013 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #999821 is a reply to message #999656] Sun, 13 January 2013 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #999826 is a reply to message #999656] Sun, 13 January 2013 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #999830 is a reply to message #999656] Sun, 13 January 2013 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #999835 is a reply to message #999656] Sun, 13 January 2013 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #999840 is a reply to message #999656] Sun, 13 January 2013 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #999845 is a reply to message #999656] Sun, 13 January 2013 01:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #1000096 is a reply to message #999656] Sun, 13 January 2013 20:48 Go to previous messageGo to next message
Greg Jansen is currently offline Greg Jansen
Messages: 22
Registered: July 2010
Junior Member
Thanks Ed,
I just tried changing the Copier call to also resolve proxies, then created a new diagram and performed the test. Still unable to reopen the model after a save and for the same reason as previously. However, all is well otherwise with the proxies being resolved, so I will keep resolving them. I wish I understood proxies better, so I will probably consult your book when I get back to the office.

Many thanks. If you have further suggestions, I am all ears.
Greg
Re: Unresolvable transient references in notation model [message #1000150 is a reply to message #1000096] Mon, 14 January 2013 00:51 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
Greg,

Does this thing you're copying have any non-containment references? It
certainly appears to be the case that notation model is creating
notational elements (Edges I suppose) that refer to something that
you've not actually copied. You'll need to track down why it's doing
that and when it's doing that. You might do so by setting a breakpoint
in the setSource method of an Edge (and perhaps make it conditional on
EcoreUtil.getURI(source).toString().contains("transientChildren"). Is it
okay that you switch the element in the CreateElementRequest during
execution as opposed to specializing where the element request itself is
created? I don't know GMF well enough to know the answer to that.


On 14/01/2013 2:48 AM, Greg Jansen wrote:
> Thanks Ed,
> I just tried changing the Copier call to also resolve proxies, then
> created a new diagram and performed the test. Still unable to reopen
> the model after a save and for the same reason as previously. However,
> all is well otherwise with the proxies being resolved, so I will keep
> resolving them. I wish I understood proxies better, so I will probably
> consult your book when I get back to the office.
>
> Many thanks. If you have further suggestions, I am all ears.
> Greg
>
Re: Unresolvable transient references in notation model [message #1000349 is a reply to message #1000150] Mon, 14 January 2013 10:13 Go to previous messageGo to next message
Greg Jansen is currently offline 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 46 times)
Re: Unresolvable transient references in notation model [message #1000354 is a reply to message #1000349] Mon, 14 January 2013 10:29 Go to previous messageGo to next message
Greg Jansen is currently offline Greg Jansen
Messages: 22
Registered: July 2010
Junior Member
I have discovered a strange workaround for this issue. If I add a newly created MetadataBlock element to the diagram first, then add the copied one, then the edge is persisted without transient child references. So this issue seem to only occur when the copied element is the first element added to the containing ordered list. Note that I have three elements in my model that may contain these copied template objects. The issue occurs in two out of the three. The two containment features in which this occurs are ordered, but the one without issues is not ordered.
Re: Unresolvable transient references in notation model [message #1000371 is a reply to message #1000354] Mon, 14 January 2013 11:00 Go to previous messageGo to next message
Greg Jansen is currently offline Greg Jansen
Messages: 22
Registered: July 2010
Junior Member
Could this have something to do with the useOriginalReferences option, currently set to true? 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?

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.
Re: Unresolvable transient references in notation model [message #1000619 is a reply to message #1000349] Tue, 15 January 2013 00:28 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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
Re: Unresolvable transient references in notation model [message #1000620 is a reply to message #1000354] Tue, 15 January 2013 00:29 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
Greg,

You'll really need to look closely at the thing you've copied with the
debugger...

On 14/01/2013 4:29 PM, Greg Jansen wrote:
> I have discovered a strange workaround for this issue. If I add a
> newly created MetadataBlock element to the diagram first, then add the
> copied one, then the edge is persisted without transient child
> references. So this issue seem to only occur when the copied element
> is the first element added to the containing ordered list. Note that I
> have three elements in my model that may contain these copied template
> objects. The issue occurs in two out of the three. The two containment
> features in which this occurs are ordered, but the one without issues
> is not ordered.
Re: Unresolvable transient references in notation model [message #1000622 is a reply to message #1000371] Tue, 15 January 2013 00:32 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
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.
Re: Unresolvable transient references in notation model [message #1001350 is a reply to message #1000622] Wed, 16 January 2013 09:45 Go to previous messageGo to next message
Greg Jansen is currently offline Greg Jansen
Messages: 22
Registered: July 2010
Junior Member
I ran the debugger and checked the copied object after the call the Copier.copyReferences(). The expected objects seem to have been copied and the reference between two objects contained there was intact, pointing to the copied object. So I think the result produced by Copier is completely fine. The problem seems to occur after that, when GMF creates the view to represent the cross-reference or perhaps later, when it attempts to persist that view.
Re: Unresolvable transient references in notation model [message #1001374 is a reply to message #1001350] Wed, 16 January 2013 10:29 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25919
Registered: July 2009
Senior Member
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Greg,<br>
<br>
Did you try this earlier suggestion?<br>
<blockquote>You might do so by setting a breakpoint in the setSource
method of an Edge (and perhaps make it conditional on
EcoreUtil.getURI(source).toString().contains("transientChildren").</blockquote>
<div class="moz-cite-prefix">You know about conditional
breakpoints?  You need to find out when and why the edge referring
to an inappropriate thing is being created...<br>
<br>
<br>
On 16/01/2013 3:45 PM, Greg Jansen wrote:<br>
</div>
<blockquote cite="mid:kd6edi$kus$1@xxxxxxxxe.org" type="cite">I
ran the debugger and checked the copied object after the call the
Copier.copyReferences(). The expected objects seem to have been
copied and the reference between two objects contained there was
intact, pointing to the copied object. So I think the result
produced by Copier is completely fine. The problem seems to occur
after that, when GMF creates the view to represent the
cross-reference or perhaps later, when it attempts to persist that
view.
<br>
</blockquote>
<br>
</body>
</html>
Re: Unresolvable transient references in notation model [message #1006513 is a reply to message #1001374] Thu, 31 January 2013 09:38 Go to previous messageGo to next message
Greg Jansen is currently offline Greg Jansen
Messages: 22
Registered: July 2010
Junior Member
Thanks again Ed, other deadlines took me away from this. I will try a breakpoint on Edge as soon as I find the source code plugin. When I import the likely SDK the jars contain no java files (or class files for this matter). I will keep at it and let you know what I discover.
Re: Unresolvable transient references in notation model [message #1032029 is a reply to message #1006513] Tue, 02 April 2013 09:41 Go to previous message
Greg Jansen is currently offline 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
Previous Topic:Keybinding for ValidateAction
Next Topic:Initializing a diagram with default node
Goto Forum:
  


Current Time: Sat Jul 26 13:32:48 EDT 2014

Powered by FUDForum. Page generated in 0.06648 seconds