Overview
Tutorial steps
Run and test
And this is compatible with the diagram editor !...
Thank you
Discussion

Overview

This tutorial is an EMF tutorial but to go faster it takes the output of the GMF tutorial 2 as an input (in order not to have to build a new ecore model).

It shows how to persist your date in several ecore files instead of one.

This can be very interesting at least in two situations :

your model instantiation is so important that you want to organize all your data in several files
you have a few ecore files that all contains an identical subpart, so you would like to factorize it

This tutorial is based on the model built in the second GMF tutorial wich is availabale through :

This tutorial has been built with :

Eclipse 3.5.1
Graphical Modeling Framework SDK 2.2.1
Eclipse Modeling Framework 2.5.0

Tutorial steps

Open the filesystem.ecore file
Select the Filesystem.folders : Folder association (sub node of the Filesystem node)
In the properties view, set the Resolve Proxies to true

Repeat this operation with the following associations nodes :
- Filesystem.files : File
- Folder.folders : Folder
- Folder.files : File
Save the file
Open the filesystem.genmodel file
Select the root node Filesystem and in the properties view set the Containment proxies to true

Select the Folder.folders : Folder association (sub node of the Filesystem node)
In the properties view, set the Children and Create Child to true (in order to have a context menu allowing to create a child node in the generated EMF editor)
Repeat this operation with the Folder.files : File node
Save the file
Regenerate the model and the EMF editor with these steps :
- Open the filesystem.genmodel file
- On the root item, right click and select Generate Model Code
- Right click again on the root and select Generate Edit Code.
- Right click again on the root and select Generate Editor Code.
Open the filesystem.gmfgen file
Select the root node Gen Editor Generator jfb.examples.gmf.filesystem.diagram and in the properties view set the Same File For Diagram And Model to false
Save the file
Click on the Transform label of the dashboard
Generate the diagram by clicking on the Generate diagram editor label in the dashboard.

Run and test

Run the eclipse configuration that had been created in the first tutorial.
Create a new Filesystem model file named parent.filesystem (not a diagram file)
Select the Filesystem model object and click Ok
In the editor, right click on the Filesystem node and select New Child → Folder
On the Folder node that has just been created, right click and select Control
Select a new file name, for example click on Browse Workspace, select your project and type child.filesystem
Save the file
Open the child.filesystem, modify your folder (for example choose a name in the properties view for that folder, save the file and look at the parent.filesystem file ; it may have been updated automatically !

Cick `Control`	Select a file	The result…

And this is compatible with the diagram editor !...

Now you can initialize a diagram editor by right clicking on the parent.filesystem file and selecting Initialize filesystem_diagram diagram file and every modification in the diagram editor will be propagated to the two ecore files

Thank you

I hope that this material will be helpful for you. If you want to support it, your help is welcome :

Discussion

Luca, 2010/11/26 16:54

Hi,

is there a way to model a child.filesystem_diagram and then drag and drop it the the parent.filesystem_diagram?

Thanks

Jean-François Brazeau, 2010/11/26 22:01

Hello,

As far as I can see, it is possible to create a child.filesystem_diagram in association with child.filesystem. But you will not need to drag and drop the child.filesystem_diagram in the parent.filesystem_diagram. Every modification made to the child.filesystem from the child.filesystem_diagram will be automatically available in the parent.filesystem_diagram (except that you will probably have to re-arrange the nodes in the diagram if you've created several new nodes in the child diagram).

Regards,

JFB

Luca, 2010/11/27 00:21

Yes, I know!

Anyway what I asked is different!

I'd like to model the child first and then create the parent and drag the child in the parent! In this way I can reuse the same child in different parent diagrams!

Regards,

Luca

Jean-François Brazeau, 2010/11/29 17:36

Hummm… I maybe don't understand what you want to do, but what I said in the previous message can be generalized with several parents, each parent model containing the child (but this implies that your model doesn't have a bidirectional relation between the the child and the parent file). In other words, you would have something like :

parent1.filesystem <- parent1.filesystem_diagram
      |
child.filesystem   <- child.filesystem_diagram
      |
parent1.filesystem <- parent1.filesystem_diagram

Is that what you want to do ?

Regards,

JFB

Luca, 2010/11/29 17:50

mmm…i want to modeling one child and use that in different parents. Let's suppose you have a model of a processor (child) and you want to use the same model in different pc models (parent).

I'd like to operate in the following order:

1) modeling the processor → processor.model_diagram 2) modeling the first pc → pc1.model_diagram 3) drag the processor model into the pc model in order to reuse it. 4) modeling another pc and reuse again the processor model.

I hope that now my idea is more clear. Thanks, Luca

Jean-François Brazeau, 2010/12/02 20:53

When the processor is reused in a pc diagram, do you want to keep the processor's appearance that you had obtained in the initial processor diagram (the child) ? Or are you only interested to share the underlying model of the processor among a processor diagram and several PC diagrams ? In the last case, what I said in the previous message is compatible with it as far as I can see. In the first case, thing get more complicated according to me !!!!….

I think that this question is dependent on the number of elements contained in the processor diagram. If there are a lot of figures, you should be interested in rearranging not all these figures in the parent diagrams. But the processor has a few elements, it is acceptable to rearrange the processor elements on each diagram.

JF