PHP Blogger

Startseite Schreib mir ne Mail! RSS Abo Webnews

PHP ist eine Template Engine!

Den meisten meiner Leser ist bekannt, das ich kein Freund von Template-Engines bin. Diese unnützen Klassen und Bibliotheken “versuchen” Optik von Logik und Business-Code zu trennen - was dabei herauskommt, nennt sich unter Umständen Smarty und ist ein Witz.

Bei meinem Lieblings-Template-Veteranen Smarty wird PHP Code durch Pseudo-Code ersetzt - irgendwelche Schleifen- und Bedingungskonstrukte, verstümmelte Variablennamen und Nicht-HTML Tags fliegen kreuz und quer durch die HTML Landschaft. Im schlimmsten aller Fälle verteilt über verschiedene Template-Dateien.

Das nächste Level der Verrücktheit sind CM-Systeme, die alles unnötig komplizieren (obwohl alles einfacher werden sollte), noch mehr Pseudo-Tags und -Code einführen und ein Desaster an Performance anrichten. Das beste Beispiel ist Typo3, aber auch große kommerzielle CMS Hersteller wie Day, Red Dot, Vignette, Fiona (von Infopark) und Imperia (Reihenfolge ohne Wertung) begehen ähnliche Fehler. Die Performanceschwäche wird übrigens meist mit dem genialen Statischen-Cache-Feature wieder gut gemacht.

Gibt’s denn kein Projekt, das das besser macht?

Bei nicht PHP-basierten CM-Systemen kann man über Pseudo-Tags hinwegsehen, schließlich muss ja der gehamsterte Content irgendwie mit HTML verpackt werden. Aber was überhaupt nicht geht, ist Pseudo-Code mit dem ganze If- und For-Konstrukte in HTML eingebettet werden.

Dazu kommt meist eine fürchterlich überladene Oberfläche mit Funktionen, die keiner benötigt, und was man benötigt, muss man bei kommerziellen Anbietern richtig teuer nachkaufen. Da gehts dann meist schon nicht mehr um 4-5 stellige Beträge, sondern um knackige 6 stellige Gelder, die hier für Webschrott ausgegeben werden. Jeder will ja beim Web 2.0 eine gute Figur machen ;)

Dort wo Smarty wenigstens bei einer Technologie bleibt, kombinieren die meisten kommerziellen WCMS Anbieter mehrere Technologien wie Perl, Java, C++ und irgendwelche Shelltools. Was rauskommt ist eine bunte Trallala-Applikation, dekoriert mit schicken Servelets, feinen Docklets, schnuckeligen Applets und super Frames (Huhu, ein kleiner Wink ans SAP Portal ;-). Liest sich schrecklich, klingt furchtbar und man sollte es niemals wieder anfassen, wenns mal läuft.

Okay, ich bin ein bisschen vom Thema abgedriftet, um meinem Unmut Luft zu machen. Was war doch gleich das Thema? Achja, Template-Engines. Also zu der bereits ausfürlich ;) erwähnten nicht vorhandenen Trennung zwischen Content und Logik, fantastischen Pseudocodes und -tags, irgendwelchen dubiosen Scriptsprachen wie TypoScript kommt dann noch die massenweise Verschwendung an kostbarem Arbeitsspeicher:

Denn woran die meisten nicht denken, Template Engines duplizieren nahezu den benutzten Speicher. Na gut, nicht direkt die Template-Engines - aber welcher Entwickler gibt in PHP die Variablen wieder frei, nachdem sie an die Template Engine übergeben wurden?

Im Idealfall platziert das Template-Framework die Inhalte da, wo sie hin sollen und spuckt den generierten HTML Klumpen in ein Cache-Verzeichnis um dem Server beim nächsten Abruf etwas Rechenleistung zu ersparen.

Aber warum der ganze Aufwand? PHP ist doch bereits eine Template Engine? Warum einen Parser bauen, wenn’s PHP schneller kann? Warum Keywords für Variablen einführen, wenn PHP die direkte Einbettung mit <?= $variable ?> bereits unterstützt?

Die Berechnung und Organisation von Werten muss natürlich ausgelagert werden - keine Frage. Aber auch dafür gibts schöne PHP Funktionen; Du wärst bestimmt nicht der Erste, der PHP Code in HTML einbettet.

Ach und übrigens: Auf Sub-Snippets kann man meiner Meinung nach auch verzichten. Was ich meine? Diese lieben kleinen HTML-Abrisse, die gerne in Schleifen wiederholt werden (Vielleicht für einen Breadcrumb oder eine Downloadliste). Die verrückteste Idee ist, diese Dinge in eigene Dateien zu packen und bei jedem Schleifendurchlauf von der Platte zu laden. Du weiß schon, das der langsamste PC Baustein die Festplatte ist?

