Über den Sinn und Unsinn einer PHP Template Engine

Vor ein paar Tagen erschien auf dem YouTube Kanal von Vitalij Mik ein Video über PHP Template Engines, welches recht schnell sehr polarisierende Reaktionen in den Kommentaren hervor rief. Augenscheinlich scheint der Einsatz von PHP Template Engines in der Community ein sehr konfliktbehaftetes Thema zu sein. Ich werde mal versuchen zu erklären, warum der Einsatz von Template Engines aus meiner Sicht so überhaupt keinen Sinn ergibt und eher von schlechtem Stil, als von Können zeugt.

Was ist eine Template Engine eigentlich?

Um es mal stark vereinfacht zu formulieren: Eine Template Engine ist eine Art Adapter für die Präsentationsschicht und verspricht einfacheres Handling von Daten innerhalb eines Templates. Oftmals implementiert eine Template Engine eine eigene Syntax, die über die Logik der Template Engine in sauberes PHP übersetzt wird.

<h1>{$title}</h1> 
<ul>    
    {foreach item=item from=$items}    
    <li>{$item}</li>       
    {/foreach}
</ul>

Das gezeigte Code-Beispiel zeigt die Implementierung einer einfachen foreach-Schleife in der Syntax der Smarty Template Engine.

<h1><?= $title ?></h1>
<ul>
    <?php foreach ($items as $item): ?>
        <li><?= $item ?></li>
    <?php endforeach; ?>
</ul>

Das zweite Code Beispiel zeigt die gleiche foreach-Schleife in einem HTML Template mit PHP umgesetzt.

Welche Vorteile hat eine Template Engine

Welche Vorteile bringt der Einsatz einer Template Engine, wie z.B. Twig , Mustache oder Smarty mit sich? Relativ häufig liest man folgende Punkte, die den Einsatz einer Template Engine rechtfertigen sollen:

  • Saubere und einfachere Syntax innerhalb eines Templates
  • Der Zwang die Business Logik von der Präsentation trennen zu müssen
  • Implementierung von sicherheitsrelevaten Funktionen, wie z.B. das Escaping von Werten bevor sie ausgegeben werden

Weitere Vorteile wollen mir jetzt einfach nicht einfallen. Falls ihr noch relevante Vorteile kennt, die für den Einsatz einer Template Engine sprechen, schreibt sie gern in die Kommentare.

Gibt es auch Nachteile?

Gut, vielleicht bin ich ein wenig voreingenommen. Aus meiner Sicht ist der Einsatz von Template Engines in den wenigstens Szenarien ein Vorteil. Hier mal ein paar Punkte, warum dies so ist:

  • Eine zusätzliche Syntax muss erlernt werden, obwohl PHP von Beginn an den Anspruch mit sich brachte selbst eine Template Engine zu sein
  • Eine zusätzliche Logik wird implementiert, die die Resourcen belastet. Der Speicherverbrauch und die Ausführungszeit werden zu Gunsten einer Logik belastet, die niemand benötigt. Zusätzliche Software muss auf dem aktuellen Stand gehalten und getestet werden.
  • Wenn Template Engines dazu eingesetzt werden die Business Logik von der Präsentation zu trennen, liegt das Problem eher beim Entwickler, der das Prinzip Seperation of Concerns nicht verstanden hat.

Ja, zugegeben klingt das ein bisschen offensiv. Die Nachteile liegen aber auf der Hand.

Oftmals wird tatsächlich gesagt, dass der Einsatz einer Template Engine Vorteile für die Designer mit sich bringt, die dann einfach Teile des Templates an der Stelle verwenden können, an der sie tatsächlich benötigt werden. Ob der Designer jetzt einen foreach-Block lesen kann, der mit PHP oder mit Smarty geschrieben wurde, ist aber vollkommen irrelevant. Fakt ist, dass der Designer immer eine Syntax beherrschen muss. Wenn er sich Smarty oder Twig aneignen kann, kann er sich auch gleich die PHP Syntax in Templates aneignen.

