Community
Participate
Working Groups
The VSM editor currently provides some refactoring actions: . BorderNodeMapping to sub NodeMappping (when child of a ContainerMapping) . NodeMapping to BorderMapping (when child of a ContainerMapping) . Relation based EdgeMapping to Element based EdgeMapping . Element based EdgeMapping to Relation based EdgeMapping We could also provide . NodeMapping to ContainerMapping when the mapping is contained by a Layer or a ContainerMapping (it is not just a change of containing feature, it will require to change all inverse cross references, recopy the possible attribute and reference, if there is a style: ask the user which style shoudl be created) . ContainerMapping to Node Mapping (see preceding comments) + a check that there are no other children than border node mappings . Line Mapping <-> Column Mapping in a Cross Table.
(In reply to Maxime Porhel from comment #0) > The VSM editor currently provides some refactoring actions: > . BorderNodeMapping to sub NodeMappping (when child of a ContainerMapping) > . NodeMapping to BorderMapping (when child of a ContainerMapping) > . Relation based EdgeMapping to Element based EdgeMapping > . Element based EdgeMapping to Relation based EdgeMapping > > We could also provide > . NodeMapping to ContainerMapping when the mapping is contained by a Layer > or a ContainerMapping (it is not just a change of containing feature, it > will require to change all inverse cross references, recopy the possible > attribute and reference, if there is a style: ask the user which style > shoudl be created) > . ContainerMapping to Node Mapping (see preceding comments) + a check that > there are no other children than border node mappings > . Line Mapping <-> Column Mapping in a Cross Table. 2 remarks: * This should first be written as a generic "Convert to" operation, defined at the core EMF level (no dependencies to Sirius), with semantic similar to Smallatlk's "become:". See the discussion at https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/msg02220.html on a related feature discussed for Papyrus. Maybe we can collaborate/reuse some code with them in this issue. For which actual concrete pairs of source and target types we want to expose an actual menu item in the UI is a second step. * In the end, I'd *really* like to get rid completely of the distinction between container mapping and node mappings, at the very least in the core Sirius code (and metamodel). Apart from the fact that nodes can't have elements inside them, there is no good reason that I can see to have two different concepts here (with lots of semi-duplicated and sometimes inconsistent code and features). Nodes should disappear as a specific mapping type, to be replaced by containers which simply happen to not have any children (or not to compute & display them. hint: we would simply need a new value for childrenPresentation: NONE). If we got this, the refactoring between nodes and containers would become a no-op.