Zum Schluß noch eine kleine Empfehlung, schließlich soll das Lesen des Artikels nicht umsonst gewesen sein. Ed Eliot hat vor einiger Zeit ein kleines Projekt veröffentlicht, das die Vorteile von PHP nutzt. Deshlab gibts von Ihm eine Mini-Template-Engine, mit deren Hilfe man prima HTML von Logik trennen kann ohne eine Prozessor-Orgie zu veranstalten.

Hat das Ding einen Namen? Nein, ich glaube er nennt es nur Template-Engine. Ok. Übrigens: Wer’s nicht lassen kann, mit seiner Template-Engine ist es auch möglich, Templates zu verschachteln…

Ähnliche Artikel:

  1. Vergiss Template-Engines!
  2. Bröckchen für Bröckchen
  3. Die Templates, die ich rief
  4. Nach Tigerente jetzt Tigermaus
  5. Pseudo-Tags mit Textile

Frank meint dazu:

17. August 2007 um 14:32

Ich denke, eine Sache ist nicht korrekt:

Die Auslagerung von gemeinsamem Code als Snippets ist sinnvoll. Oder wer möchte die Navigation in 100 Templates redundant haben und alle bei einer Änderung anfassen? Es gibt immer einige Elemente, die man auslagern möchte. Dazu gehören sicher nicht Einzeiler-Snippets wie ein Element einer Downloadliste oder Breadcrumb. Sehr wohl aber die Downloadliste oder der Breadcrumb an sich.

Und eine Festplatte mag zwar langsam sein, aber die Datei befindet sich nach dem ersten Lesen im Cache des Betriebssystems und wird dann direkt aus dem Speicher geladen. Es ist außerdem kein Argument, dass ein paar Dateien mehr oder weniger nun das Skript an sich langsamer machen, da die Performance-Einflüsse sehr komplex sind und das Laden von kleinen Dateien ist mit Sicherheit das kleinste Problem hierbei.

timi meint dazu:

17. August 2007 um 14:48

Hi Frank, vor lauter Schreib-Euphorie sind in den Artikel ein paar stark polarisierte Aussagen reingerutscht ;)

Du hast natürlich Recht, was gemeinsamen Code und Filesystem-Cache angeht - 3 oder 4 Includes sind natürlich nicht der Brüller, was die Performanceverschlechterung angeht. Aber je nach Bibliothek/Framework/CMS sind es schnell an die 100 (wenn nicht sogar mehr) Includes die alle geparst werden möchten, das macht sich dann schon in der Laufzeit bemerkbar.

Noch ein Wort zu Breadcrumbs und Co.: Im Zeitalter von XHTML und CSS reduziert sich die Komplexität der verwendeten Elemente beträchtlich, eine Auslagerung in Snippets ist deshalb nicht mehr unbedingt notwendig, ein Beispiel gibts z.B. hier: http://de.selfhtml.org/css/layouts/navigationsleisten.htm

Frank meint dazu:

17. August 2007 um 18:51

Das Argument der vielen oder nicht so vielen Dateien ist nach wie vor irrelevant, da das Laden der Dateien von der Festplatte nur einen Bruchteil der Laufzeit einnimmt. Das Parsen der Skript-Dateien nimmt die allermeiste Zeit in Anspruch, wie du ja auch selber sagst.

Es muss lediglich dafür gesorgt werden, dass nur der Code inkludiert wird, der auch wirklich benötigt wird pro Aufruf und dies wiederum erreicht man am besten, wenn man den Code so sauber wie möglich in Dateien trennt. Umfasst ein Framework oder Projekt 100 Dateien, heißt das ja nicht automatisch, dass diese alle geladen werden jedesmal. ;-)

Deinen letzten Absatz verstehe ich allerdings nicht. Es hat doch nichts damit zu tun, ob ich nun weniger Code brauche für z.B. eine Navigation. Was machst du denn, wenn du einen neuen Menüpunkt hinzufügen willst? Ich glaube, dann wärst du froh, wenn du ein Snippet hast. 8-)
Und wenn die Navigation generiert wird, dann möchte ich doch den Iterationscode nur an einer Stelle haben. Oder habe ich etwas falsch verstanden?

Stefan meint dazu:

20. August 2007 um 15:03

Diesen ganzen Template-Wahn kann ich ebenfalls nicht verstehen. Ich glaube, das rührt daher, dass viele meinen, HTML sei Design und gehöre deshalb in ein Template ausgelagert. Doch fürs Design ist CSS zuständig; HTML ist Auszeichnung und als solche eher Teil der Businesslogik.
Wenn in einem Navigationsmenü ein zusätzlicher Punkt auftauchen soll, dann ist das keine Frage des Designs! Also sollten auch die Design-Dateien nicht angefasst werden müssen. Vielmehr gehört in so einem Fall eine Funktion angefasst, die das Menü erstellt.

