Der Unsinn der Templateengine Smarty

Welche Vorteile hat die Templateengine Smarty ?

Diese Frage sollte man sich stellen.

Zitieren wir doch einmal aus dem Original Manual von Smarty:

Smarty ist eine Template-Engine für PHP. Genauer gesagt erlaubt es die einfache Trennung

von Applikations-Logik und Design/Ausgabe. Dies ist vor allem wünschenswert, wenn der

Applikationsentwickler nicht die selbe Person ist wie der Designer. Nehmen wir zum Beispiel eine

Webseite die Zeitungsartikel ausgibt. Der Titel, die Einführung, der Author und der Inhalt selbst enthalten

keine Informationen darüber wie sie dargestellt werden sollen. Also werden sie von der Applikation

an Smarty übergeben, damit der Designer in den Templates mit einer Kombination von HTML- und

Template-Tags die Ausgabe (Tabellen, Hintergrundfarben, Schriftgrössen, Stylesheets, etc.) gestalten

kann. Falls nun die Applikation eines Tages angepasst werden muss, ist dies für den Designer nicht

von Belang, da die Inhalte immer noch genau gleich übergeben werden. Genauso kann der Designer

die Ausgabe der Daten beliebig verändern, ohne dass eine Änderung der Applikation vorgenommen

werden muss. Somit können der Programmierer die Applikations-Logik und der Designer die Ausgabe frei anpassen, ohne sich dabei in die Quere zu kommen.

Das hört sich alles gut an.

Im Klartext – die Applikation weist der Templateengine Smarty Variable zu die man dann über Templates einsetzen und somit verwenden kann ohne das man sich als Designer Gedanken machen muss wo oder wie diese Inhalte her kommen.

Was aber macht Smarty ?

Smarty verwendet einen eigenen Syntax, der in Templates zu verwenden ist.

Diese Templates werden von Smarty compiliert und nach PHP umgesetzt.

Diese erzeugten PHP Scripte sind es die letzten Endes die eigentliche Funktion des Templates übernehmen.

So erzeugt als Beispiel der Einsatz mit dem Befehl die Smarty – Variable {$content} auszugeben ein ziemlich umfangreiches PHP Script:

         compiled from "0cad7c7dfeb0a5ae0790853e5d70ef5fee98a86a" */ ?>

$_valid = $_smarty_tpl->decodeProperties(array (
  'file_dependency' => 
  array (
    '0cad7c7dfeb0a5ae0790853e5d70ef5fee98a86a' => 
    array (
      0 => '0cad7c7dfeb0a5ae0790853e5d70ef5fee98a86a',
      1 => 0,
      2 => 'string',
    ),
  ),
  'nocache_hash' => '10485702885129227e450bf2-26028959',
  'function' => 
  array (
  ),
  'has_nocache_code' => false,
  'version' => 'Smarty-3.1.13',
  'unifunc' => 'content_5129227e460231_94686189',
),false); /*/%%SmartyHeaderCode%%*/?>

Hier der Content

Das ist natürlich viel Holz für etwas was man einfach mit PHP echo $content ; ausgeben könnte.

Aber natürlich muss Smarty rein aus technischen Gründen mehr leisten, denn

das Template könnte nicht vorhanden sein,

es könnte veraltet sein, d.h. die Vorlage entspricht nicht den Zeitmarkern der compilierten Version,
es könnten weitere Templates oder Plugins darin enthalten sein die widerum etwas enthalten.

Und natürlich besondere Dinge wie cache oder nocache Features müssen auch abgearbeitet werden.

Das alles kann nur bedeuten – Smarty ist im Vergleich zu PHP direkt sehr viel langsamer.

Bei einem reinen PHP Template könnte man Subtemplates einfach per include einbinden – Plugins könnte man einfach einsetzen und wenn diese Plugins ihrerseits Subtemplates aufrufen included man die innerhalb des Plugins und führt die Ausgabe durch.

Auf diese Art könnte man einen Zeitfresser erster Güte aus dem Weg schaffen der von Smarty an allen Ecken einzusetzen ist – die PHP Funktion eval.

Nun wird ja bei Smarty (und allen anderen Templateengines) die Trennung von Code und Design hervorgehoben.

Praktisch macht es dazu keinen Unterschied aus ob man in einem Template eine PHP Variable direkt oder indirekt via Smarty verwendet.

Bei der indirekten Verwendung via Smarty muss man allerdings den Syntax von Smarty lernen und beherrschen.

Völlig überflüssig für Designer , da PHP zur Grundausbildung eines Designers gehört.

Manchmal wird von den Verfechtern von Smarty die sogenannte Sicherheit angeführt, die sich daraus ergeben soll, das direkte PHP Tags komplett unterdrückt werden können und somit nicht ausgeführt werden.

Nun ist es aber auf der anderen Seite auch so, das allein das Nichtsetzen eines Endtags von Smarty ( } ) man eine weisse Seite enthält und u.U. Lange suchen muss um einen solchen Fehler zu finden.

