One of the major enhancements that you’ll get with MPS 3.4 is the new Transformation Menu Language. This is meant as a replacement and a major improvement over the functionality of Side-transformations and Node substitutions, which have been deprecated and will be removed from MPS in one of the next versions. (Don’t worry, a semi-automated migration will be provided.)
Additionally, the very same language can be used to define any other editor-related context-aware actions, such as the new Context Assistant or Context Actions Tool.
I’d like to clarify the rationale behind this new functionality in this post, so that you can better assess it and appreciate it fully.
The old mechanism based on side-transformations and node substitutions defined in the Actions aspect of language suffered from several problems, many of which you surely have experienced yourselves:
- The transformations were not specified for individual projections (editors), but instead they affected nodes (structure). This made it rather unintuitive to tune transformations for a particular editor, if multiple editors per concept were defined.
- Attaching actions to individual cells within an editor was complicated and fragile.
- The side-transformation tags, which were meant to help with the above issues, did not scale, nor did they encourage language extension.
- The “remove concept” and “remove defaults” options were unintuitive and frequently gave surprising results.
- When debugging a problem in editor behavior, in was not always obvious, which action takes effect and when.
Additionally, MPS 3.4 offers two new ways to help users invoke context-sensitive actions – Context Assistant and Context Actions Tool. It is only sensible that MPS provides a unified way for the language designers to define contextual actions, no matter, in which way they will be triggered and presented to the user.
How it looks
The Editor aspect can now hold definitions of both transformation and substitute menus:
Transformation and substitution are the two types of the new menus:
- Transformation menus – these specify contextual menus that should pop-up at various places in the editor
- Substitution menus – these define rules for allowed node substitutions (replacement)
There are three kinds of each of these two menu types:
- Default – These menus are applied to suitable nodes, unless a specific “named” menu has been specified. Only one default menu of each type can be defined for a concept.
- Named – These menus have to be attached to editor cells explicitly to have effect.
- Contribution – these can enhance existing menus by adding entries to them, typically when an extending language needs to customize a menu defined in the extended language.
The language itself somewhat resembles the old language used in Actions. After all, it should express similar ideas. The definition is divided into sections, each of which is attached to a particular location. It is the location that defines, whether the action will be a side-transformation, code-completion entry, context assistant entry or a context action tool element.
The individual entries of each section may express individual actions, parametrized actions, groups, submenus and several other options.
Let’s stop explaining the details are. You can always check out the full documentation and an explanatory video.
Benefits
Let’s instead summarize the major benefits here:
- Modularity – menus can include other menus or contribute to them, giving the extending languages more control over the menu contents
- Reuse – actions or menus can be shared easily among other menus
- Support for multiple projections – editors explicitly define the menus to use, which allows different editors for the same concept to have different menus
- Scalable and intuitive mechanism to attach actions to individual editor cells through named menus
- No need for puzzling “remove concept” or “remove defaults” constructs
- Unified approach to defining transformations, substitutions as well as various context-aware actions/assistants
Try it yourself
In order to experience the new Transformation Menu Language yourselves, use MPS 3.4 EAP3 or, since we’re still heavily polishing this feature, grab the recent builds from the TeamCity server.
The Drive to Develop
-JetBrains MPS Team