Sebastian meint dazu:

21. August 2007 um 03:04

——–
Denn woran die meisten nicht denken, Template Engines duplizieren nahezu den benutzten Speicher. Na gut, nicht direkt die Template-Engines - aber welcher Entwickler gibt in PHP die Variablen wieder frei, nachdem sie an die Template Engine übergeben wurden?
——–

es macht in php in derselben instanz keinen unterschied auf den speicher ob du eine variable freigibst oder nicht. aus dem speicher wird sie erst vom garbage collecter entfernt - und der kommt erst ganz zum schluß.

ansonsten kann ich dir eigentlich nur zustimmen, nur solltest du hierbei immer die sicherheit im auge haben. php ist vielleicht eine template engine (dafür wurden die Personal Homepage Tools ja zuallerst entwickelt), aber auch eine mächtige sprache. mit einem CMS gehen nicht nur gestandene programmierer ins feld, sondern auch DAUs. und wie schnell machen die, wenn sie denn templates editieren können, hierraus:

——
>?=$title=<
——

das hier?

—–
>?=$password=<
—–

eben. du weißt es nicht. nun stellt sich die frage wie du sowas kontrollieren könnstest? auch eine klasse könnte ich mit $GLOBALS umgehen …….

gruß

timi meint dazu:

21. August 2007 um 14:05

@Frank, so einfach kann man das Festplattencaching nun nicht von der Performancefrage entbinden - schließlich kommts zunächst mal auf die Hardware und deren Konfiguration an, und das Betriebsystem hat dann ohnehin das letzte Wort. Probleme hatte ich hier z.B. auf einer Sun unter Solaris - es kommt also auf drauf an.

Und zu meinem letzten Absatz: Wer zwei li-Tags in einer Datei kapselt, ist selbst schuld. Der Navi-Generator ist natürlich wie die übrige Logik in externen Dateien gekapselt.

@Stefan: HTML beinhaltet keine Logik, daher kann es auf keinen Fall der Businesslogik zugeordnet werden - ich sehe HTML als eigenständigen Part, es gehört klassischerweise zur View einer Applikation…

@Sebastian: Ich kann Dir in keinem der Punkte zustimmen. Es ist richtig, der Garbage Collector räumt den Physikalischen Speicher zum Schluss auf - wenn man eine Variable mit unset entläd, wird sie jedoch aus der Interpreter-Verwaltung für Speicher entfernt, und bei einem komplexen Array können Zeigerinfos durchaus den Speicher entschlacken. Auf jeden Fall kommt es zu spürbaren Performance-Unterschieden.

Und: Wer die Variable $password global bereitstellt, darf sich nicht wundern, wenn Nutzer sie verwenden. Die wenigsten Variablen sollten global bereitgestellt werden. Besser ist es, sie über Objekte mit Get-Funktionen anzubieten. Dort können auch Berechtigungsfragen geklärt werden.

Sebastian meint dazu:

21. August 2007 um 19:41

—–
Und: Wer die Variable $password global bereitstellt, darf sich nicht wundern, wenn Nutzer sie verwenden. Die wenigsten Variablen sollten global bereitgestellt werden. Besser ist es, sie über Objekte mit Get-Funktionen anzubieten. Dort können auch Berechtigungsfragen geklärt werden.
—–

sollte, hätte, täte, würde.
ich sagte es kann passieren. auch $_SERVER ist interessant. als user könnte mans verhindern, wenn mans weiß.
ich will also damit sagen, dass dus dir nicht so einfach machen solltest, sondern wirklich wissen solltest was passieren kann.

PHP Blogger: Abstraktes HTML mit HAML - Ein PHP Blog auf deutsch meint dazu:

25. Oktober 2007 um 17:26

[...] bin ich von diesem Logik-Gerammel in Templates nicht sonderlich begeistert. Immerhin bietet Haml eine Alternative zum PHP-Tag Geraffel in [...]

PHP Blogger: Vergiss Template-Engines! - Ein PHP Blog auf deutsch meint dazu:

6. November 2007 um 12:21

[...] zu Template-Engines unter PHP kennt jeder gute Leser des PHP Bloggers. Artikel wie “PHP ist eine Template Engine!“, “Die Templates, die ich rief” und “Bröckchen für [...]

Eraser meint dazu:

21. Februar 2008 um 17:12

Hey,
ein seh interesanter Artikel. Ich hab mich gerade mit dem Thema befast da Template Engins viel zu aufgeblasen sind und am ende doch nicht die benötigten Funktionen hat und man dan wieder auf ein {PHP}-Block zurückgreifen muss.
Ich hab auch schon mit dem gedanken gespielt, alles ohne Templatengines zu machen und nur eine Strikte Trennung ermöglichen.
Und durch zufall bin ich hier gelanded und hab ein problem weniger - Ich mach mein Projekt ohne Templateengine… (auch wenn ein par dinge evtl. ein wenig übertrieben sind ;)

