Hallo pl,
Und hinsichtlich der sich hier zeigenden Problematik ist das im Übrigen völlig uninteressant.
Ja. Hat Matthias eingangs dieses Astes ja auch gleich gesagt :) Aber off-topics führen gern zu interessanten Fachgesprächen im Fachforum.
Eine TE ist ein Vehikel, um in der Anwendung Schichtentrennung herbeizuführen. Jede TE definiert irgendeine Syntax zum Einsteuern von Daten, die meisten auch Zusatzsyntax für weitere Operationen, wodurch eine formale Sprache gebildet wird. Es ist relativ egal, ob diese formale Sprache "Smarty" heißt, "PL Template Language", Perl oder PHP. Der Vorteil einer "nicht-Programmiersprache" in der UI-Schicht liegt darin, dass man nicht dazu verleitet wird, dort Business-Logik zu programmieren. Ich kann meine UI-Templates auch rein mit PHP bilden (was Smarty zum Beispiel unter der Haube tut, es transpiliert Smarty-Templates in PHP). Der Vorteil von Template-Sprachen ist auch, dass die für's Template wichtigen Operationen knackig und ausdrucksstark definiert werden können; in einer Universalsprache formulierte Templates sind da umständlicher.
Ja, und weil es Template-Nutzern auf den Keks geht, wenn die TE nur Variablen auflöst und man Code-behind braucht, der die Business-Schicht mit GUI-spezifischem Code vermüllt (bzw. man eine Extra-Schicht zwischen GUI und Business-Schicht einziehen muss, um ein ViewModel aufzubauen), sind in viele TE so viele Möglichkeiten zum Codieren eingesickert, dass sie genauso Turing-vollständig sind wie die Host-Sprache. Sobald ich in einer formalen Sprache die Elemente "sequenz", "alternative" und "iteration" habe, dazu noch die Möglichkeit, irgendwie Werte zu speichern, ist sie Turing-vollständig. Wie hält es deine TE mit Turing?
Und es ward Code!
Rolf
sumpsi - posui - clusi