Platzhalter sind in PHP "nicht wirklich sinnvoll"

[mermshaus]

@Google weiß alles

Sorry, Edit-Zeitraum ist abgelaufen. Ich habe jetzt glaube ich verstanden, wie du es meintest. Tut mir leid, da war ich etwas auf dem falschen Dampfer. :( Ich hätte es noch umformuliert, aber ich denke, dass der größte Teil meiner Antwort dennoch allgemein nicht verkehrt ist.

Ich versuche mal, die These zu paraphrasieren: „Sobald das Templating komplexere Möglichkeiten unterstützt, möchte ein Anwender diese auch nutzen, was den Lernaufwand steigert.“

Zwei Punkte dazu:

1. Da ist erst mal die Frage, worüber wir hier eigentlich reden. Deshalb habe ich deine Antwort auch erst falsch verstanden. Ich hatte nicht auf dem Schirm, dass es sozusagen das Ziel ist, dem Anwender per Design nur ganz einfache String-Ersetzungen zur Verfügung zu stellen. Das ist natürlich in Ordnung und dafür gibt es definitiv auch Anwendungen. Ich würde auch nicht behaupten, dass es gar keinen (geschwindigkeitsbezogenen) Sinn ergibt, derlei Vorlagen nach PHP zu kompilieren. (So was ist immer ein potenzieller Risikofaktor.) Das deckt aber definitiv nicht ansatzweise alle Anwendungen für Templating ab. Ich denke, dass das in Form von deiner Umsetzung mit dem Kompilieren eher in Richtung Spezialfall geht und dass man bei simplen Ersetzungen ansonsten mit preg_replace_callback oder strtr (womöglich begleitet von Caching der fertigen Ausgabe) in Sachen Performance auch gut genug dabei ist und dass man in komplexeren Fällen dem Anwender ruhig Smarty oder Twig oder dergleichen zumuten darf, weil es bei Bedarf eben auch erweiterte Funktionalität bereitstellt. Es hängt natürlich davon ab, was man entwickelt und wie technisch versiert die Anwender sind.^[1]

2. Ich glaube nicht, dass Nutzer so erpicht darauf sind, alle Feinheiten des genutzten Systems zu lernen. Der „normale Anwender“™ erarbeitet und notiert sich seine drei oder vier Workflows und ist im Grunde glücklich und zufrieden. Da kann man aber auch anmerken, dass es eher selten der normale Anwender ist, der sich überhaupt mit dem Editieren von Templates beschäftigt. Ich glaube, die Leute, die sich an so was rantrauen, sind eher Leute vom Fach oder zumindest Leute, von denen man als Entwickler im Normalfall eine gewisse Kompetenz erwarten kann. Die erwarten dann umgekehrt in vielen Fällen auch durchaus Funktionalität, die über das simple Verschieben von Textblöcken hinausgeht. (Die Ausnahme dazu ist, wenn die Besucher/Nutzer der Seite Templates editieren können. Etwa bei einem Blog-Anbieter. Aber das ist ein Spezialfall, denke ich. Und selbst dort kann simple Logikprogrammierung durchaus erwünscht sein.)

   Was den Hinweis auf kramdown angeht: Markup-Sprachen sind schon noch mal eine andere Geschichte als Templating. Obwohl die eher vernünftige (ich hoffe? ;)) Nutzung von kramdown hier im Forum schon mein Argument stützt, dass sich die meisten Nutzer nicht mit dem Potenzial aufhalten, das eine solche Funktionalität bietet. Die Verbindung oder eine Abgrenzung von Markup-Sprache und Templating scheint mir aber ein ganz interessantes Thema zu sein. Nur fällt mir gerade nicht viel dazu ein.

Als Fazit formuliert: Ich denke nicht, dass man in normalen Fällen kompilierte Templates benötigt, wenn sich die Funktionalität darauf beschränkt, Platzhalter zu verschieben.

Noch mal meine Entschuldigung, deinen Beitrag erst falsch verstanden zu haben.

---

1. Das ist ein durchaus interessantes Thema. Meine Erfahrung dazu ist, dass es so oder so eher trübe aussieht, derlei Funktionalität für „Programmierlaien“™ bedienbar zu machen (auch wenn ich Leute da für lernfähig halte, aber lernen müssen sie auch „einfachste“ Systeme). Ich erkenne aber an, dass es gewünscht sein kann, Dinge zumindest so zu gestalten, dass sie nichts kaputt machen können (etwa durch das Ermöglichen von XSS). Wobei sich Template-Engines in Sachen Funktionsumfang wahrscheinlich auch konfigurieren lassen. Das weiß ich ohne Recherche nicht. ↩︎