diff --git a/docs/de/language-snippets.ent b/docs/de/language-snippets.ent index 87681d98..64825427 100644 --- a/docs/de/language-snippets.ent +++ b/docs/de/language-snippets.ent @@ -1,11 +1,29 @@ - + + + Technische Bemerkung - Der merge 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 merge 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. '> - Als optionaler dritter Parameter, können sie die compile_id 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 compile_id für jedes Template Verzeichnis, da gleichnamige Templates sich sonst überschreiben. Sie können die $compile_id auch nur einmal, global setzen. + Als optionaler dritter Parameter, können sie die + $compile_id 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 $compile_id für jedes + Template Verzeichnis, da gleichnamige Templates sich sonst + überschreiben. Sie können die + $compile_id auch nur einmal, + global setzen. '> diff --git a/docs/de/preface.xml b/docs/de/preface.xml index fabb9b26..90ae8781 100644 --- a/docs/de/preface.xml +++ b/docs/de/preface.xml @@ -4,61 +4,76 @@ Vorwort - 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. - 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. - 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. - 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? + 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