Gruß,
E

Webagentur meint dazu:

19. August 2008 um 12:11

Gibt es irgendwo eine genaue Anleitung (möglichst in deutsch), wo man sieht wie man einen eigenen Template Parser mit Platzhalter etc. bauen kann?

Robert Heine meint dazu:

2. Oktober 2008 um 15:03

Ich sehe das absolut genauso, wie der Author. Typo3 bietet so viele neue Konstrukte, dass es eigentlich schon eine eigene Programmiersprache ist (nennt sich ja sogar so: TypoScript”). Wo aus einer TemplateEngine eine neue Programmiersprache wird, kann man genausogut ein PHP-Framework schreiben / benutzen, um seine Templatedateien zu “parsen” (siehe Joomla 1.5). Der Vorteil: Man muss nicht wirklich neue Syntax lernen, wie bei TypoScript, und hat im Template alle Vorteile von PHP.

Wieso sollte ich als Entwickler jemandem Zugriff auf die Templates gewähren, wenn ich ihm nicht vertraue? Von daher stellt sich für mich die Frage nach der Sicherheit dann auch garnicht, weil keiner in meinem Template “print $passwort” verwenden kann, dem ich das nicht erlaube.

Auch wenn der Artikel schon etwas älter ist, verlink ich ihn trotzdem mal in meinem Blog, denn irgendwie ist er immernoch aktuell 8-)

Typo3 Freelancer meint dazu:

11. September 2009 um 11:24

Ich finde, wenn man eine Website mit sehr vielen Usern gleichzeitig online hat, dass man auf eine TemplateEngine verzichten sollte, da sie viel zu Speichhungrig sind. Die Kurzschreibweise von PHP-Tags bringen ja bereits alles mit.

Bockerl meint dazu:

31. Dezember 2009 um 13:03

Ich finde die vorgestellte Template-Variante wirklich sehr gut. Ich werde sie mir mal etwas näher anschauen.

SEO meint dazu:

23. Juli 2010 um 14:45

Ich werde mir auch mal die Möglichkeit anschauen. Da ich aber auch viel mit xt:Commerce mache, muss ich mich leider trotzdem mit Smarty rumschlagen.

Webagentur meint dazu:

20. August 2010 um 13:01

Ich arbeite auch sehr viel mit Smarty, da ich auf Basis von xtcModified Kunden-Shops öfters erstelle und diese Template-Engine fester Bestandsteil dort ist. Aber auch für was neues bin ich immer offen.

Social Media Agentur meint dazu:

17. Februar 2011 um 12:39

Da wir hier sehr viel mit TYPO3 machen, nutzen wir natürlich auch das Templating in TYPO3. Aber auch Smarty setzen wir oft ein, aber es ist natürlich tatsächlich sehr Speicherhungrig. Aber was ist schon perfekt?

HTML mit PHP Code aus Datenbank auslesen + ausf meint dazu:

29. April 2011 um 19:16

[...] einfach Smarty). [...] Bin der gleichen Meinung wie Inta. Hab da noch einen Link ausgegraben… PHP Blogger: PHP ist eine Template Engine! - Ein PHP Blog auf deutsch __________________ Gru

Problem bei Ausgabe mit echo - XHTMLforum meint dazu:

30. Juni 2011 um 19:28

[...] Wahl. Der Autor hat hier zwar etwas

Marc Weber meint dazu:

1. Januar 2012 um 22:55

Na ja, es gibt auch Schlanke Tools, die wenig machen, aber genu das was wichtig ist: HTML überprüfen, Variablen auf Wunsch einfach escapen, bei bedarf aber dennoch PHP Hacks zulassen wenn es sein muss - und zusätzlich lesbaren Stil erzwingen, so wie haml-lang.com. Eine sehr vollständige Implementation für PHP kann man online bei haml-to-php.com ausprobieren. Weil native PHP Code erstellt wird ist das Ergebnis auch fast so schnell wie PHP. Dies ist dann ehere eine DSL (Domain specific Language) um HTML zu schreiben. Wer will kann ja vollständiges Caching wie bei Smarty in wenigen Zeilen zusätzlich selber implementieren.

Sgt.Nops meint dazu:

13. Dezember 2012 um 12:54

Das besonders abartige ist das es bei Smarty dann wiederum Plugins gibt die das ausführen von PHP im Template ermöglichen. Erst wird Aufwand getrieben um alles zu trennen, dann macht man Plugins um die Trennung wieder aufzuheben.

RSS für Kommentare zu diesem Artikel · TrackBack URI

Schreib Deine Meinung