Die Frage, wie man die Applikations-Logik eines PHP-Scriptes vom Layout trennt, ist unzweifelhaft eines der am häfigsten diskutierten Themen. Da PHP als "in HTML eingebettete Scripting-Sprache" angepriesen wird, ergibt sich nach einigen Projekten in denen man HTML und PHP gemischt hat schnell die Idee, Funktionalität und Darstellung zu trennen. Dazu kommt, dass in vielen Firmen Applikationsentwickler und Designer nicht die selbe Person sind. In Konsequenz beginnt die Suche nach einer Template-Lösung.
Als Beispiel: In unserer Firma funktioniert die Entwicklung einer Applikation wie folgt: Nachdem die Spezifikationen erstellt sind, entwickelt der Interface Designer einen Prototypen des Interfaces und übergibt dieses dem Programmierer. Der Programmierer implementiert die Geschäftslogik in PHP und verwendet den Interface-Prototypen zur Erstellung eines Template-Skeletts. Danach übergibt der Programmierer die Templates dem HTML/Webseiten-Designer welcher ihnen den letzten Schliff verleiht. Das Projekt kann mehrfach zwischen dem Programmieren und dem Designer ausgetauscht werden. Deshalb ist es wichtig, dass die Trennung von Logik und Design klar stattfindet. Der Programmierer will sich normalerweise nicht mit HTML herumschlagen müssen und möchte auch nicht, dass der Designer seinen PHP-Code verändert. Designer selbst benötigen Konfigurationsdateien, dynamische Blöcke und andere Interface spezifische Eigenheiten, möchten aber auch nicht direkt mit PHP in Berührung kommen.
Die meisten Template-Engines die heutzutage angeboten werden, bieten eine rudimentäre Möglichkeit Variablen in einem Template zu ersetzen und beherschen eine eingeschränkte Funktionalität für dynamische Blöcke. Unsere Anforderungen forderten jedoch ein wenig mehr. Wir wollten erreichen, dass sich Programmierer überhaupt nicht um HTML Layouts kümmern müssen. Dies war aber fast unumgänglich. Wenn ein Designer zum Beispiel alternierende Farben in einer Tabelle einsetzen wollte, musste dies vorhergehend mit dem Programmierer abgesprochen werden. Wir wollten weiter, dass dem Designer Konfigurationsdateien zur Verfügung stünden, aus denen er Variablen für seine Templates extrahieren kann. Die Liste ist endlos.
Wir begannen 1999 mit der Spezifikation der Template Engine. Nachdem dies erledigt war, fingen wir an eine Engine in C zu schreiben, die - so hofften wir - in PHP eingebaut würde. Nach einer hitzigen Debatte darüber was eine Template Engine können sollte und was nicht, und nachdem wir feststellen mussten, dass ein paar komplizierte technische Probleme auf uns zukommen würden, entschlossen wir uns die Template Engine in PHP als Klasse zu realisieren, damit sie von jederman verwendet und angepasst werden kann. So schrieben wir also eine Engine, die wir SmartTemplate™ nannten (anm: diese Klasse wurde nie veröffentlicht). SmartTemplate erlaubte uns praktisch alles zu tun was wir uns vorgenommen hatten: normale Variablen-Ersetzung, Möglichkeiten weitere Templates einzubinden, Integration von Konfigurationsdateien, Einbetten von PHP-Code, limitierte 'if'-Funktionalität und eine sehr robuste Implementation von dynamischen Blöcken die mehrfach verschachtelt werden konnten. All dies wurde mit Regulären Ausdrücken erledigt und der Sourcecode wurde ziemlich unübersichtlich. Für grössere Applikationen war die Klasse auch bemerkenswert langsam, da das Parsing bei jedem Aufruf einer Seite durchlaufen werden musste. Das grösste Problem aber war, dass der Programmierer das Setup, die Templates und dynamische Blöcke in seinem PHP-Skript definieren musste. Die nächste Frage war: wie können wir dies weiter vereinfachen?
Dann kam uns die Idee, aus der schließlich Smarty wurde. Wir wussten wie schnell PHP-Code ohne den Overhead des Template-Parsing ist. Wir wussten ebenfalls wie pedantisch PHP aus Sicht eines durchschnittlichen Designers ist und dass dies mit einer einfacheren Template-Syntax verborgen werden kann. Was wäre also, wenn wir diese beiden Stärken vereinten? Smarty war geboren...