Migration from Side Transform Actions to Transformation Menu Language
Hello,
after migration to MPS 3.4.1 I struggle with the migration of some of my former side transform actions.
In concrete, the former action looked like this:
both sides transformed node:IRestrictedExpressiontag:ext_1 //<no description>
condition :
(operationContext, model, sourceNode)->boolean {
sourceNode.isRestrictedExpressionOnly();
}
common initializer :
<no common variables>
....................................
<no common initializer>
actions :
remove concept BinaryExpression
----------
remove concept TernaryExpression
----------
remove concept Expression
Means, based on a condition, some Concept types are removed from the menu.
This worked well with 3.3.5 but now with TransformationMenuLanguage, the 'remove concept' action is no longer available. The migration wizard delivers the following:
transformation menu filterRestrictedActions_ext_1 for concept IRestrictedExpression
section({ side transform LEFT RIGHT }) {
group
variables
<< ... >>
condition (editorContext, node, model)->boolean {
node.isRestrictedExpressionOnly();
}
<< ... >>
}
Is there any equivalent construct for 'remove concept'?
Thanks a lot
Holger
Please sign in to leave a comment.
FYI, I got the same issue:
https://mps-support.jetbrains.com/hc/en-us/community/posts/208589805/comments/205121684
Did you manage to solve this yet?
Ceers,
N.
As with MPS 3.4 it is recommended to use GrammarCells instead of implementing all the actions (TransformMenuActions) manually, I followed this approach. So most of my manual TransformMenuActions became obsolete.
The needed filtering I solved by using scoping, but not with ScopeProvider mentioned in the discussion you've referenced, I use the constraint aspect instead. The concept constraint aspect (can be parent) for example checks the 'link' to distinguish between left/right expression and decides about the allowed child. Or vice versa, the potentially included concept restricts its usage by itself (can be child).
I finally think the way with scoping is also more generic than the TransformMenuAction as I could move the constraint to a concept interface which is implemented by all affected concepts.
Thanks for the clarification! However, the "can be parent" constraint aspect will give you mostly NULL for the "childNode" due to the fact that they (i.e. the possible children) have not been created at that point in time. Therefore, any checks against properties of the childNode is impossible until the reference has been created and then MPS will tell you that this concept is out of the search scope. Thus, they will appear in the completion menu but will yield an error once they are selected. The same goes for the vice versa approach using the "can be parent" constraint.
It seems there is no other way than using the ScopeProvider? What do you think? Any further idea?