We can guess that there were 2 different attempts to solve the above complexity:
A: "Map Everything" - to add all 3 possible GMF mappings for every qualifying containment feature
- this correctly shows imported models or models created without the diagram
- user can create any specialized type of InputPin
- user has to choose correct InputPin subtype at palette
B: "Map Once" - map only the simplest InputPin
- this still correctly shows the imported models, including those with ValuePin's, because ValuePin extend InputPin
- user can only create InputPins
- attempt to create ValuePin via dedicated palette entry does not work
case B is represented as a red cells in the columns E/F
Note that green cell only means that the corresponding mapping is
present in the GMFGen, it does not mean that everything works as
expected :)
E.g, for CallOperationAction the #target is mapped, but #argument is always used from the diagram
E.g, we haven't found a way to create any pins for SendObjectAction
There may be other problem cases for existing actions, for now we were just focusing on what is mapped at all.
Note that the sheet also shows a few other problems:
- some features are not mapped at all, e.g AddStructuralFeatureValueAction#insertAt, the whole columns E/F or G are red in the table
- LoopNode#bodyOutput at cell [G17] is special case we don't understand at all
- - it is the only mapped non-containment
- - even if there was some intention behind this, user can't actually create #bodyOutput pin for LoopNode
- - if there was intention behind this, it should probably be implemented for other non-containments, e.g. LoopNode#decider
- - may be it is related that creation of LoopNode#loopVariable output pin fails (Bugzilla XXX)
- for some actions / pins there is also some synchronization logic implemented but we don't want to touch this topic for now
So the questions here are:
- does anybody care? :)
- is there any logic we missed behind the choice A vs B?
- what would you suggest as a choice A vs B for newly added actions for Mars?
- whatever the choice, should we enforce it for all existing ActivityD actions?
