New Features

This section provides an overview of new possibilities with TMF Xtext compared to oAW Xtext. Please note that this list is neither complete nor does it explain every aspect in detail to keep this document tight.

Dependency Injection with Google Guice

Beyond the mentioned architectural overhaul that carve out separate concerns in a meaningful way these different classes of TMF Xtext are wired using Google Guice and can easily replaced by or combined with your own implementation. We could have foreseen some common needs for adaption but with this mechanism you can virtually change every aspect of Xtext without duplicating an unmanageable amount of code.

Improvements on Grammar Level

The Xtext grammar language introduces some new features, too. Read the chapter grammar language to understand the details about all the improvements that have been implemented.

Grammar mixins allow you to extend existing languages and change their concrete and abstract syntax. However the abstract syntax (i.e. the Ecore model) can only be extended. This allows you to reuse existing validations, code generators, interpreters or other code which has been written against those types.

In oAW Xtext common terminals like ID, INT, STRING, ML_COMMENT, SL_SOMMENT and WS (whitespace) were hard coded into the grammar language and couldn’t be removed and hardly overridden. In TMF Xtext these terminals are imported through the newly introduced grammar mixin mechanism from the shipped grammar org.eclipse.xtext.common.Terminals per default. This means that they are still there but reside in a libraries now. You don’t have to use them and you can come up with your own set of reusable rules.

Reusing existing Ecore models in oAW Xtext didn’t work well and we communicated this by flagging this feature as ‘experimental’. In TMF Xtext importing existing Ecore models is fully supported. Moreover, it is possible to import a couple of different EPackages and generate some at the same time, so that the generated Ecore models extend or refer to the existing Ecore models.

The grammar language gained one new concept that is of great value when writing left-factored grammars (e.g. expressions). With actions one can do minor AST rewritings within a rule to overcome degenerated ASTs. You will find an in-depth explanation of actions in the dedicated chapter in the reference documentation.

Fine-grained control for validation

In order to make more expensive validations possible without slowing down the editor, TMF Xtext supports three different validation hooks.

  1. FAST constraints are triggered by the reconciler (i.e. 500 ms after the last keystroke) and on save.

  2. NORMAL constraints are executed on save only.

  3. EXPENSIVE constraints are executed through an action which is available through the context menu.

Please note that when using Xtext models for code generation the checks of all three categories will be performed.

Beside this it is now possible to add information about the feature which is validated.


  context Entity#name ERROR "Name should start with a capital "+this.name+"." :
    this.name.toFirstUpper() == this.name;

If you add the name of a feature prepended by a hash (‘#’) in Check, the editor will only mark the value of the feature (name), not the whole object (Entity). Both concepts, control over validation time as well as pointing to a specific feature, complement one another in Check and Java based validation.