mirror of
				https://github.com/smarty-php/smarty.git
				synced 2025-11-03 22:01:36 +01:00 
			
		
		
		
	
		
			
	
	
		
			74 lines
		
	
	
		
			4.6 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
		
		
			
		
	
	
			74 lines
		
	
	
		
			4.6 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 
								 | 
							
								<!-- 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ä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.
							 | 
						|||
| 
								 | 
							
								  </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 ü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.
							 | 
						|||
| 
								 | 
							
								  </para>
							 | 
						|||
| 
								 | 
							
								  <para>
							 | 
						|||
| 
								 | 
							
								   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.
							 | 
						|||
| 
								 | 
							
								  </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ü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 <productname>SmartTemplate</productname>
							 | 
						|||
| 
								 | 
							
								   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?
							 | 
						|||
| 
								 | 
							
								  </para>
							 | 
						|||
| 
								 | 
							
								  <para>
							 | 
						|||
| 
								 | 
							
								   Dann kam uns die Idee, aus der schlie<69>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...
							 | 
						|||
| 
								 | 
							
								  </para>
							 | 
						|||
| 
								 | 
							
								 </preface>
							 |