Viele Entwickler denken auch nicht drüber nach, dass der Einsatz einer Template Engine auch immer Resourcen frisst. Natürlich leben wir heute in einer Zeit, in der der Grundsatz, dass Anwendungen so performant wie möglich sein müssen, durch große Arbeitsspeicher und performantere CPUs ein wenig relativiert wurde. Dennoch ist es aus meiner Sicht unsinnig eine Logik zu implementieren, die eine eigene Syntax bereit stellt, um diese dann während der Laufzeit wieder in reines PHP zurück zu interpretieren. Dann kann man Templates auch gleich mit PHP schreiben und auf diese ganze Ruminterpretiererei verzichten. Zudem schafft man sich auch immer ein zusätzliches Modul an, welches aktualisiert und getestet weden muss. Template Engines kosten am Ende eines Tages also bares Geld. Template Engines sind in keinem Fall eine Erleichterung. Für niemanden. Weder für den Designer noch für den Entwickler. Natürlich könnte man jetzt sagen, dass die Laufzeitprobleme durch Caching und sonstige zusätzliche Mechanismen gelöst werden könnten. Das alles sind aber nur Hilfsmittel, die man ohne den Einsatz einer Template Engine nicht brauchen würde.

Kommen wir zu dem Punkt, den ich als größte Krücke von PHP Template Engines sehe. Der große, so gut klingende Vorteil, dass man gezwungen wird Business Logik von der Präsentation zu trennen. Der Vorteil, der so hübsch klingt, aber keiner ist. Wenn ein Entwickler eine Template Engine benötigt, um die Business Logik von der Präsentation zu trennen, sollte man das Problem dahinter auch klar adressieren. Der Schwachpunkt ist da eher der Entwickler, der darin endet, dass er Business Logik in sein HTML Template schreibt. Davor wird ihn auch keine Template Engine retten. Denn alle gängigen Template Engines ermöglichen dem Entwickler Business Logik in sein Template zu implementieren. Es wäre weitaus sinnvoller den Entwickler an diesem Punkt noch mal an die Hand zu nehmen und ihm die Basics im Sinne von Seperation of Concerns zu erklären.

Fazit

So hart das jetzt klingen mag. PHP Template Engines haben sich selbst überlebt. Man benötigt sie einfach nicht oder nicht mehr. PHP war von Anfang an auch als Template Engine gedacht, die man leicht erlernen kann. Seitdem hat sich PHP weiter entwickelt. Gängige Software-Paradigmen gelten eben auch für die Entwicklung mit PHP. Wenn ein Entwickler verstanden hat, dass man Business Logik von der Präsentation zu trennen hat, bin ich mir sicher, dass eine Template Engine nur noch als Einschränkung empfunden wird, die keinerlei Mehrwert bietet.

