Home » Modeling » GMF (Graphical Modeling Framework) » Shortcut drag and drop between two models
|
| Re: Shortcut drag and drop between two models [message #780663 is a reply to message #779822] |
Wed, 18 January 2012 22:46   |
 Michael Golubev
Messages: 383
Registered: July 2009 |
Senior Member |
|
|
Hello,
Could you please be more precise, what is the behavior that does not work for you?
I haven't yet looked into your models, but will definitely do, just need more information about where to look at.
Regards,
Michael "Borlander" Golubev
at Montages Think Tank, Prague, Czech Republic
Montages AG, Zürich, Switzerland
|
|
|
| Re: Shortcut drag and drop between two models [message #780770 is a reply to message #780663] |
Thu, 19 January 2012 10:34 |
Laurent Le Moux
Messages: 184
Registered: September 2011 |
Senior Member |
|
|
Hi Michael,
Sorry for the lack of details. I was a little bit in a hurry when I wrote the message...
Hereafter the steps I followed :
1. EMF Part
The 'DeviceCore' project contains both models and all files generated with the EMF and GMF tools.
The 'DeviceOverview' model refers to a 'Component' element defined in the 'ComponentDetail' model.
So, when I generate the DeviceOverview.genmodel, I need to select both ecore models.
From this single .genmodel, I then generate all the necessary EMF code for manipulating both models (DeviceCore .edit and .editor projects).
2. ComponentDetail GMF part
ComponentDetail is the referenced model. It doesn't (yet) know about DeviceOverview referencing it. So, I just generated this part with the usual ComponentDetail.genmodel, .gmftool, .gmfgraph, .gmfmap and .gmfgen files.
I just modified ComponentDetail.gmfgen file to generate a ComponentDetail.diagram project instead of a DeviceCore.diagram one.
So, I basically replaced two references to DeviceCore by ComponentDetail in the .gmfgen file :
Gen Editor -> Editor Plug-in Directory = /ComponentDetail.diagram/src
Gen Editor -> Gen Plugin -> ID = ComponentDetail.diagram
3. DeviceOverview GMF part (just for test)
I did the same work to generate a DeviceOverview.diagram project.
At that level, I can run the basic application with all these plugins and generate diagrams for both DeviceOverview and ComponentDetail models.
But both diagrams are handled separately and are only 'linked' by the underlying EMF models. In other terms, at GMF level, they are still independent.
4. The 'Component' shortcut
That's where I'm stucked... Somewhere...
4.1. .gmfgraph adaptation
I copied the Component declaration from the ComponentDetail.gmfgraph to define its graphical representation in the DeviceOverview.gmfgraph as well.
I choose not to declare Component in DeviceOverview.gmftool.
4.2. .gmfmap adaptation
To allow its display in a DeviceOverview diagram, I modified the DeviceOverview.gmfmap file.
I added a Child Reference under the 'Device' Node Mapping. This declaration reflects the ecore model where a 'Device' element may refer to one or more 'Component' elements.
Below the Child Reference, I added a 'Component' Node Mapping.
It's important to note that at Child Reference level the 'Containement feature' is set to a ComponentDetail model element and not to a DeviceOverview one.
4.3. DeviceOverview.gmfgen generation and adaptation
That's where the error occurs...
By generating the DeviceOverview.gmfgen file, I get the following GMF warning / Eclipse error : 'Containment Feature' must be owned by 'Domain Meta Element' or its super type of this reference.
Not knowing what to do, I choose to ignore the warning and modify the generated DeviceOverview.gmfgen file to declare the Component shortcut, following the 'Jevon Drag & Drop Tutorial' I found on the Web.
This means : Gen Editor -> Gen Diagram -> Contains Shortcuts To = componentdetail
I finally generate again the DeviceOverview.diagram plugin.
4.4. ComponentDetail.gmfgen adaptation
I also set the following parameter in ComponentDetail.gmfgen before generating again the ComponentDetail.diagram plugin.
Gen Editor -> Gen Diagram -> Shortcuts Provided For = deviceoverview.diagram.part.DeviceOverviewDiagramEditorID
5. Running the resulting application and running into troubles... 
When I finally launch the generated application, I get two problems :
1. I can create a DeviceOverview diagram which works fine as long as I don't create a ComponentDetail one. Then, simply moving "My device" element in the DeviceOverview diagram causes the following execution error :
java.lang.ClassCastException: deviceoverview.impl.DeviceImpl cannot be cast to componentdetail.CDModel
Somehow, it appears that there is collision between both models at GMF and/or EMF level...
2. Drag & drop of "My component" element from the ecore file in the navigator to the DeviceOverview GMF diagram just does nothing and displays no error message.
I send you also the generated application project.
Please note that I made several tries to get all this running and the GMF tools files I uploaded in my first message may not be exactly in the same state I just described above.
Thanks in advance for your help,
Laurent
|
|
|
| Re: Shortcut drag and drop between two models [message #781682 is a reply to message #780770] |
Sun, 22 January 2012 01:07 |
Michael Golubev
Messages: 383
Registered: July 2009 |
Senior Member |
|
|
Hello,
You are mixing different concepts here.
In GMF-T we are referring as shortcuts the completely "alien" elements that are
- added to the diagram explicitly by the user,
- rendered and supported by the means of some other diagram plugin (lets forget about the self-shortcuts for simplicity)
It means that if you are going to show the shortcuts from the diagram B at the diagram A, neither code nor a definition models of the diagram A normally knows about the diagram B elements.
In particular neither diagram updater nor the element creation code of the diagram A is expected to handle the presence of the B-elements.
The B-code handles the internal structure (labels, children, etc) of all added shortcuts as well as the links outgoing from them.
The code from diagram A may handle the links outgoing from A-elements that has B-elements as their targets, also I am not 100% sure this will work out of the box without manual changes too.
Also, actually GMF only supports top-level shortcuts (those placed at the diagram canvas).
Consider the following use case:
User has loaded the 2 different CDModel's resources into the resource set and via property sheet has chosen 2 different Components C1 and C2 as used-by Device D.
You have 2 options here:
- a) Automatically show the both C1/C2 as an inner elements of D (it means the components are NOT shortcurs, because they are managed by the Device diagram updater)
- b) Don't change anything at the diagram until user explicitly adds the C1 or C2 as a top-level shortcut at the D-diagram canvas. Once something added, automatically show the D-link "uses" from D to C1/C2. (this is canonical shortcut use case)
The option b) is simpler to implement -- you should just:
- remove the node mapping for component from the device, and
- in the GMFGen model for D-diagram add the "Create Shortcut Action" into the ContextMenu
- set the D-Diagram#containsShortcutsTo = "componentdetail" (extension of the model resource for components)
But to my understanding you want to implement an option a) which actually has a poor support from the generation.
The problem here is that you want C to be graphically contained in D but the diagram code does not know where to put the new created C because you don't specify any containment.
This causes the problem 1) from your post -- GMF made some guess about what are the proper containers for new C's while generating the ComponentCreateCommand for diagram D. Warning told you that the guessed container was not matched, so you should not be surprised by the CCE.
To fix CCE, you may either
- disable creation of the new Components at the D diagram completely. Then just add generated @not "return false;" into the (d.diagram) ComponentCreateCommand#canExecute()
- substitute real creation of the Component with choosing of the existing component. In this case, replace ComponentCreateCommand#canExecute() with "return true; // user always can choose something", and reimplement the doExecuteWithResult here by the code very similar to the one that you get generated after adding the "Create Shortcut Action" into the ContextMenu of the D-diagram GMFGen.
This will solve the problem 1) from your post.
If you want to set the Device#uses reference by the means of DND of the component, you need to
- write something similar to the attached DeviceDragDropEditPolicy
- use it instead the default one in the DeviceEditPart#createDefaultEditPolicies() like:
installEditPolicy(EditPolicyRoles.DRAG_DROP_ROLE, new DeviceDragDropEditPolicy());
It would be nice if you created a bugzilla for us to handle that at the generation stage. It is not yet clear for me how this behavior and all its variants may be specified in the gmf input models, but a few votes may help us to identify this as a common issue.
Regards,
Michael "Borlander" Golubev
at Montages Think Tank, Prague, Czech Republic
Montages AG, Zürich, Switzerland
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 05:19:43 GMT 2024
Powered by FUDForum. Page generated in 0.04245 seconds |
] 
Search
Help
Register
Login
Home
.
