Goodbye XML – Befreiungsakt mit Xtext

IDE per Fingerschnipp

Die Laufzeitinfrastruktur von Xtext ist schon sehr fortschrittlich. Man bekommt nicht nur einen Parser, sondern auch getypte EMF-Klassen [3] (ähnlich, aber wesentlich besser als JAXB), einen Linker für Querverweise, einen Serialisierer (oder Unparser) und viele Dinge mehr. Darüber hinaus erlaubt die flexible, auf Google Guice [4] basierende Architektur, wirklich jeden Aspekt der Implementierung anzupassen oder sogar ganz auszutauschen.

Das Besondere an Xtext ist jedoch die umfassende Eclipse-Integration. Xtext benutzt die Informationen aus der Grammatik, um eine Entwicklungsumgebung an die Hand zu geben, die sich nicht nur nahtlos mit den Java Development Tools (JDT), also der Java IDE in Eclipse, integrieren lässt, sondern auch vom Funktionsumfang nahe an das große Vorbild herankommt. Von einem mächtigen Texteditor mit den aus Java gewohnten Funktionen, z. B. Syntax Coloring, Validierung, Autovervollständigung, Autoformatierung oder Outline Views, über IDE-Aspekte, wie globale Navigation, Indizierung, globale Suche und eine Integration in den Eclipse Incremental Builder, ist alles dabei, was eine moderne Entwicklungsumgebung ausmacht. Die Eclipse-abhängigen Teile sind zwar strikt von den Laufzeitkomponenten getrennt, können aber ebenfalls individuell angepasst und erweitert werden. Auch hier setzt Xtext auf die konsequente Verwendung von Dependency Injection mit Google Guice.

Verarbeitung der Daten

Sowohl für XML als auch für Xtext-basierte Sprachen existieren mannigfaltige Möglichkeiten, wie die abgelegten Informationen nach dem Editieren weiterverarbeitet werden können. Xtext spielt als Teil des Eclipse Modeling Project durch die Verwendung des allgegenwärtigen Modellierungsframeworks EMF von Haus aus mit zahlreichen anderen Eclipse-Technologien zusammen: sei es EMF Compare für das Ermitteln struktureller Unterschiede zwischen verschiedenen Versionen einer Datei, GMF für die grafische Bearbeitung oder ausgefeilte Templatesprachen wie Xpand [5] und Acceleo. Dadurch ist es sehr einfach möglich, Codegeneratoren, Interpreter oder Compiler beziehungsweise Transformationen zu implementieren. Für XML wiederum existiert mit XSLT eine mächtige Sprache für die Umwandlung der vorliegenden strukturierten Daten in andere XML-Dialekte, in HTML oder auch einfach nur in menschenlesbaren Text.

Um ein Gefühl für die jeweils verfügbaren Technologien zu vermitteln, haben wir mithilfe von XSLT aus der reduzierten pom.xml die Notation der Xtext POM erzeugt und nutzen Xpand als Templatesprache für den umgekehrten Weg (Listing 5 und 6).

Abb. 2: Der Xtext-Editor in Aktion
Listing 5: Transformation mit XSLT
Listing 6: Transformation mit Xpand
«IMPORT org::xtext::simplemaven::simpleMaven»
«EXTENSION templates::Extensions»
«DEFINE main FOR Project-»
«FILE name+"-pom.xml"-»
4.0.0«groupId()»«artifactId()»«kind.name»«version»«description»«url»
«IF !dependencies.isEmpty»
  
«FOREACH dependencies AS d»
    «groupId(d.name)»«groupId(d.name)»«d.version»«d.scope.name»
«ENDFOREACH»
  
«ENDIF»

«ENDFILE-»
«ENDDEFINE»

Die zugehörigen Extensions:

import org::xtext::simplemaven::simpleMaven;
groupId(Project this) :
  name.split(".").withoutLast().toString(".");
artifactId(Project this) :
  name.split(".").last();

Beim Vergleich der beiden Lösungen fällt auf, dass sie sich in der Länge scheinbar nicht wesentlich unterscheiden. Auf den zweiten Blick wird jedoch deutlich, dass das Template für die Xpand-basierte Umsetzung fast genau so wenige (oder eher viele) Zeilen hat, wie die dadurch generierte XML-Datei. Die Konstrukte der Templatesprache selbst verursachen nur geringes Rauschen in der Abbildungsvorschrift.

Ganz anders sieht es im XSLT-Template aus. Da auch XSLT ein XML-Format ist, gibt es wieder sehr viele öffnende und schließende Elemente, die von der eigentlich transportierten Information und damit von den Regeln ablenken, die auf die Eingaben anzuwenden sind. Obwohl wir nur wenige Zeilen in unserer sehr kompakten Notation erzeugen wollen, ist dies auf den ersten Blick nur schwer zu erfassen. Die vielen XSLT-Syntaxelemente lenken von den statischen Informationen ab, die sich in der generierten Zieldatei wiederfinden. Der Vorteil, den wir für die Xtext-basierte POM gegenüber dem XML-Format identifiziert haben, lässt sich eins zu eins auf den Vergleich von Xpand mit XSLT übertragen. Wieder gilt, dass die spezialisierte Syntax der Templatesprache dem generischen Charakter von XML überlegen ist.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.