13 Gedanken zu „Über den Sinn und Unsinn einer PHP Template Engine“

  1. Sorry, aber da bin ich völlig gegenteiliger Ansicht! Ein Template Engine macht in jedem Falle viel Sinn! Nicht nur, wie im simpelsten Fall bei Word-Serienbriefen, sondern erst recht bei recherchierenden Web-Anwendungen: Ich mache eine Suche (via select * from …) und bekomme eine Anzahl Ergebnisse mit je einer Anzahl variable=wert Ergebnissen. Ob ich das nun in einer „Details“-Page oder in Übersichten oder in Medium-Detailed-Ergebnissen ausgebe, ist völlig Wurscht, da die Präsentation reines html ist. Und die Trennung zwischen Präsentation und Code ist von daher nützlich, da ich sowohl im laufenden Betrieb die Datenbank erweitern kann, als auch die html-Präsentation austauschen kann ohne dass Fehler oder Stillstand entstehen!
    Mit freundlichen Grüßen aus Bochum
    Und DIESE Website funktioniert nicht, da die Knöpfe weg sind wenn man zu viel Text eingibt! Ganz schlechte Programmierung!!!

    Antworten
    • Hey Dieter,

      ich kann Dir da nicht zustimmen. Ich verstehe Deinen Einwand. Aber grundsätzlich gilt immer die Logik von der View Schicht zu trennen. Dieser Grundsatz hat aber relativ wenig mit einer Template Engine zu tun. SQL Statements gehören in ein Repository, oder um es weitläufiger auszudrücken: in die Business Logik. Die View Schicht verarbeitet lediglich die zuvor ermittelten Daten. Mir persönlich ergibt sich mittlerweile der Sinn hinter PHP Template Engines nicht mehr. Wenn ich meine Anwendung gut programmiert habe, ist es sehr viel performanter eine einfache PHP foreach-Schleife in meinem Template auszuführen, als eine Template Engine einzubinden, die eine zusätzliche Syntax integriert, die dann von der Template Engine wieder zurück in natives PHP übersetzt wird. Wieso dann nicht gleich PHP? Ich bleibe dabei: Template Engines bleiben unnötig.

      Achso ja … als versierter Developer wirst Du sicherlich festgestellt haben, dass das hier eine WordPress Installation ist. Ja, zugegeben – das Template ist etwas in die Jahre gekommen. Dieser Kritik nehme ich mich an. Dafür, dass DIESE Website aber NICHT!!! funktioniert, hast Du trotzdem einen ganz akzeptablen Kommentar abgegeben. 😉 Wenn ich Zeit finde, werde ich ein neues, aktuelleres Template kaufen, so dass die Seite hier in einem neueren, „funktionierenderem“ Design erscheint. Versprochen. Ohne zig Ausrufezeichen.

      Antworten
      • Oups, es gibt ja eine Antwort – hab ich erst mitbekommen, als ich eine eMail bzgl. des nächsten Beitrages bekam…

        Ich muss mich da etwas relativieren, denn ich bezog mich nicht auf PHP-Anwendungen mit PHP-Template Engines, ich meinte eher den grundsätzlichen Gebrauch von Template Engines in großen, generischen Anwendungen, wie z.B. ebay oder Amazon.
        Da ergänzt man seinen „Datenhorizont“ durch neue „Perspektiven“ in beliebigen Datenbank-Tabellen mit Eltern-Kinder-Verpointerung und stellt der Auflistung oder des Einzelexemplares der Präsentationsebene über eine Template Engine ALLE entsprechenden Daten zur Verfügung, und dort, ggf. auf html-Ebene wird mal eben ein weiterer Link mit relativen Daten dieses Exemplares hinzugefügt. Ohne, dass „der Laden stillsteht“.

        Ich, der versierte – und alte – Developer habe so etwas vor nicht ganz 20 Jahren in Java mit stringtemplate als TE und dem üblichen Javascript erstellt. Inzwischen mach ich nur noch kleine Sachen Hobby-mäßig auf nem PC mit VB oder nem Raspberry mit PHP und Python.

        Begonnen habe ich das Programmieren 1968 mit Focal, Basic und Fortran auf Rechnern von IBM und Digital Equipment. Später wurde es dann C und Java auf Unix und VC und VB auf dem PC. Ohne überheblich wirken zu wollen: Ich habe Plattformen kommen und gehen gesehen. Und mit ihnen Abteilungsleiter, die sich für neue kehrende Besen gehalten haben und sich nichtmals als harte Borste erwiesen …

        Rückblickend muss ich sagen, eine Template-Engine erleichtert einem das modulare Arbeiten sehr, gerade in Verbindung mit (inzwischen) schnellen Interpretern, die es z.B. über eval() gestatten, beliebigen Code einer Anwendung im laufenden Betrieb hinzuzufügen.

        Also mein Fazit: Die Nutzung einer Template Engine ist in großen generischen Applikationen in einem großen wachsenden Datenhorizont mit schnell zu ändernder und individuell konfigurierbarer Präsentation unerlässlich. (Zack, und ohne zig (3) Ausrufezeichen)

        Mit freundlichen Grüßen

  2. Da soll man auch einen anderen Aspekt sehen: Templates verfügen nur über die Informationen mit denen die beliefert werden. Innerhalb des Templates kann man nicht z.B. DB auslesen und Daten zu „var_dump“-en ist auch nicht möglich. In Teams, wo Templates nicht von Entwickler erstellt werden ist ein Template-Engine ein Muss. Noch ein gutes Feature ist die Vererbung von Templates.

    Antworten
    • Hi Alexander,

      danke für Deinen Kommentar. Lass mich auf die verschiedenen Punkte eingehen, die Du in Deinem Kommentar genannt hast.

      Templates verfügen nur über die Informationen mit denen die beliefert werden

      Brauche ich dafür eine Template Engine oder muss ich nicht einfach nur ein disziplinierter Entwickler sein, der sich an verschiedene Grundsätze des Programmierens hält? Das, was Du hier beschreibst, ist einfach der Grundsatz Separation of Concerns. Oder um es etwas konkreter zu sagen: Business Logik gehört nicht ins Template. Wenn ich sauber programmiere, wird die Business Logik vom Controller erledigt und dem entsprechend werden nur Daten ausgeliefert, die für das Template relevant sind. Aus meiner Sicht benötige ich dafür keine Template Engine. Lediglich ein wenig Disziplin und ein paar Coding Standards, um diese Art von Code Qualität zu erlangen. Nur, weil man PHP Business Logik in einem Template ausführen könnte, rechtfertigt das noch lange nicht den Einsatz einer Template Engine.

      In Teams, wo Templates nicht von Entwickler erstellt werden ist ein Template-Engine ein Muss.

      Ich verstehe Dein Argument. Dieses Argument wird durchaus öfter genannt. Ich frage hier immer ganz plump WARUM? Jemand, der sich mit Templates auseinander setzt, muss zwingend HTML und CSS Standards drauf haben. Alles andere muss zusätzlich gelernt werden. Ob ich nun die Syntax einer Template Engine lerne, oder mich direkt mit simplen PHP Schleifen-Konstrukten oder if/else Bedingungen auseinander setze. Der Effekt bleibt der gleiche. Die Syntax einer Template Engine zu lernen ist genau so aufwendig, wie die Syntax von elementaren PHP Sprachkonstrukten zu erlenen. Letzteres zieht eben nur nicht den Overhead einer Template Engine mit sich.

      Noch ein gutes Feature ist die Vererbung von Templates

      Selbst innerhalb der Template Engine Gemeinde scheiden sich hier die Geister. Das Konzept dahinter ist einfachste Vererbung, um Templates zu erweitern. Braucht man das wirklich? In den letzten 15 Jahren meiner Selbstständigkeit gab es kein einziges Team, welches darauf zurückgegriffen hat. In einigen Teams war man sogar der Meinung, dass man schon weit vorher etwas falsch gemacht haben muss, um einen Use-Case von Template Vererbung zu rechtfertigen. Ja, das ist ein offensiver Standpunkt. Aber auch hier schließe ich mich an. Das ist nichts, was man mit reinem PHP nicht auch hinbekommen würde.

      Antworten
  3. Danke für den sehr interessanten Artikel. In den meisten Fällen würde ich dir 100% Recht geben. Gerade wenn man alleine oder im sehr kleinen Team arbeitet wird eigentlich keine Templates Engine benötigt, da PHP alles mitbringt, was man dafür braucht. Gerade die Short-Tags bei PHP sind genau so übersichtlich zu nutzen wie die Befehle einer Templates Sprache.

    Aber es gibt ein paar Punkte, die vor allem bei großen Projekten mit großen Teams zu tragen kommen.

    1. Templates Sprachen sind in der Regel Programmiersprache unabhängig. Wenn PHP gut ohne Templates klar kommt, kommen andere Sprachen nicht so gut klar damit. Der Frontende Entwickler kann in anderen Projekten direkt los legen ohne die Programmiersprache zu können oder gar zu kennen.
    2. Templates lassen sich dadurch leichter in anderen Projekten wieder verwenden und vereinfachen die Migration auf eine andere Sprache.
    3. Wenn man PHP im Templates zulässt, gibt man dem Frontend Entwickler Team sehr viel macht (Zugriff auf die Datenbank, etc) die man als erfahrener Backend Entwickler nicht unbedingt abgeben will.
    4. Wegen dem Overhead der Templates engine: In den meisten Frameworks ins eine Templates engine implementiert, also direkt verfügbar, das minimiert den Initialen Aufwand enorm.

    Ich bin mittlerweile auch mehr dazu übergegangen, Backend und Frontend komplett zu trennen und über eine saubere API zu verbinden, das beendet im Backend die Frage nach dem Templates.

    Antworten
    • Hey Caspar,

      danke für Deinen detaillierten Kommentar. Ich kann die von Dir genannten Punkte vollkommen nachvollziehen, möchte aber dennoch ein paar Worte dazu verlieren. Gerade bei großen Teams hat der Verzicht einer Template Engine enorm große, positive Auswirkungen auf die Kommunikation zwischen Front- und Backend Entwicklern. Die Backend Entwickler werden gezwungen sauberer zu arbeiten, so dass der Frontend Entwickler sauber struktuierte Datenmodelle geliefert bekommt, die er in seinen Templates ohne großen Aufwand anwenden kann. Zumal sich diese sauber strukturierten Datenmodelle durch das ganze Projekt ziehen. Somit wissen sowohl Front- als auch Backend, wovon sie reden, wenn sie miteinander kommunzizieren. Der Backendentwickler muss sich somit nicht mehr mit einer zusätzlichen, unnötigen Syntax einer Template Engine auseinander setzen und der Frontend-Entwickler kann seine Problematiken sehr viel einfacher schildern, da beide Entwickler die gleiche Sprache verwenden. Die Kommunikation untereinander wird eindeutiger und schneller.

      1. Genau dieses Argument kann ich in meiner Argumentationskette nicht gelten lassen. Eine PHP Template Engine bleibt immer an PHP gebunden. Dem entsprechend ist es vollkommen egal, ob ich jetzt einfachste PHP Logik in Form von Wenn/Dann Bedingungen in Templates schreibe, oder eine Syntax einer Template Engine nutze. Für den Frontend Entwickler bleibt der Aufwand der gleiche. Er muss die Syntax lernen. Vollkommen unabhängig davon, ob es nun die Syntax einer Template Engine oder eben PHP ist. Wenn der PHP Entwickler sauber arbeitet, muss er ohnehin nicht mehr als die oben genannte Wenn/Dann oder Schleifen Logik verwenden. Der Lernaufwand für die Syntax bleibt der gleiche. Einziger Benefit für den Frontend-Entwickler (Bezeichnung passt in diesem Zusammenhang heutzutage auch nicht mehr wirklich) ist, dass er auch in Projekten arbeiten kann, die auf eine Template Engine verzichten und lediglich einfache PHP Syntax in Templates verwenden.

      2. Diesen Punkt verstehe ich nicht ganz. Inwiefern vereinfacht die Syntax einer anderen Sprache – vollkommen dahingestellt ob PHP oder Engine Syntax – die Migration in eine andere Sprache? Migration im Sinne von PHP auf .NET? IF / ELSE Statements sind simpel und einfach zu verstehen. Unabhängig von der jeweiligen Programmiersprache. Mehr als Schleifen und Wenn/Dann Bedingungen gehören eh nicht in die Templates. Die Wiederverwendbarkeit von Templates ist eher ein generelles Argument. Wenn man sich in einem anderen Projekt die gleiche Template Engine ans Bein gebunden hat, kann man die Templates natürlich auch dort verwenden. Gleiches gilt aber auch für PHP Templates. Problematiken der projektübergreifenden Versionierung und Konfiguration der Template Engine mal außen vor gelassen.

      3. Das ist aber kein PHP Problem, sondern eher ein Problem der Entwickler, oder? Ich glaube ich lehne mich nicht all zu weit aus dem Fenster, wenn ich sage, dass ein Entwickler, der Business Logik in ein Template schreibt, kein guter Entwickler ist. In den Teams, in denen ich tätig war, hat man einen solchen Entwickler zur Seite genommen und geschult, da hier ganz offensichtlich ein paar Basics fehlten. Bei diesem Punkt geht es eher um Qualität als um einen Vorteil einer Template Engine. Zumal ich mit den meisten Template Engines ebenfalls die Möglichkeit habe Business Logik in den Templates auszuführen. Dieses Argument kann mit klar definierten Coding Standards und einer entsprechenden QA komplett wiederlegt werden.

      4. Auch hier widerspreche ich wehement. Bei allen gängigen PHP Frameworks werde ich vor die Wahl gestellt eine Template Engine zu nutzen, oder eben nicht. Das Laminas Framework hat auch eine View Schicht, benutzt hierfür aber PHP und keine zusätzlich eingeführte Syntax. Symfony bietet mir Twig an, zwingt mich aber nicht diese Engine zu nutzen. Laravel möchte mich gern zu Blade drängen, zwingt aber ebenso wenig wie Symfony diese Template Engine zu nutzen. WordPress („Framework“ im allerweitesten, ganz weit entfernten Sinne) baut ebenfalls auf PHP Syntax. Entweder benutze ich diese Komponente und installiere sie mir über einen Package Manager (z.B. Composer) oder lasse sie einfach weg. Die Implementierung entscheide ich als Entwickler genau so, als würde ich mich für die Implementierung einer Template Engine in einem nicht auf Frameworks basierenden Projekt dafür entscheiden. Entscheide ich mich dafür, habe ich auch den entsprechenden Overhead.

      Das Fazit bleibt meiner Meinung nach das gleiche, wie zuvor auch: Als guter Entwickler trenne ich die Business Logik von den Templates. Als guter Entwickler belästige ich den Frontend Entwickler nicht damit, dass er die ausgelieferte Datenstruktur auch noch aufwendig prozessieren muss, bevor sie im Frontend entgültig dargestellt wird. Für all das, brauche ich keine Template Engine. Was ich allerdings wirklich brauche sind Entwickler, die Datenmodelle entwickeln, die den Ansprüchen des Frontends entsprechen, so dass sie schnell und ohne Umwege implementiert werden können.

      Fakt bleibt aber auch, dass sich die Thematik mit der Einführung von JavaScript Frameworks, die gleichzeitig auch eine striktere Trennung von Front- und Backend über entsprechende APIs mit sich gebracht haben, Template Engines so oder so noch überflüssiger gemacht haben, als sie es ohnehin schon sind. Da bin ich vollkommen bei Dir.

      Antworten
  4. Vielleicht liegt das Problem nicht in Template Engines, sondern darin, dass das PHP Ecosystem ein gewachsener Haufen pseudoprofessioneller Schrott ist. Niemand würde ernsthaft erb als Template Engine in Ruby, XSLT bei XML, Jinja2 in Python, WPF bei C# oder Thymleaf in Java/JVM anzweifeln. Nur bei PHP scheint seit Beginn der Sprache bereits alles verloren zu sein, so dass man seine Daten einfach irgendwo reinkippt und froh ist, wenn es funktioniert.

    Eine Template Engine hat einen ganz wichtigen Zweck: Schlechte Devs zu zwingen, weniger schlimmen Quatsch zu machen. Gerade da es in PHP so unfassbar viele miserable Programmierung gibt, ist es um so wichtiger, die Sachen ordentlich abzugrenzen. Das wichtigste dabei vielleicht: Nur die Daten zu übergeben, die auch im Frontend verwurstet werden sollen. Und eine ordentliche Template Engine kann auch nichts anderes, als das Zeug dann anzuzeigen und davor noch zu transformieren. Die einzigen PHP Template Engines die ich grob kenne sind Twig und Mustache, und da kann man eigentlich keine der beschriebenen Grausamkeiten anrichten – aber das sind dann wiederum auch Engines, für die es Implementierungen in diversen anderen Sprachen gibt (vielleicht weil diese eben mal nicht Schrott sind). Da ist nirgends die Möglichkeit, noch seinen PHP-Code reinzuschmuggeln um dann doch etwas anderes zu veranstalten. Vielleicht sieht das bei anderen Engines im PHP Ecosystem aber auch anders aus.

    Genau das ist auch das Konzept, dass bei der Trennung von Frontend und Backend so wichtig ist: Es sind nur die Daten vorhanden, die auch angezeigt werden sollen. Nur da das nun wirklich per API übertragen wird, kann auch kein schlechter Dev mehr auf die Idee kommen, vielleicht doch ein bisschen PHP-Code ins Template zu flanschen.

    Und Performance ist in keinem anderen Ecosystem bei einer Template Engine ein Thema. Aber vielleicht hat PHP wirklich eine derart miese Performance, dass das sogar auch noch zu einem Argument wird.

    Alles in allem klingt der Artikel irgendwie nach einer Selbstrechtfertigung dafür, dass der Autor keine Template Engine benutzt.

    Antworten
    • Hi Michael,

      danke für Deinen ausführlichen Kommentar zu Beginn des Jahres. Du scheinst da in mit mir in etwa auf einer Wellenlänge zu sein, was den Einsatz von Template Engines angeht.

      PHP entwickelt sich glücklicherweise in eine sehr professionelle Richtung. Dennoch bleibt die Verbreitung enorm hoch. Mitunter auch, weil die Einstiegshürde so enorm niedrig ist. Im Grunde genommen kann jeder mit ein wenig Interesse sofort loslegen und Ergebnisse erzielen. Grundsätzlich finde ich das nicht schlecht. Wie Du aber auch schon sagtest, hat dies zur Folge, dass es eine gewaltige Menge an nicht professionellen Entwicklern dort draußen gibt. Nicht alles in PHP ist gut. Wie Du selbst schon sagtest, liegt das auch am historischen Background von PHP.

      Dieser Artikel hier soll keine Selbstrechtfertigung sein, sondern zweifelt den Einsatz von PHP Template Engines als solche grundsätzlich an. Sie sind einfach nicht notwendig. Ich stimme Dir zu, dass PHP Template Engines das Resultat unzureichend ausgebildeter Entwickler sind. Mit dem entsprechenden Know How realisiert man recht schnell, dass PHP Template Engines ein unnötiger Klotz am Bein sind. Es geht schlichtweg um die Trennung von Logik und View Schicht. Seperation of concerns. Ein so elementar wichtiger Grundsatz in der Softwareentwicklung.

      Performance ist mit den aktuellen PHP Versionen 8.1 und 8.2 glücklicherweise kein wirklich ins Gewicht fallendes Thema mehr. Wie im Artikel auch schon geschrieben, ist die Performance aber nicht der einzige Grund, warum man auf Template Engines verzichten sollte. Abhängigkeiten, die gepflegt werden möchten, Code, der während der Laufzeit zusätzlich ausgeführt werden muss, eine unnötige zusätzliche Syntax, etc. pp. Alles Nachteile, die schlichtweg überwiegen.

      Ja, Du hast Recht. Ich selbst benutze Template Engines in meinen eigenen Projekten nicht. Dennoch komme ich immer wieder mit Legacy Projekten in Berührung, bei denen ich mit Template Engines zu tun habe. Selbst Twig erlaubt es den Usern eigene Plugins zu schreiben und ist somit nicht geschützt vor der unendlichen Dummheit mancher Entwickler. Template Engines zwingen einen Entwickler eben nicht wilden Unsinn in einem Template zu veranstalten. Theoretisch mögen sie es vielleicht tun. Wer aber unbedingt möchte, findet einen Weg.

      Sei nicht so streng mit PHP als Programmiersprache. Wir alle sollten mehr auf unsere Skills schauen, aus unseren Fehlern lernen und dadurch besser werden. Ich bleibe dabei. PHP und Template Engines bleiben eine Unsitte.

      Antworten
  5. Danke für die tolle Arbeit die hier geleistet wurde, hier bekommt man sehr gute Informationen, die sehr nützlich sein können.

    Lieben Gruß Mia

    Antworten
  6. Ich verwende Python für dynamische Webseiten und bin es gewohnt, Templates zu nutzen. Nun muss ich für einen Verein ein PHP-Script überarbeiten und sehe die Katastrophe.

    Mein Vater hat das PHP-Script geschrieben oder von jemandem übernommen und dort wird Zeile für ein String (html) zusammengesetzt, um das dann via E-Mail zu versenden. Da ist php-code mit html-markup gemischt.

    Ich weigere mich, HTML-Code in PHP-Dokumenten zu packen und suche deswegen eine sehr einfache Möglichkeit irgendeine Template-Engine zu nutzen.

    Antworten
    • Hey Andre,

      ja ich kann mir gerade vorstellen, dass das eine einzig große Konkatenierung von HTML Strings ist. Du verstehst sicherlich, warum ich auch für dieses Vorhaben eine PHP Template Engine für groben Unfug halte. Letztendlich ist genau das, was Du in dem PHP Script Deines Vaters siehst, die performanteste, wenn auch prozedurale Lösung. Alternativ gibt es aber eine Bibliothek mit dem Namen PHPMailer, die Du für Dein Vorhaben nutzen könntest. Zudem könntest Du das HTML Markup in HTML Dateien auslagern, die Du dann mit der PHP Funktion file_get_contents() als String lädst. Im HTML platzierst Du Platzhalter, die Du mit den Werten Deiner Variablen ersetzen möchtest und nutzt die PHP Funktion str_replace(), um alle Variablen mit den entsprechenden Werten zu ersetzen.

      Kleines Beispiel:

      declare(strict_types=1);

      namespace Marcel;

      $subject = file_get_contents(‚./view/email-template.html‘);
      $search = [ ‚{{name}}‘, ‚{{vorname}}‘ ];
      $replace = [ ‚Maaß‘, ‚Marcel‘ ];
      $content = str_replace($search, $replace, $subject);

      // ab hier dann weiter mit php mailer

      PHP wurde ursprünglich genau so entwickelt, dass HTML und PHP in eine Datei geschrieben werden können. Seitdem hat man sich aber sehr weiter entwickelt und hat zum prozeduralem Stil, den Duda gerade vor Dir siehst, die Objektorientierung eingeführt, die Du von Python kennst. Das mag auf den ersten Blick konfus wirken, hat PHP aber zu immensem Erfolg verholfen.

      Antworten
  7. Template Engines escapen die Ausgage automatisch.
    Ansonsten haben die keinen Sinn und Zweck und sind wohl eher ein Klotz am Bein als sonst was.
    Ist mir ziemlich klar, dass das Schnappatmung verursacht, es wird ziemlich viel unsinniges Zeug programmiert 😉

    Antworten

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.