Harald Kirsch

genug Unfug.

2014-07-06

Template Engines

Contents

Tirade

Über Javaworld.com bin ich auf diesen Blog gestoßen, der uns nahebringen will, dass wir statt JSP nun eine bestimmte Template Engine verwenden sollen. Dass JSP eine kleine Pest ist, da bin ich mit ihm allemal einer Meinung, zum einen, weil ich es für Unfug halte, dass man viele Programmiersprachen und Syntaxen in einer Datei vermischelt (xml, html, Java, expression language bei JSP), zum anderen weil ich der Meinung bin, dass Webseiten programmiert werden müssen, und dass XML (also JSP) eine ziemlich besch...eidene Syntax für's Programmieren ist.

All das ist viel besser mit einer "template engine"? Unfug! Auch im Template kommt schnell der Wunsch auf, eine "expression syntax" zu verwenden. Und natürlich will man Kontrollstrukturen wie if und for haben --- wie soll man sonst Anteile der Seite dynamisch ausblenden, oder sich wiederholende Elemente im Template abbilden. Wenn man all das haben will, warum dann nicht gleich eine komplette Programmiersprache? Aber die Templatesprache ist typischerweise eine Hackertummelwiese wo die Entwickler mal ein paar Funktionen reingehauen haben, die sie brauchten. Mit einem sauberen Sprachdesign hat das in der Regel nichts zu tun. Warum soll man eine schlecht designte Sprache zum Programmieren nutzen? Unfug!

Vorschlag

Webseiten, die aus einer Javaapplikation kommen, sollten auch in Java geschrieben werden. Dagegen gibt es natürlich diverse Einwände:

  1. "Dann ist der Code voller println()". Wieder Unfug! Natürlich braucht es Klassen, mit denen man den HTML-DOM aufbaut und die ihn dann im Servlet hübsch formatiert rausschreiben. Das hat noch den Vorteil, dass das HTML keine Syntaxfehler mehr enthält. Das API muss ja nicht so furchtbar sein, wie die XML-APIs von Java.
  2. "Die Designer können aber mit Java nicht umgehen." Richtig. Und können die mit der Templatesprache umgehen? Die Designer sollen die HTML-Struktur vorgeben und sich ans CSS halten. Die paar DIVs dann im Code zu generieren ist programmiertechnischer Kleinkarm, den man nebenbei erledigt, während man sich um die wichtigen Dinge, nämlich die Inhalte, in einer adäquaten Programmiersprache kümmert.
  3. "Bei jeder Designänderung muss das Java neu compiliert werden." Na hoffentlich. Wir wollen doch nicht im Produktivsystem im JSP rumfummeln, oder? Und ob wir dann in der Entwicklung in einer JSP oder Template-Datei was ändern, oder im Javacode --- wo ist da der Unterschied?
  4. "Selbst mit einer HtmlBuilder Klasse kann man die Struktur des HTML nicht mehr erkennen." Ja und Nein. Das ist eine Frage der Übung, genau wie es Übung braucht in einem HTML/JSP-Tag/scriptlet/include Verhau oder einem mit Kontrollstrukturen verwursteten Template die Seitenstruktur zu erkennen. Der Vorteil der reinen Generierung in Java ist, dass man alle Vorteile von "clean code" auch auf die HTML-Generierung anwenden kann. Nach kurzer Zeit hat man das raus und hat Strukturänderungen am HTML schneller durchgezogen, als im Template oder JSP mit copy/paste lauter Durcheinander zu erzeugen.

Schlusswort

Klar, das hier ist eine Tirade in der ich übertreibe. Dass es niemand gibt, der HTML rein im Java erzeugt, hat vielleicht einen guten Grund, den ich noch nicht verstanden habe. Vielleicht hat sich aber auch schlicht noch niemand getraut, weil es ja keiner macht. Ich hab's gemacht in einem in der Tat kleinen Projekt. Es hat wunderbar funktioniert.