09 November 2016
Um mit JavaServer Faces «rumzupröbeln», habe ich vor geraumer Zeit kurzerhand einen kleinen Checkerservice mit den ilivalidator-Bibliotheken gemacht. Weil ich auch noch etwas Einfacheres haben wollte, habe ich mit Spring Boot einen «no-frills» Webdienst auf die Beine gestellt:
Die Funktionalität ist eingeschränkt: Das Ein- und Ausschalten von Checks wird nicht unterstützt. Wäre aber z.B. machbar, wenn man ZIP-Dateien mit einer TOML-Datei hochladen könnte.
Im Fokus stand bei dieser Umsetzung weniger das GUI, sondern vielmehr die Webwendung ohne GUI. Mit curl und Konsorten geht das Prüfen von INTERLIS-Dateien so jetzt wunderbar:
Die Syntax ist simpel:
-v
: curl erzeugt möglichst viel Output.
-XPOST
: Es wird ein POST-Request durchgeführt.
-F file=@ch_254900_error.itf
: Mit diesem Parameter werden die Daten auf den Server hochgeladen. Dabei entspricht file
dem Namen des HTML-Input-Elementes vom Typ file der HTML-Webseite.
Es folgt die URL des Webdienstes (Achtung: Slash am Ende der URL). Wie einfach, effizient und im Prinzip elegant so ein Dienst geschrieben werden kann, sieht man im Quellcode. Es wird zweimal auf die gleiche URL gemappt. Der einzige Unterschied ist die Request-Methode. Einmal GET und einmal POST. Je nach Request-Methode erscheint entweder die HTML-Webseite oder es wird die Prüfung der hochgeladenen Datei durchgeführt.
In die zu prüfendene INTERLIS-Datei habe ich absichtlich einen Fehler eingepflanzt. Der Output der INTERLIS-Prüfung ist ziemlich unübersichtlich. Vor allem auch wegen des Outputs von curl selbst:
Auf der viertletzten Zeile ist der Fehler ersichtlich: Ein LFP3 ohne Nummer. Um das Ganze übersichtlicher zu machen, lassen wir beim nächsten Aufruf den -v
-Parameter und den Parameter -XPOST
. -XPOST
hat zwar keinen Einfluss auf den Output, ist aber überflüssig, da curl standardmässig einen POST-Request ausführt. Ist schon übersichtlicher geworden:
Jetzt ist nur noch Output von ilivalidator sichtbar. Was mich aber in den allermeisten Fällen überhaupt nicht interessiert, sind die Information zu den Repositories und Programmversionen etc. etc. Oder anders formuliert: Ich will nur die Fehler sehen. Für diesen Usecase reicht ein wenig «Pipe-und-Grep-Zauber»:
Der Pipe-Operator |
leitet die Ausgabe des Befehls (hier curl) direkt an einen anderen Befehl. In unserem Fall ist dieser andere Befehl grep
. Mit grep lassen Dateien etc. nach Texten durchsuchen. Weil wir eben nur an Fehlern interessiert sind, suchen wir nach «Error». Eine Unschönheit gibt es noch: diese Datei-Hochlade-Information. Warum die jetzt plötzlich erscheint, ist mir schleierhaft. Mit einem simplen zusätzlichen -s
beim curl-Befehl verschwindet diese auch noch:
Bei macOS und Linux ist curl natürlich mit dabei oder zumindest sofort installiert. Unter Windows ist curl jedenfalls auch verfügbar. Eventuell reicht unter Windows 10 schon die Linux Bash Shell.