Und man muss sich regelrecht verbiegen um Kleinigkeiten bei Stringmanipulationen zu erreichen.
Dafür gibt es zahlreiche Plugins und deren Variante Modifikatoren zudem kann man selbst welche schreiben die man mit PHP direkt mit ein paar Anschlägen hätte erledigen können.

Zudem ist es absolut kein Problem sich ein Smarty-Plugin zu schreiben um komplexe Funktionen ausführen zu können die auch für das Gesamtsystem gefährlich werden könnten.

Webdesigner müssen für komplexe Web's solche Plugins schreiben können.

Es liegen z.B. in der Regel Daten in einer Datenbank vor die es manchmal darzustellen gilt.

Die Datenstruktur und Zusammenhänge sind dokumentiert.

Die Beschaffung via PHP ist häufig genug ein Einzeiler.

Unter Smarty ist es eine Sache eines komplexen Smarty – Plugins das man schreiben müsste.

Das Smarty – Manual beschreibt das System als sehr schnell.

Schnelligkeit ist immer relativ.

Setzt man eine Applikation einem Apache Benchmark aus und vergleicht die Ergebnisse mit einem reinen PHP Werk gleicher Funktionalität dann wird es einem klar – unter Last kann eine reines PHP-Werk mehrere hundert mal mehr Leistung abliefern als ein Werk mit Smarty.

Heftige Arbeit haben z.B. Shopsysteme auszuhalten – da gibt es einige beliebte Titel die mit Smarty arbeiten.

Die Lastleistung dieser Systeme ist unter all dem was man akzeptieren könnte – da wird noch nicht einmal Tante Emma Niveau erreicht – ein Wachstum mit Smarty ist bei denen kaum möglich.

Warum aber kommen Betreiber nicht darauf das man sich eine künstliche Wachstumsgrenze eingebaut hat ?

Natürlich gibt es Webangebote die nur für einen kleinen Kreis interessant sind. Die Betreiber rufen ihre Seiten auf und meinen – das ist ja schnell.

Nun liegt da keine großartige Last vor – Effekte durch Pagespeedmaßnahmen werden nicht gesehen - die Seite wirkt schnell.

Auf der anderen Seite wird dann gemeckert – zu wenig Besucher, zu wenig Umsatz.

Führt man dann einen Apache Benchmark mit einer ordentlichen Last aus stellt man fest – das System kann sehr schnell nicht mehr mit halten.

Natürlich spielen dabei auch andere Faktoren eine Rolle.

Um diese auszuschalten vergleicht man am besten mit Benchmarks die auf einem lokalen Server ausgeführt werden.

Nachfolgend eine Auswertung verschiedener CMS bei denen einige mit Smarty arbeiten.

Die Ergebnisse sind verblüffend und zeigen deutliche Unterschiede:

Bei Shopsystemen die mit Smarty arbeiten sind die Verhältnisse noch krasser da dort typisch eine Vielzahl von Plugins und Subtemplates eingesetzt werden.

Unter Last liegen die Leistungen bei häufig nur 3..4 Request's pro Sekunde – das ist definitiv zu wenig um Wachstum und wirtschaftlichen Erfolg zu haben.

Sicher kann man die Leistung verbessern wenn man die Struktur optimiert aber diese Möglichkeiten sind stark begrenzt.

In der Grafik ist PowerCMS zu sehen – das arbeitet mit Smarty und über Jahre hoch optimierten Strukturen und ist tatsächlich extrem leistungsfähig.
Das System Porg arbeitet dagegen rein mit PHP und liegt fast auf der Null-Linie.

Das grundsätzliche Problem bei Templateengines besteht darin das man heute weit von dem Idealkonzept arbeitet bei denen solche Engines sehr gute Leistungen bringen werden.

Das wäre

• alle Variablen zuweisen
• Template ausführen

Heute arbeiten Designs mehr oder weniger rekursiv – ein Haupttemplate enthält eine Zahl Subtemplates die wiederum weitere Subtemplates enthalten.

Das bedeutet einen ziemlichen Aufwand für die Engine alles im Griff zu haben.

Zudem ist der Verbrauch an RAM hoch und RAM Verbrauch hat einen direkten Einfluss auf die Leistung.

Man messe mal mit Apache Benchmark die Leistung des gleichen Systems bei dem beim zweiten Test künstlich der RAM Bedarf um 2 MB hoch getrieben wird – da weiß man genau welche Konsequenzen das haben wird.

Man darf sich einmal vor Augen führen was PHP bedeutet = Hypertext Prepocessor.

Das aber bedeutet u.a. PHP selbst ist eigentlich auch eine Templateengine.

Und damit stellt sich die Frage ob es überhaupt sinnvoll ist eine auf PHP basierende Zwischenschicht mit eigenem Syntax, Parser und Compiler zwischen PHP und der Ausgabe zu setzen um genau das auszugeben was PHP direkt machen kann.
Schließlich sind die unter Smarty wirksamen Scripte auch nur PHP.

Ich meine – das ist heute kompletter Unsinn.