Re: [gmf-dev] GMF Tooling Visual Editor

[Mickael Istria <mickael.istria@xxxxxxxxxxxxxx>]

On 15/12/2011 16:29, Andres Alvarez wrote:

Hi Mickael, 

Thank you for your email.  We developed this in only a couple of weeks as a proof of concept and it still needs a lot of work. The idea of having integrated the three gmf models was for simplicity and to assure the integrity of the models. Users can still open the underlaying .simplemap model and customize the Canvas, Tool and Mapping models as usual.

Yes, I understood that.
But let's imagine that there will be some very interesting improvements on defaults editors provided for these files independently (for I proposed some improvements to .gmfgraph to have a preview of the defined figures), then people who use your "composite" model will have another editor, and won't be able to benefit from new features available for the "sub-parts" of your model.
Relying on current files would make your editor better integrated into GMF Tooling.

About the simplemap model, I needed to represent ChilReferences (SimpleSubNode in my model) as containments elements of the main diagram in order to allow the user to create unlimited number of nested sub nodes, however in the gmfmap model, a Mapping element can only have TopNodeReferences (SimpleTopNode) as containment children. The sames goes for the Compartments; I wanted to represent graphically the Compartments (SimpleCompartment in my model) as containment children of my SimpleNodes and container parents of other SimpleNodes. Finally, it was practical to have SimpleLabelNode elements to know if the user want to create only a label element or a more complex node element.

Yes, that's IMHO the good way to do so.

Anyway, the model could probabilly be simplified as it was created on the fly.

I think you could create a model that directly consumes several files. EMF supports having multiple files in a resourceSet. So instead of creating your whole file with everything in, you could rely on multiple files. Even with multiple files, it will be only one model at runtime.
This is for sure more difficult to set up; but it will turn your project into an "additional view for GMF Tooling" instead of an "alternate view for GMF Tooling". People would probably use it more if they don't have anything to change, and just a new thing to add.

What is interesting with your approach is that it hightlights the fact that GMFT files are so highly coupled that we feel they could be edited in a single editor. I think the same thing. But the current grain of GMF Tooling files allow to easily re-use figures, nodes across several editors (I don't know whether people do it a lot), this is IMHO something we should try to keep.

Regards,

--

Mickael Istria
R&D Engineer, Eclipse Plug-in RCP Developer

PetalsLink - Open Source SOA

My blog - My Tweets