- Changes made by migrations in Local History view
- Migrations for conceptNode//, .asNode, .conceptNode etc
- Modifications in the generator of the editor language
- API: EditorCell contract
- API: EditorCellFactory is now available only within UpdateSession
- Language Runtime: AbstractEditorBuilder
- Generator: EditorBuilder classes
- Contextual parameters available for cell builders
- New signature for createCell() methods
- Automatic migration script for new createCell() methods
- Mapping labels
- CellLayoutConstructor switch introduced
- New generator for RefCellCellProvider sub-classes
- InlineCellProvider replaced with EditorBuilder sub-class
- Editor Styles generator
- StyleClassItem constraints modification
- HTTP Support Plugin
- Fully-compiled languages
Changes made by migrations in Local History view
Migrations now cooperate with the Local History functionality. After running migrations, it's possible to see all the changes made to the project by each migration.
Open the Local History view for the project's folder, a module or a model, select any two changes and press Ctrl + D to see the difference.
It's also possible to revert a change or a group of those from the Local History view and the Diff dialogs
Migrations for conceptNode//, .asNode, .conceptNode etc
Modifications in the generator of the editor language
We decided to significantly re-design the generator of the editor language in this milestone. The editor language is supposed to be extended by the MPS users, so it makes sense to describe those changes we made in a single place. The new generator will simplify templates, make the generated code more human-readable and use more meta-information at the generation-time instead of the run-time. This item is relevant to those, who have developed languages extending the editor language. For projects not extending the editor language these changes should be transparent - you can just regenerate all editors in order to update your code.
If any of your languages extends the editor language in order to provide new cell types, we recommend you to carefully read through the following list of changes in order to be able to update your templates manually in cases, when it is required.
API: EditorCell contract
The contract of EditorCell.setBig()/.getBig() methods was slightly changed. Please check the javadoc for details.
API: EditorCellFactory is now available only within UpdateSession
We made the EditorCellFactory instance controlled by the current UpdateSession. In the same time we put some caches inside the EditorCellFactory implementation, making the editor building process faster in some situations. The EditorContext.getCellFactory() method was deprecated and will be removed in the next release.
Language Runtime: AbstractEditorBuilder
AbstractEditorBuilder runtime class was introduced and should be used as a common super-class of any classes containing cell factory methods. This class implements common utility methods and provides access to generic contextual parameters of editor cell creation process like:
AbstractEditorBuilder is used to capture some context of cell creation process and execute consequent cell factory methods within this context.
Generator: EditorBuilder classes
A separate sub-class of AbstractEditorBuilder class will be generated now as a root class for each of available editor declaration hierarchies:
The MPS editor generator will continue creating classes, implementing ConceptEditor & ConceptEditorComponent. These classes were used earlier as containers for cell factory methods. In the new version of MPS these classes are used as descriptors providing access to the contextual hints information & instantiating actual EditorBuilders. Descriptor classes may be cached by the EditorCellFactory implementation.
Contextual parameters available for cell builders
The code, generated as a part of AbstractEditorBuilder sub-classes may access contextual parameters by using existing methods of AbstractEditorBuilder class. In addition to that, all available meta-information is used to generate private fields with more specific types than those available in the method signatures of AbstractEditorBuilder. For now each sub-class of AbstractEditorBuilder will hold private node<TheConcept> myNode field, where TheConcept is the actual concept associated with this AbstractEditorBuilder. This means that any cell factory method may use such a private field in order to get typed access to the contextual node and directly access available properties, links and other information from the contextual node using s-model language.
CellFactoryContextClass is a handy utility class providing necessary context for templates, generating the code included into one of the generated AbstractEditorBuilder sub-classes. By using this class as a contextual class template authors will automatically obtain all available methods and fields, the code generation environment will be supported by MPS platform, and so it's not necessary to reconstruct it for each and every editor template anymore. At the same time, CellFactoryContextClass can be used as a marker interface highlighting templates, which will generate code for one of the EditorBuilders, simplifying the process of locating such code & supporting it in the future.
The GenericCellCreationContext interface provides limited subset of contextual information, which is always available for the code called either as a part of EditorBuilders or from a separate class, executed as a part of cell creation (editor update) process. This interface should be used as a template context instead of CellFactoryContextClass in those cases, when template authors are going to reuse the same template across the EditorBuilders generation process and some other places. For example, query methods which may be generated either inside EditorBuilders or within some style class.
New signature for createCell() methods
In the previous version of MPS, the cell factory methods were always generated with two additional parameters specifying the context of cell creation: EditorContext & node<>. From now on it's not necessary to specify these parameters any more - the generated code can always access this information (as well as any other contextual info) by calling methods from the containing EditorBuilder class. The new editor generator will generate cell factory methods without any parameters.
Automatic migration script for new createCell() methods
For compatibility with the existing generators, we provide a migration script patching available templates and introducing the new createCell() methods, which delegate to the old ones (with the two additional parameters) as a fallback. We recommend to execute this script first and then check all modifications and verify, if the modified generator still works correctly. The provided automatic migration supports only most frequent situations, so in some specific cases you may need to manually modify your generator in order to make it work again. The template, which generates the compatibility methods is called template_cellFactoryCompatibility. If you later modify your generator to generate directly the new createCellMethods, you should remove any calls to template_cellFactoryCompatibility. We do recommend to review all existing generators & patch obsolete templates generating the legacy createCell(...) methods in the scope of the current MPS release - we are going to drop the compatibility template in the next version.
Several mapping labels were introduced into the Editor generator (MAPPING_main) and may be used to simplify code generation:
cellFactory.class.concept : ConceptEditorDeclaration -> ClassConcept
This label expose a java class, generated for the EditorBuilder of ConceptEditorDeclaration.cellModel
cellFactory.class.inspector : ConceptEditorDeclaration -> ClassConcept
This label exposes a java class, generated for the EditorBuilder of ConceptEditorDeclaration.inspectedCellModel
cellFactory.class.component : EditorComponentDeclaration -> ClassConcept
This label exposes a java class, generated for the EditorBuilder of EditorComponentDeclaration
cellFactory.constructor : EditorCellModel -> ConstructorDeclaration
Used to mark the constructor of the generated EditorBuilder class.
cellFactory.factoryMethod : EditorCellModel -> InstanceMethodDeclaration
The replacement for obsolete cellFactoryMethod label, containing the new cellFactory methods. This label should be used instead of cellFactoryMethod at the moment of modification of existing templates making them generating new cellFactory methods.
generated.constructor : <no input concept> -> ConstructorDeclaration
This label may be used together with existing generatedClass one to mark generated constructor instances. This label may be used to avoid the ugly code for locating first constructor instance inside node<ClassConcept>, returned from the generatedClass mapping.
CellLayoutConstructor switch introduced
This template switch is used to instantiate proper cell layout while creating a collection cell. The previously used static createxxx() methods inside EditorCell_Collection class have been deprecated and will be removed.
New generator for RefCellCellProvider sub-classes
The generator for CellModel_RefCell has been modified. The newly generated anonymous inner classes for RefCellCellProvider do not use the logic located inside RefCellCellProvider.createRefCell() runtime method. The meta-information, available at generation-time, are used in oder to create complete content of this method. If you do generate sub-classes of RefCellCellProvider within your generators, you should consider reviewing such places and aligning your templates with the templates from MPS.
InlineCellProvider replaced with EditorBuilder sub-class
InlineCellProvider is not being used by the MPS generator anymore. MPS uses the generated sub-classes of AbstractEditorBuilder instead. Nevertheless, we modified some constraints inside InlineCellProvider in order to make the lifecycle more transparent. We recommend to check the javadoc for InlineCellProvider, if you are still using it.
Editor Styles generator
A separate static inner class will be generated for each entry inside StyleSheet & StyleKeyPack instances. The provided applyStyleClass template may be used to properly instantiate & call the new Style classes. Legacy static .applyxxx() methods should be removed in the next release.
StyleClassItem constraints modification
We removed the canBeChild constraints from the StyleClassItem concept. These constraints were replaced with canBeParent constraints of the node, containing the StyleClassItem. In addition to that isApplicableToCell(node<EditorCellModel> cellModel) behaviour method has been deprecated and is not used anymore. Instead we have introduced the following methods:
We recommend you to check the javadoc of StyleClassItem behavior methods, if you are implementing any custom StyleClassItem in your language.
HTTP Support Plugin
We introduced a new plugin that provides:
- co-operating via node URLs
integration with YouTrack and TeamCity services
- a DSL for defining custom extensions to the IDEA Platform built-in server
Now you can create URL references to your code via the context menu. The created URL will be copied to the clipboard and then can be pasted wherever you want. On clicking it, MPS will handle it and open the referenced code.
If you want to get a URL programmatically, you should use the .getURL operation defined in jetbrains.mps.ide.httpsupport language.
YouTrack and TeamCity Integration
MPS listens for requests that come from YouTrack and TeamCity. On clicking the 'Open in IDE' button in a browser, MPS will open the requested file. Moreover, if you are trying to open a generated file, MPS will open its sources in a proper location.
Built-in server extensions
The features above are implemented using the IDEA Platform built-in server. If you have any other necessities to handle HTTP requests in the IDE, you can define an extension to it server via jetbrains.mps.ide.httpsupport language. Note that the defined extensions should be placed in a plugin solution. See Plugin for more information
work in progress a the moment. The idea behind this capability is to relax MPS's bond to the language declaration models. Namely, use of node.concept.getDeclarationNode as ConceptDeclaration assumes there's a structure model available. This might, however, not be always true, for example if there's a alternative model that declares concepts (or metamodel elements, in general)
Migrations to run:
- ??some constraints migration (radimir)
Support of the substitute and side transform actions in the aspect actions is dropped.
Substitute and side transform actions from the actions aspect are no longer supported. Transformation and substitute menus should be used instead.
All commented out side transform and substitute actions will be removed by migration.
Corresponding commented out editor style SideTransformAnchorTagStyleClassItem will also be removed.
Instead of using SideTransformAnchorTagStyleClassItem in the specific cell one can attach the transformation menu with side transform section to that cell.
The instances of CellMenuPart_ApplySideTransforms will be removed as well.
CellMenuPart_ApplySideTransforms was designed to include items of the side-transform menu to the completion menu of the specific cell.
With the transformation menu language one can describe the same behaviour. She can attach the transformation menu with completion section to the cell. That section will contain the with include menu part with the specified location of side transform. So the items of side-transform menu will be included to the completion.
You can find the example at the FieldDeclaration_ApplySideTransforms menu:
Location of the included menu can be specified with the intention "Specify Location".