Die Sache mit DSL und XML und wie ich meine Arbeit automatisieren kann, fesselt mich noch immer. Ich habe mich an zwei Sachverhalte erinnert:
1) Es gibt im Standard-Java eine Klasse StringTokenizer. Die leistet in Ansätzen das, was ein Lexer kann. Die api-Doku führte mich zum StreamTokenizer, der etwas leistungsfähiger und flexibler ist.
2) Es gibt ein Entwurfsmuster mit Namen “Interpreter“.
Nun bestimme ich, dass meine DSL so ist, dass das erste Wort in einer Zeile ein Kommando-Name ist und der Rest der Zeile sind die Parameter für das Kommando. Ich brauche also etwas, das jede Zeile passend interpretiert, also das Kommando am Anfang erkennt und daraufhin einen passenden Interpreter findet, dem dann überlassen wird, wie weiter zu verfahren ist.
Java’s StringTokenizer zerlegt jede Zeile. Mein InterpreterBuilder erzeugt mittels Reflection-API einen passenden Interpreter, beispielsweise einen FileExistsPInterpreter wenn die Zeile mit “FileExistsP” beginnt oder einen UnknownCommandInterpreter, wenn kein passender Interpreter gefunden wird. Der Interpreter liest dann – wieder mit Hilfe des StringTokenizer – den Rest der Zeile, bereitet diesen Rest als Parameter für ein FileExistsP-Objekt auf, erzeugt das Objekt und ruft dessen execute-Methode auf.
Das beschriebene Verfahren liegt in diesem tar-gz-Archiv mit falschem Dateinamen, damit WordPress nicht meckert. Es ist ein gepacktes Eclipse-Projekt, die enthaltene jar-Datei muss im Build Path liegen. Startpunkt ist de.aysx.mpfinterpreter.Main. Das wird mit einem Dateinamen aufgerufen, beispielweise so, das die beiliegende Datei “einProgramm.dsl” aufgerufen wird.
NB FileExistsP ist auf das Minimum reduziert: Einen Befehlsnamen und der unabdingbare Parameter. FileCreatedTodayP hat noch “filename=” im Aufruf. Das ist ein Rest vom vorhergehenden und wird überflüssig, wenn das hier beschriebene Verfahren komplett ausformuliert ist.