[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.modeling.gmf] Re: A shortcut behaving as a node extension 
Hi Fabrice,

The most straightforward way is to define two different node mappings, one for a node without references to another node (the "base" node) and the other for a node which has such a reference (use MappingEntry#domainSpecialization and likely MappingEntry#domainInitializer to create several entries that reference the same underlying domain metaclass).
The tricky part is to define N2's compartment to reference N1's children. Unfortunately, this can't be done in a declarative way using gmfmap or gmfgen at the moment (AFAIK, there are plans to address this issue in the upcoming release). However, this may be done by manual fine-tuning of the generated code (or templates).
I believe, the places for modification are as follows:
1. XYZCreateCommand and XYZCompartmentItemSemanticEditPolicy -- to create child nodes in correct place;
2. XYZDiagramUpdater -- to return correct semantic children by navigating additional reference;
3. XYZCompartmentCanonicalEditPolicy -- to trigger update in response to changes of values in more features.


Best regards,
Boris



Wailly wrote: 
Hi Boris,

In fact, my purpose is to consider N1 and N2 as 2 classes, with N2 inheriting from N1. That is why they are identical when created, but become different when you start modifying N2. But maybe it is not compatible with what exists today in GMF...

For a better understanding, here is an instantiated example of my needs:

Model instance of N1 (classic)
====================
<node name="N1">
 <node name="N1.1"/>
 <node name="Nx" attribute="111"/>
</node>

Model instance of N2 (the trick)
====================
<node name="N2" isInstanceOf="N1">
 <node name="N2.1"/>
 <node name="Nx" attribute="222"/>
</node>


Notation instance of N1 (classic)
=======================
+ N1
|--N1.1
|--Nx (attribute 111)

Notation instance of N2
=======================
+ N2
|--N1.1
|--N2.1
|--Nx (attribute 222)


Any modification with GMF editor on N1 is reported to N1's model and N1's notation and also to N2's notation (no need to report it to N2's model as the reference from N2 to N1 does it implicitly).
Any modification with GMF editor on N2 is reported to N2's model and N2's notation.

It is pure inheritance between instances at the model level so there is no need to duplicate information from N1 into N2.
The notation level resolves this inheritance by creating an instance which is the addition of N1 and N2.

I hope you understand the need, and just would like to know if such a mechanism is available on GMF.
If not, what would be your advice to implement that?

Thanks a lot,

Fabrice