EMFText Overview

EMFText is a tool which allows users to define a plain textual syntax for their Ecore based metamodel and to generate components to load, edit and store model instances. The syntax is specified by a so called concrete syntax specification which are usually stored as files with the suffix .cs. A cs specification is directly related to one ore more Ecore metamodel(s) whose structure implicitly pretends a grammar skeleton. The following figure gives an overview on how the generator part of EMFText works and what components it actually generates.

Through combining metamodel and cs specification, EMFText derives a context-free grammar and exports it as an ANTLR parser specification. This specification contains annotated semantic actions which cover the largest part of metamodel instanciation. EMFText then transparently delegates parser and lexer generation to ANTLR by passing the generated grammar file. Since ANTLR does not cover the whole class of context-free grammars we can not guarantee the generation of a working parser forarbitrary cases. However, in most cases generation should be sufficient.

While parsers are used to load model instances from textual representations a printer is needed to do the inverse, e.g. to print an in-memory instance of the metamodel back to a textual representation. The printed results then should again be parseable by the corresponding parser. Both instances (printed and loaded) should be equal. Furthermore, printers should produce a formatted and human-readable output. The EMFText built-in printer generator tries to achieve these goals by interpreting the cs file and the derived grammar. cs specifications can be enriched by special operators to indicate that on a specific position white-spaces or newlines have to be printed. Additionally, it uses information about literals (e.g. keywords) in defined languages which are removed from model instances. As for parser generation, EMFText does not guarantee that printer generation works for arbitrary cases but mostly it is be a convenient solution.

EMFText also generates a set of resolvers. Resolvers convert parsed token strings to an adequate representation in the metamodel instance.

TokenResolvers implement a mapping from the string value of a specific token to a native Java type (e.g. boolean, int, String etc.). In the standard implementation TokenResolvers can automatically remove and add (printing) pre- and suffixes. The conversion to native java datatypes is done by delegation to the corresponding Java type conversion functions. For example, Integer.parseInt("42") results in an int valued 42. Since this behavior is only desireable for conrete syntaxes mirroring exactly (or at least partially) the Java syntax for primitive types, users are expected to implement more adequate mapping functions as needed.

Resolvments depending on context are meant to be realised by implementing ReferenceResolvers. For these only stubs are generated. While TokenResolvers are directly invoked by parsers, ReferenceResolvers are triggered on demand later by EMF's proxy resolution mechanism. An additional feature is the evaluation of eventually annotated OCL constraints. With OCL, consistency conditions can be declared on the metamodel to further improve quality of EMFText based developments.