smarty/docs/de/preface.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision$ -->
<!-- EN-Revision: 1.3 Maintainer: andreas Status: ready -->
 <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>