Bugzilla – Full Text Bug Listing
| Summary: | Create a runtime Figure that interprets the GMFGraph model | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] GMF-Tooling | Reporter: | Mickael Istria <mistria> | ||||
| Component: | Runtime | Assignee: | Project Inbox <gmp.gmf-tooling-inbox> | ||||
| Status: | NEW --- | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | borlander, pierre-charles.david, pnhoang, ralphgerbig | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | Diagram Features | ||||||
| Attachments: |
|
||||||
|
Description
Mickael Istria
Why would we do that? There are a lot of other things that may be interpreted at runtime based on the gmfgen (or even gmfmap) artifacts -- updater, semantic edit-policies, basically everything. However GMFT consistently tries to avoid interpreting some descriptors at runtime in favor to formulating as much as possible in the code. I see a lot of good reasons for that consistency, e.g, it allows developer to escape into the @generated not code, which is problematic for interpreter approach. I don't like an actual state when the code-generation for figures is made at the bridge state and then stored in the GMFGen as a code-snippet to be used as is at the actual code-generation state. However for this particular problem have a solution of using the ModeledViewmap, (just referencing the GMFGraph figure from gmfgen) and running the figure templates at the codegen stage. This simplifies the bridge, allows to generate surrounding code that uses specific figure properties (edit policies, etc) and makes the codegeneration more clean. I strongly believe we would better focus on delivering the code-generation based on ModeledViewmap's. BTW, it will allow someone to do the figure interpreter approach via <<AROUND>>'s (In reply to comment #1) > Why would we do that? To provide a snapshot of the figure while developing the gmfgraph. GMFGraph is not easy to use, and testing its content is time consuming when one only wants to refine a figure. If we develop it for tooling, we could use it for runtime. All the work is done. Also, that is a first step towards a Graphical designer for Draw2d figures. I don't think it has to be part of a roadmap, but I'll try to make some experience exploring this way for the tooling. Then the idea of reusing it at runtime will come to everyone's minds. I understand what are you talking about. Just would like to note that described usecase may be done by generating the code, installing the bundle and loading it at runtime -- this is how we are _already_ doing the tests for gmfgraph. Yes, sure, but I feel it's a tricky, there are a lot of complex steps. What I have in mind, is that the gmfgraph metamodel is able to model ANY draw2d figure. I'd like to leverage it to create a draft of a graphical Draw2dBuilder. But that's something I'll work on my side. I don't plan to push such a critical change to GMFT. (yet ;) Created attachment 207368 [details]
Screenshot of WIP
Here is the screenshot of my progress on this topic.
You can find the necessary change on the git repo in branch "GMFGraphRendererFigure-363449".
I personnally now can't stop using it, it saves me a lot of time.
IMHO, it would be relevant to make it part of the 3.0 release, if we have nothing better on that side until then,
I forgot to mention that not everything is supported. If you are interested in it, test it with you use-cases and help in improving it. Hi Mickael, I am doing something similar. I have my own small language that I am intepreting. I have this code http://code.google.com/a/eclipselabs.org/p/melanie/source/browse/de.uni_mannheim.informatik.swt.models.plm.visualizationservice/src/de/uni_mannheim/informatik/swt/plm/visualization/service/VisualModelToFigureTransfomator.java for Nodes and this code for connections http://code.google.com/a/eclipselabs.org/p/melanie/source/browse/de.uni_mannheim.informatik.swt.gmf.plm/templates/aspects/diagram/editparts/LinkEditPart.xpt My be this can help you a bit. It is a nice idea to see a preview of the figure that is currently created. I have problems with external labels of nodes and labels attached to links. When adding these only by using a figure you will not be able to move them. I thinke for some things editparts will be needed to be created dynamically if you want to use this at runtime. Ralph Hi Mickael, As I am new to GMF so I don't know that the current version does not allow previewing the Figures when it is in the phase of designing with .gmfgraph. I also think it is a must when designing a complex system. Immagine that you have already tried to put many efforts in creating several levels of compartments in the graph, putting as many labels and rectangles in the children as possible, then you have to go through a very long phase a head of mapping the elements of your data model to this graph IN ORDER TO JUST PREVIEW THE GRAPH. Much worse when you realized that the graphical interfaces created are not that you want, you have to come back to change the data model, then change also the graph to a new structure. This will eventually lead to a loop that is a headache to developer. I totally support this idea. Hope it will be integrated into the main branch. Thanks, Marked for project plan |