mirror of
https://github.com/smarty-php/smarty.git
synced 2025-08-05 10:54:27 +02:00
sync with en
This commit is contained in:
messju
@@ -1,11 +1,29 @@
|
||||
<!-- EN-Revision: 1.2 Maintainer: andreas Status: ready -->
|
||||
<!-- $Revision$ -->
|
||||
<!-- EN-Revision: 1.5 Maintainer: andreas Status: ready -->
|
||||
|
||||
<!ENTITY note.parameter.merge '<note>
|
||||
<title>Technische Bemerkung</title>
|
||||
<para>
|
||||
Der <parameter>merge</parameter> Parameter berüksichtigt Array Keys. Das bedeutet, dass numerisch indizierte Arrays sich gegenseitig überschreiben können, oder die Keys nicht sequentiell ausgegeben werden. Dies, im Gegensatz zur PHP Funktion array_merge(), die numerische Keys neu sortiert.
|
||||
Der <parameter>merge</parameter> Parameter berüksichtigt Array
|
||||
Keys. Das bedeutet, dass numerisch indizierte Arrays sich
|
||||
gegenseitig überschreiben können, oder die Keys nicht
|
||||
sequentiell ausgegeben werden. Dies, im Gegensatz zur PHP Funktion
|
||||
<ulink url="&url.php-manual;array_merge">array_merge()</ulink>, die
|
||||
numerische Keys neu sortiert.
|
||||
</para>
|
||||
</note>'>
|
||||
|
||||
<!ENTITY parameter.compileid '<para>
|
||||
Als optionaler dritter Parameter, können sie die <parameter>compile_id</parameter> angeben. Dies ist sinnvoll, wenn Sie verschiedene Versionen der komipilerten Templates für verschiedene Sprachen unterhalten wollen. Weiter ist dieser Parameter nützlich, wenn Sie mehrere $template_dir Verzeichnisse, aber nur ein $compile_dir nutzen. Setzen Sie <parameter>compile_id</parameter> für jedes Template Verzeichnis, da gleichnamige Templates sich sonst überschreiben. Sie können die <link linkend="variable.compile.id">$compile_id</link> auch nur einmal, global setzen.
|
||||
Als optionaler dritter Parameter, können sie die
|
||||
<parameter>$compile_id</parameter> angeben. Dies ist sinnvoll, wenn
|
||||
Sie verschiedene Versionen der komipilerten Templates für
|
||||
verschiedene Sprachen unterhalten wollen. Weiter ist dieser Parameter
|
||||
nützlich, wenn Sie mehrere
|
||||
<link linkend="variable.template.dir">$template_dir</link> Verzeichnisse,
|
||||
aber nur ein <link linkend="variable.compile.dir">$compile_dir</link>
|
||||
nutzen. Setzen Sie <parameter>$compile_id</parameter> für jedes
|
||||
Template Verzeichnis, da gleichnamige Templates sich sonst
|
||||
überschreiben. Sie können die
|
||||
<link linkend="variable.compile.id">$compile_id</link> auch nur einmal,
|
||||
global setzen.
|
||||
</para>'>
|
||||
|
||||
@@ -4,61 +4,76 @@
|
||||
<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.
|
||||
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.
|
||||
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.
|
||||
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?
|
||||
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
|
||||
|
||||
Reference in New Issue
Block a user