[prev in list] [next in list] [prev in thread] [next in thread]
List: smarty-cvs
Subject: [SMARTY-CVS] cvs: smarty /docs/de language-snippets.ent preface.xml
From: "Messju Mohr" <messju () php ! net>
Date: 2005-06-10 9:33:02
Message-ID: cvsmessju1118395982 () cvsserver
[Download RAW message or body]
messju Fri Jun 10 05:33:02 2005 EDT
Modified files:
/smarty/docs/de language-snippets.ent preface.xml
Log:
sync with en
["messju-20050610053302.txt" (text/plain)]
http://cvs.php.net/diff.php/smarty/docs/de/language-snippets.ent?r1=1.2&r2=1.3&ty=u
Index: smarty/docs/de/language-snippets.ent
diff -u smarty/docs/de/language-snippets.ent:1.2 \
smarty/docs/de/language-snippets.ent:1.3
--- smarty/docs/de/language-snippets.ent:1.2 Fri Jul 16 10:32:27 2004
+++ smarty/docs/de/language-snippets.ent Fri Jun 10 05:32:59 2005
@@ -1,11 +1,29 @@
-<!-- EN-Revision: 1.2 Maintainer: andreas Status: ready -->
+<!-- $Revision: 1.3 $ -->
+<!-- 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>'>
http://cvs.php.net/diff.php/smarty/docs/de/preface.xml?r1=1.2&r2=1.3&ty=u
Index: smarty/docs/de/preface.xml
diff -u smarty/docs/de/preface.xml:1.2 smarty/docs/de/preface.xml:1.3
--- smarty/docs/de/preface.xml:1.2 Fri Jul 16 10:32:27 2004
+++ smarty/docs/de/preface.xml Fri Jun 10 05:32:59 2005
@@ -1,64 +1,79 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- EN-Revision: 1.2 Maintainer: andreas Status: ready -->
-<!-- $Revision: 1.2 $ -->
+<!-- $Revision: 1.3 $ -->
<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ßlich Smarty wurde. Wir wussten
--
Smarty CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic