Community
Participate
Working Groups
GMF-Tooling should provide easy-to-use options in order to get the domain model (de)serialized into an existing Xtext DSL rather than a XMI. Maybe this is already simple enough? An interesting additional feature would be that the generated code could share editingDomain with an XText editor for immediate synchronization.
Jan, your opinion on this topic is very welcome.
Xtext encapsulates a lot of functionality behind the EMF resource API. I've summed up almost everything in the Xtext docs: http://www.eclipse.org/Xtext/documentation/2_0_0/210-emf-integration.php To use Xtext as the serialization mechanism, it's usually enough to register the appropriate EMF resource factory. GMF Tooling generates a registration entry for a GMResourceFactory, which should be avoided if you want to use Xtext serialization. Further work is necessary to make cut/copy/paste work, as there is an explicit cast to GMFResource in the GMF Runtime (which is quite messy in this area anyway). Most people are fine with that stage of integration. (http://www.eclipse.org/Xtext/documentation/2_0_0/210-emf-integration.php#gmf_integration_stage_1) The further you go the more complicated it will get. E.g. Xtext offers a lot of cross-resource infrastructure, while GMF (Tooling) only provides quite rudimentary support in this case. Some examples (GMF vs Xtext) * UUIDs vs names * Explicit loading of additional resources vs automatic on-demand loading based on an index * EMFT vs synchronisation on IDocument ... So there will always be some trade-offs, which would be weighted differently with regard to th actual application, i.e. a generated default solution is likely not to match to many use cases (IMHO).
I Think this is a often requested functionality in the GMF forum. I personally would like to have GMF serialize to a custom dsl as well. Maybe we could implement this feature for the next version of GMF. I might even contribute if I can get some free resources. I will need to take a look into that.
I have done several really big projects with lots of Xtext-based dsls and GMF-Editors on top of that. Most of the points Jan mentioned are also true for my scenarios. Sometimes it is really hard to avoid explicit casts to GMFResource or XMIResource. I think this is the most important thing to avoid. As it is now the integration with Xtext is sometimes hard because everything is made very explicit to XMIResources (UUIDs,...). Esspecially the cut/paste/copy stuff. We spent quite some time to get around this issues. I would be very welcome to have all this support out of the box in GMF-Tooling. I would also suggest to avoid the treeeditors for the different models involved in the development process with GMF-Tooling. If there would be some well defined textuell dsls for that with contentassist and so on, more people would use GMF-Tooling. Together with the Xtext integration this would be the most suitable solution for me and many more developers. I think GMF is for now the best solution to build graphical editors but the learning curve is very high. So more and more people believe that Graphiti is the philosophers' stone but as it is now you have to code a lot to get the same functionallity as you can get with GMF-Tooling in no time.
Thanks for your feedback Holger, About resources, please see and comment bug #360511. About having DSL, well... I think it is a matter of feelings. I am personnally not yet a big fan of creating DSLs for anything. Learning a language is as difficult as looking at properties, and as I understand your advice, the key with DSL is not having a DSL itself, but rather to have content assist and other tooling. Everybody agrees on an easier and more ergonomic tooling. I think Michael Golubev and his colleagues are working on a higher-level editor for GMF-T models that will make things easier to understand. What would you think about Itemis creating and contributing a DSL and a textual editor for GMF-Tooling models ? ;)
My feeling about the different models that are used until now for mapping and so on are a little bit confusing and have too many switches that nearly nobody knows or nobody needs. First of all we have to define an reference implementations to clarify what would be sufficient as implementation behind the generator. Then we have to clarify how this stuff could be defined in a dsl. Not important if this is a Xtext dsl or as treeeditor as it is now. Could we define a library on top f GMF runtime to be DRY. Any thoughts?
