smarty/docs/de/preface.xml

<!-- Smarty German Documentation Port -->
<!-- $Id$ -->
<!-- $Author$ -->
<!-- $Revision$ -->

 <preface id="preface">
  <title>Vorwort</title>
  <para>
   Die Frage, wie man die Applikations-Logik eines PHP-Scriptes vom Layout trennt, ist unzweifelhaft
   eines der am h&auml;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&auml;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.
  </para>
  <para>
   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 &uuml;bergibt dieses
   dem Programmierer. Der Programmierer implementiert die Gesch&auml;ftslogik
   in PHP und verwendet den Interface-Prototypen zur Erstellung eines Template-Skeletts.
   Danach &uuml;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&uuml;ssen und m&ouml;chte auch
   nicht, dass der Designer seinen PHP-Code ver&auml;ndert. Designer selbst
   ben&ouml;tigen Konfigurationsdateien, dynamische Bl&ouml;cke und andere Interface spezifische
   Eigenheiten, m&ouml;chten aber auch nicht direkt mit PHP in Ber&uuml;hrung kommen.
  </para>
  <para>
   Die meisten Template-Engines die heutzutage angeboten werden, bieten eine
   rudiment&auml;re M&ouml;glichkeit Variablen in einem Template zu ersetzen
   und beherschen eine eingeschr&auml;nkte Funktionalit&auml;t f&uuml;r dynamische
   Bl&ouml;cke. Unsere Anforderungen forderten jedoch ein wenig mehr. Wir wollten
   erreichen, dass sich Programmierer &uuml;berhaupt nicht um HTML Layouts
   k&uuml;mmern m&uuml;ssen. Dies war aber fast unumg&auml;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&uuml;gung st&uuml;nden,
   aus denen er Variablen f&uuml;r seine Templates extrahieren kann. Die Liste ist endlos.
  </para>
  <para>
   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&uuml;rde. Nach einer hitzigen Debatte dar&uuml;ber
   was eine Template Engine k&ouml;nnen sollte und was nicht, und nachdem wir feststellen
   mussten, dass ein paar komplizierte technische Probleme auf uns zukommen
   w&uuml;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 <productname>SmartTemplate</productname>
   nannten (anm: diese Klasse wurde nie ver&ouml;ffentlicht). SmartTemplate
   erlaubte uns praktisch alles zu tun was wir uns vorgenommen hatten: normale
   Variablen-Ersetzung, M&ouml;glichkeiten weitere Templates einzubinden,
   Integration von Konfigurationsdateien, Einbetten von PHP-Code, limitierte 'if'-Funktionalit&auml;t
   und eine sehr robuste Implementation von dynamischen Bl&ouml;cken die
   mehrfach verschachtelt werden konnten. All dies wurde mit Regul&auml;ren Ausdr&uuml;cken
   erledigt und der Sourcecode wurde ziemlich un&uuml;bersichtlich. F&uuml;r gr&ouml;ssere
   Applikationen war die Klasse auch bemerkenswert langsam, da das Parsing bei jedem
   Aufruf einer Seite durchlaufen werden musste. Das gr&ouml;sste Problem aber war,
   dass der Programmierer das Setup, die Templates und dynamische Bl&ouml;cke in seinem
   PHP-Skript definieren musste. Die n&auml;chste Frage war: wie k&ouml;nnen wir dies
   weiter vereinfachen?
  </para>
  <para>
   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&auml;re also, wenn wir diese
   beiden St&auml;rken vereinten? Smarty war geboren...
  </para>
 </preface>