Workflow in Xtext Framework - mn-mikke/Model-driven-Pretty-Printer-for-Xtext-Framework GitHub Wiki

Before a user starts to write a grammar it is good to have an idea of what the given language syntax should look like and what claims are imposed on it. A good approach is to first create code examples of the language, which will be later useful for grammar testing. After the user has written a correct grammar containing all necessary references to meta-models and other requisites, code of a plug-in integrating the designed language into Eclipse IDE can be generated. The plug-in contains many runtime and IDE concepts, whose default behavior can be mostly changed by addition of standardly named methods into the prepared class. In this text, only the most important ones will be listed.

Runtime Concepts

These concepts deal with the Eclipse plug-in back-end and especially with the affairs of model generation from a code and code of a DSL as such.

  • Code Formatting - As it was mentioned in the introduction, the code formatting concept deals with the organization of code elements in such way that the code is more legible.
  • Linking - The concept serves to creating cross-references related to already existing model elements. The cross-reference is essentially a link to another grammar rule specifying a nonterminal. When a language is given that allows for declaring variables and subsequently use them, declaration of a variable can serve as a target of a cross-reference and an usage of the variable is the cross-reference.
  • Scoping - The concept defines visibility boundaries of reference targets for a particular cross-reference. The boundaries can be defined not only inside the file where the cross-reference is present but also over multiple files.
  • Validation - The concept serves to check whether the model, which is a result of the input code, fulfill given features that can not be defined through grammar rules such as the definition of a specific number of elements in the model, an order of elements in the model, etc.

IDE Concepts

These concepts integrate a newly created language into the Eclipse IDE and provide convenience for a language developer working with a language. The main goal of the concepts is to speed up code writing.

  • Content Assist - The content assist serves to suggest and complete a code according to the possibilities specified by context which is determined by the cursor in the code.
  • Outline View - The outline view is a tool that helps developers navigate through created models. It enables to view model elements hierarchically and sort them alphabetically.
  • Labeling - This concept allows for associating a model element with the label or the icon that are exploited by other IDE concepts. For example these presentation elements can be found in the suggest window of content assist or in the window of outline view.
  • Quick Fixes - This concept provides a possibility possibility of fixing code errors reported by explicitly defined validation rules as well as validation rules are derived from a grammar. The main principle of the concept is to produce the list of suggestions on the basis of an error type. Then it is up to the developer to choose one of the suggestions.
  • Template Proposals - Consider well-known "while" statement from ordinary imperative languages. The only two things which can be written differently regardless of the code formatting is the loop condition and the loop body. Everything else is a matter of a particular language syntax which is always the same. This fact led authors of the Xtext framework to create the concept of templates. The developer of a created language can define templates for various statements or other language constructs. The user can use the template according to context and fill a new code into variable parts of the template.
  • Syntax Coloring - This concept allows for distinguishing different code parts by color, font, style, etc.

Configuration

The Xtext framework offers a number of ways to change a standard behavior of the plug-in corresponding to a developed language. One of them is a possibility to configure the Modeling Workflow Engine.

Modeling Workflow Engine

The currently used Modeling Workow Engine 2 (MWE2) is responsible for hierarchical startup of every action which is necessary for the generation of a language plug-in. The engine is basically the component model, whose design is based on the POJO. By default, the runnable configuration file contains application of two component types. The first is the DirectoryCleaner, whose main purpose is to clean a directory from the code of the generated plug-in, which was created by the previous run of the engine. The second is the Generator being responsible for the language plug-in generation. This type of component further consists of fragments that represents used concepts, which were mentioned in the previous sections. The implementation of a fragment is represented by the class having access to some resources provided by the Generator component such as the grammar of a given language, the mechanism for code generation, etc. As the fragments are able to generate the code, it is necessary to register the code somewhere in order to be used by plug-in. For this reason the Xtext framework heavily exploits dependency injections realized by [Google Guice](http://code. google.com/p/google-guice/).

Google Guice

Consider the situation when some code contained in a class A calls a method of some interface or abstract class B. It is well-known that an instance of the super type B must exist before the method is called. Thus the return value of the method is tied with the type of the instance and the status of its global variables. Instead of the instance to be intricately passed through the call stack by parameters in order to make the code of the class A more generic, the concept of dependency injection solves this issue more elegantly. The code of class A with dependency injections contains no instantiations of the super type B. The separated configuration determines which concrete class inheriting from the super type B will be injected into the class A by reflection. This concept is implemented in a diffuse way in Google Guice The injected variables are marked by Java annotations. Configuration of the used concrete classes for injection are realized by a Java declarative class whose methods return a type of a concrete class and standardized method's name contains the name of super type. The Generator component of the Xtext framework generates this configuration classes whose name ends with suffix "Module" thus a language developer can mostly rewrite and use any class of a Xtext concept to modify its standard behavior.