| Change Context silently fails when navigating to EObject in different resource [message #1742848] |
Thu, 08 September 2016 04:32  |
Eclipse User |
|
|
|
Hi,
Summary
When I use a Change Context Flow Control operation to navigate to an EObject located in a different resource, the AQL expression used to specify the Browse Expression successfully locates the target object. However, all actions below the Change Context operation receive the original object instead of the target object.
Detailed explanation
Here's what I am trying to do in more detail:
Sirius based editor and meta model
I'm creating an editor which projects one ECore model onto another ECore model. The following example illustrates a scenario when such a setup is usefull. I have two meta models:
- A metamodel which describes a map of a city. It contains the streets, intersections etc.
- A metamodel which describes a route. It is expressed in terms of: move forward 200 meters, turn right 90 degrees, etc.
To provide both the map and the route model to one Sirius editor (and subsequent Diagram Descriptions) I created a metamodel which references the root elements in both the map and the route metamodels. This is called inputmodel.
The top level diagram has the only element from inputmodel as its domain class. I have another diagram which displays some more details of a street. Its domain class is Street. To project the route on this Street diagram I perform aql:self.eContainer.eInverse('referenceNameInInputmodelToRoute').routeParts . This works fine.
Issue
On the Street diagram I want to extend the route that someone took. To do this I need to create a new MoveForward element, so use the Create Instance operation. Since the starting context of the Create Element operation is an object of a Class from the map metamodel on this diagram, and the MoveForward element should be added to the Route model, we first need change context: we need to navigate to the container of the new MoveForward element. Hence the Create Element is contained in a Change Context operation which contains aql:self.eContainer.eInverse('referenceNameInInputmodelToRoute').routeParts This yields the following error when executing the Create Element:
ENTRY org.eclipse.sirius 4 0 2016-09-08 08:56:11.053
!MESSAGE Error while modifying model
!STACK 0
org.eclipse.sirius.ecore.extender.business.api.accessor.exception.FeatureNotFoundException: routeParts on map.impl.StreetImpl@3b69ad19 (name: Kerkstraat)
It looks like Change Context doens't pass the right object to the Create Element when navigating to an EObject located in a different resource. Using a Java Service which simply prints the String representation of an EObject I was able to determine that the AQL expression does correctly return a RoutePart. As long as I use Change Context with elements located in the same resource, it works as expected.
I couldn't find a bug report for this issue. Shall I submit it?
Kind regards,
Teun
|
|
|
|
| Re: Change Context silently fails when navigating to EObject in different resource [message #1743030 is a reply to message #1742904] |
Fri, 09 September 2016 13:23  |
| Eclipse User |
|
|
|
Hi,
Thanks for the reply.
Your suggestion to use self.eContainer(type) makes the expression more powerful.
You are also correct regarding the mistake in my example. It should have been 'referenceRouteToNameInInputmodel'. My apologies.
Self is not directly contained by the inputmodel.
The issue is not in finding the routeParts (a container of RouteElements). I've verifies this by creating a small Java Service which displays the result of the AQL expression. This Service takes an EObject, prints it's string representation and class to standard out, and then returns the original EObject.
Using this service as seen here: aql:self.eContainer.eInverse('referenceRouteToNameInInputmodel').routeParts.debugService() I was able to verify that I the expression returns one EObject, the container of RouteElements.
Change Context however fails to perform its task. Create Instance logs the mentioned error.
Kind regards,
Teun
|
|
|
Powered by
FUDForum. Page generated in 0.02826 seconds
Home