my.dsl.impl.SomeElement@67cee792 (attr1: SomeValue)
Well, this is not too bad. However this looks completely different to my DSL syntax, which may look like this:
SomeValue {
The content;
}Especially for debugging and logging, I prefer that DSL like output. Since Xtext does not only generates a parser for reading such a text, but also a seralizer for creating the text from a model, I was wondering if that mechanism could be used for the toString method as well. (Actually, Henrik Lindberg pointed out the serializer class -- thank you, Henrik!)
In the following, I describe how to do that. Actually, this is a little bit tricky, and it will cover several aspects of Xtext and the generation process:
- use the generated serializer for formatting a single model element
- tweak the generation process in order to add a new method
- define the body of the newly added method
We will do that by adding a post processor Xtend file, which adds a new operation to the DSL model elements. The body of the operation is then added using ecore annotations. But first, we will write a static helper class implementing the toString method using the serializer.
Use the serializer
Xtext provides a serializer class, which is usually used for writing a model to an Xtext resource. The Serializer class (in org.eclipse.xtext.parsetree.reconstr) provides a method serialize(EObject obj), which returns a String---this is exactly what we need. This class requires a parse tree constructor, a formatter and a concrete syntax validator. Thanks to google Guice, we do not have to bother about these things. Xtext generates everything required to create a nicley configured serializer for us. What we need is the Guice injector for creating the serializer:Injector injector = Guice.createInjector(new my.dsl.MyDslRuntimeModule()); Serializer serializer = injector.getInstance(Serializer.class);
Now we could simply call the serialize method for a model element (which is to be an element of the DSL):
String s = serializer.serialize(eobj);
Since this may throws an exception (when the eobj cannot be successfully serialized, e.g., due to missing values), we encapsulate this call in a try-catch block. Also, we create a helper class, providing a static method. We also use a static instance of the serializer.
Since this helper class is only to be used by the toString methods in our generated implementation, we put it into the same package.
package my.dsl.impl;
import org.eclipse.emf.ecore.EObject;
import org.eclipse.xtext.parsetree.reconstr.Serializer;
import com.google.inject.Guice;
public class ToString {
private static Serializer SERIALIZER = null;
private static Serializer getSerializer() {
if (SERIALIZER == null) { // lazy creation
SERIALIZER = Guice.createInjector(new my.dsl.MyDslRuntimeModule())
.getInstance(Serializer.class);
}
return SERIALIZER;
}
public static String valueOf(EObject eobj) {
if (eobj==null) {
return "null";
}
try {
return getSerializer().serialize(eobj);
} catch (Exception ex) { // fall back:
return eobj.getClass().getSimpleName()+'@'+eobj.hashCode();
}
}
}Post processing
Now we have to implement the toString() method of our model classes accordingly. That is, instead of the default EMF toString method, we want to call our static helper method for producing the String.A generic solution, which can not only be applied for adding the toString method but for all kind of operations, is to use a post processor extension (written in Xtend) to add new operations to the generated ecore model. The overall mechanism is described in the Xtext documentation. We have to write an Xtend extension matching a specific naming convention: <name of DSL>PostProcessor.ext. In our exampel that would be MyDslPostProcessor.
The easy thing is to add a new operation to each classifier:
import ecore;
import xtext;
process(GeneratedMetamodel this) :
this.ePackage.eClassifiers.addToStringOperation();
create EOperation addToStringOperation(EClassifier c):
... define operation ... ->
((EClass)c).eOperations.add(this);For defining the operation, we need:
- the return type of the operation
- the body of the operation
The return type is an EString (which will result in a simple Java String). In EMF, we have to set the type via EOperation.setEType(EClassifier). That is, we need the classifier of EString. With Java, this would be no problem: EcorePackage.eINSTANCE.getEString().
Unfortunately, we cannot directly access static fields from Xtend. At least, I do not know how that works. Fortunately, we can substitute EcorePackage.eINSTANCE with calling a static method of EcorePackageImpl. This static method can then be defined as a JAVA extension in Xtend:
EPackage ecorePackage(): JAVA org.eclipse.emf.ecore.impl.EcorePackageImpl.init();
Note that we return an EPackage instead of the EcorePackage. I assume this is necesssary because we use the EMF metamodel contributor and EcorePackage is not available then. We can now set the EString classifier as return type of the operation: setEType(ecorePackage().getEClassifier("EString"))
Now, we need the body of the operation. Ecore does not directly support the definition of a body, that is there is no field in EOperation for setting the body. Fortunately, we can exploit annotations for defining the body. The default EMF generator templates look for annotations marked with the source value "http://www.eclipse.org/emf/2002/GenModel". The key of the annotation must be "body", and the value of the annotation is then used as the body of the operation. In the body, we simply call our static helper method for producing the DSL-like string representation.
The complete post processor extensions looks as follows:
import ecore;
import xtext;
process(GeneratedMetamodel this) :
this.ePackage.eClassifiers.addToStringOperation();
EPackage ecorePackage():
JAVA org.eclipse.emf.ecore.impl.EcorePackageImpl.init();
create EOperation addToStringOperation(EClassifier c):
setName("toString") ->
setEType(ecorePackage().getEClassifier("EString")) ->
eAnnotations.add(addBodyAnnotation(
'if (eIsProxy()) return super.toString(); return ToString.valueOf(this);')) ->
((EClass)c).eOperations.add(this);
create EAnnotation addBodyAnnotation(EOperation op, String strBody):
setSource("http://www.eclipse.org/emf/2002/GenModel") ->
createBody(strBody) ->
op.eAnnotations.add(this);
create EStringToStringMapEntry createBody(EAnnotation annotation, String strBody):
setKey("body")->
setValue(strBody) ->
annotation.details.add(this);If you (re-) run the GenerateMyDSL workflow, the EMF toString() implementations are replaced by our new version. You can test it in a simple stand alone application (do not forget to call doSetup in order to configure the injector):
public static void main(String[] args) {
MyDslStandaloneSetup.doSetup();
MyElement = MyDslFactory.eINSTANCE.createElement();
e.setAttr1("Test");
e.setAttr2("Type");
System.out.println(e.toString());
}Closing remarks
You probably do not want to really replace all toString methods with the serializer output, as this would create rather long output in case of container elements. In that case, you can add the new operation only to selected classifiers, or use the (generated) Switch-class to further customize the output.
Although the solutions looks straight forward, it took me some time to solve some hidden problems and get around others:
- How to create the serializer using the injector -- and how to create the injector in the first place
- How to access a static Java method from Xtend without too much overhead. Would be great if static fields could be accessed from Xtend directly.
- How to use the post processor with the JavaBeans metamodel contributor. If I switch to the JavaBeans metamodel, my extension didn't get called anymore.
- I'm still wondering where "EStringToStringMapEntry" is defined. I "copied" that piece of code from a snippet I wrote a couple of months ago, and I have forgotten how I found that solution in the first place.
- Sorry, but I have to say it: The Xtend version 1.0.1 editor is crap (e.g., error markers of solved problems do not always get removed). But I've heard there should be a better one available in version 2 ;-)
Usually I'm generating the model code from my ecore models. But sometimes I want to simply query a model, and in these cases a dynamic EMF model is good enough. I wrote a small helper class, providing a very simple query language for dynamic EMF very similar to the JSP Expression Language -- of course less powerful. You can query an EObject using a dot notation and square brakets for defining the index of a list item. E.g.
