Salle,

Ich bin mir momentan am abschätzen, ob ich von "alles in einem
skript" (design + funktion) auf ein Templatesystem umsteigen soll.

Mein Problem ist folgendes, man schreib frisch und fröhlich Skripte,
die auch noch so schön strukturiert sein können. Es ist einfach nicht
praktikabel html im skript selber zu bearbeiten. Speziell dann nicht,
wenn man eine Änderung des Designs durchführen möchte.

Da ich nun sowiso all meine Skripte überarbeite und zum teil neu
schreibe (veränderte Anforderungen, gravierende verbesserung der
Funktionalität etc.), ist es ein guter Zeitpunkt um umzusteigen.

Nun meine Frage:

Was für Template-engine benützt ihr? Was für Erfahrungen habt ihr mit
diesen Templateengines gemacht?

Ich teste momentan smarty. Scheint ein ganz vernünftiges Projekt zu
sein.

gruss Pozor

Interessant ist hier, dass die Community sich nicht wirklich
einig ist über die grundlegende Handhabung von Ausgaben:

Ich erlaube mir hier eine kurze Zusammenfassung über die
bekannten Probleme und aus meiner Sicht..

Die Theorie besagt, dass man ein Programm grundlegend in
mehrere Teile aufteilen soll. Die grobste Aufteilung trennt
zwischen Core/Kern, welcher reine Funktionale Definition
aller späteren möglichkeiten bietet und keinerlei bsp. HTML
produziert. Diese Funktionen sind Darstellungsunabhängig.
Hinzu kommt die Ausgabe, welche quasi das spezifische
Darstellungsinterface (hier also HMTL) bedient. Dieser
Teil jedoch ist nicht 'Ein Teil', sondern trennt sich
wiederum grundlegend in zwei Parts:
- Strukturelle Auswertung der (bsp. POST oder GET)
Daten vom Client und Aufrufen der Kernfunktionalität
- Situative reine Ausgabe ohne Aktionssteuerung
jedoch unter berücksichtung der internen Zustände
Der Kern ist natürlich wiederum in seine Modularen Teile
zu zerlegen.

Ein Templatesystem steht nun vor einem Problem, das wir
alle haben:
'Design' ist nicht wie die Theorie das so sehr wünscht
losgelöst von der Kernfunktionalität, sondern bettet für
jede Funktionalität irgendwo auch eine Bedienung ein.
Eine Anpassung der Core führt also zwingend zu Anpassung
an der Oberfläche. Im besten Falle ist bsp. eine neu
eingeführte Option an der Oberfläche einfach nicht
vorhanden! Evtl aber geht garnichtsmehr und man muss alle
Oberflächen um dieses Element erweitern damit es wieder
geht. (Bsp. Einführen eines neuen Pflichtparameters im
Datenmodell)

Zum Charakter der beiden Teile welche Templates grundlegend
tangieren:
Die Strukturelle Auswertung ist grundlegend eine Aufgabe,
welche in PHP optimalerweise implementiert wäre! Es gilt
Informationen vom Frontend zu sammeln, und interne Zustände
zu generieren. Dieser Teil jedoch ist in hohem Masse
Darstellungsgebunden.. Es macht hier jedoch keinen Sinn, dass
man diese Logik in einer nochmals anderen Sprache formuliert.

Was also bleibt als Kernaufgabe eines Templatesystemes ist
die Auswertung der Zustände und aufgrund dessen, das
Zusammenstellen der Ansicht.

Wenn man nun aber alle anderen Teile so sauber abstrahiert
hat, wird man feststellen, dass diese losgelöste Ausgabe
auch direkt als 'Templatefiles' mit PHP-Bedingungen
sinnvoll sind. PHP ist nämlich in diesem Falle eine sehr
geeignete Templatesprache.. Eine wichtige Frage ist hier
höchstens noch die (Visuelle) Editorunterstützung..

Ganz im Ernst: das was jetzt noch übrig bleibt und auch
wirklich in diesen Ausgabedateien/Templates drinnstehen
sollte, ist dermassen einfacher PHP-Code, der durch keine
Templatelösung vereinfacht werden kann. Im Gegnteil, muss
man das Konzept nochmals durch einen Zwischenlayer und ein
langsames Templatesystem ergänzen und und und...

Was nun? .. Ich bleib' mal bei reinem PHP und übergeb
euch die Diskussion ;-)

En Gruess: Miro

Kleiner spontaner Nachtrag aus meiner Sicht:

Wenn sich n'paar Personen finden, welche sich mit dem Thema
'Templates' und ihren Einsatz tiefgehend auseinandersetzen
wollen, würde ich gerne mit diesen Personen das Thema grundlegend
angehen..

Irgendjemand aus meiner Gegend (Zürich) der die Fähigkeiten
dazu hat, und bereit ist etwas Zeit dafür zu investieren?

Ich würde mich freuen, denn ich bin genauso an einer sauberen
Lösung interessiert!

Danke & GrEeZ: Miro Dietiker

Hallo Miro,

Ich sehen den grossen Vorteil in der Trennbarkeit für Designer
und Programmierer. So ist es nicht immer sinnvoll PHP in Templates
zu erlauben. Es gibt ja grundlegende Kontrollstrukturen, die dies erledingen können.
Dies ist vorallem wichtig wenn der Kunde/user das Layout verändern
kann/will. Man kann den "Manipulatoren" nicht immer vertrauen
(speziell wenn es sich um ein grosses Multiusersystem geht -> php
erlauben ist gefärlich!).

Der Geschwindigkeitsaspekt ist berechtigt -> es wird langsamer. Dies
kann aber durch caching wettgemacht werden. Natürlich ist dies auch
sinnvoll ohne solche Templateengines!

" Eine Anpassung der Core führt also zwingend zu Anpassung
an der Oberfläche "
Ist dies nicht auch zwingend, wenn keine Templateengine verwendet wird!?!

" Situative reine Ausgabe ohne Aktionssteuerung "
Dies ist die Aufgabe der Templateengine

" Es macht hier jedoch keinen Sinn, dass
man diese Logik in einer nochmals anderen Sprache formuliert "
Dies zielt für mich auf diese Eigenschaft ab, dass das Design von
einem Designer gefertigt werden kann, der keine Ahnung von PHP haben
muss.

" PHP ist nämlich in diesem Falle eine sehr
geeignete Templatesprache.. Eine wichtige Frage ist hier höchstens
noch die (Visuelle) Editorunterstützung "
Editorenunterstützung ist meineserachtens kein Problem. Doch wie
schon vorher erwähnt ist es nicht immer sinnvoll (aus Sicherheitsgründen)
php in Templates zu erlauben.
Dies erledigt sich natürlich, wenn man alles alleine programmiert,
oder dem Partner/Angestellten vertrauen kann (doch wie kann man da je
sicher sein? Es sind auch nur Menschen... you never know.)

Ok ev.ist dies einwenig zu paranoid ;o)


Ich werde mich mal weiter mit smarty beschäftigen, doch ich bin immer
interessiert an anderen besseren Lösungen, die auch Produktiv
eingesetzt werden können.


Gruss Pozor (now from East Vancouver, BC, Canada)

PS: Ich wäre sehr interessiert an diesem Gespräch teilzunehmen, doch
bin ich noch mindestens 1 Monat in Kanada :o). Und was dieses Thema
angeht ich bin momentan eifrig am Informationen sammeln, da ich mich
bis anhin nicht intensiv mit Templateengines und Alternativen
beschäftigt habe...

Rello!

Smarty hat sich wohl sehr gut behauptet und scheint auch aus meiner
Sicht ein gutes TS zu sein.
Ich habe u.A. gestern schnell die gesamte Dokumentation
durchgearbeitet und mich auf den neuesten Stand gebracht.

Ja, das Trennen von Design usw tönt verlockend..
Der Sicherheitsaspekt ist auch wichtig..
Man muss sich jedoch bewusstsein, dass sich bsp. auch in
Templatesystemen resp ihrer Sprache viele Syntaxfehler einschleichen
können, welche genauso zu einem Parserfehler führen.
Sicherheit gibt dies zwar vor unberechtigtem Nutzen von
internen Funktionen, nicht aber vor 'Zerstörung des Templates'.

Die Paranoide Einstellung kann ich speziell nicht unterstützen,
denn der Einsatz eines Templatesystemes schützt überhauptnicht vor
Missbrauch. Man muss sich bewusstsein, dass der 'Designer' in keinem
Falle eine Person ist, vor der sich der Programmierer schützen muss!
Es handelt sich um eine Person welche vertrauenswürdig ist.
Existiert eine Schnittstelle zum bsp. zu einer DB zuzugreifen,
(Mutationsfunktionen, ...), existieren diese Funktionen im
Templatesystem grundlegend. Je breiter das TS angesiedelt wird,
umso breiter wird die Unterstützung für solcher Funktionen. Je
generischer dabei die Implementation, umso mehr Optionen können
im Design generisch verwendet werden. Konsequenz: Schon wieder
könnte der Designer mist bauen.. usw..

Meine Sorge gilt hier der Implementation (Programmierer):
Eine saubere Einbindung in ein Grundkonzept ist echt komplex. Muss
ich ein System als Template abbilden, das sehr viele gesteuerte
Elemente ausgibt (hochgradige Dynamisierung nicht nur des Inhaltes,
sondern der Dokumentstruktur), führt dazu, dass man ein solches
Script nichtmehr vernünftig in einem visuellen Editor bearbeiten kann!
Ich habe hier noch keine brauchbare Lösung gesehen, und das ist weder
bei PHP als Sprache noch bei Templatesystemen besser..

Verschnipselt man es bereits bei der Entwicklung in viele kleine
Stücke, weisen dieselben wieder Abhängigkeiten auf. Das Design wird
durch diese weitgehend definiert!
Ändert man hier etwas an der Logik der Bedienung, ist die direkte
Konsequenz eine komplette Anpassung der Verarbeitungslogik.
Diese enge Bindung macht mir vielmehr Sorgen, als jede Kopplung an
den Datenmodellkern! Hier hören meine konkreten Lösungsvorstellungen
punkto Optimum in der Implementation auf, und ich glaube nicht, dass
diese Frage schnell beantwortet werden kann.

Ein Monat wär' kein Problem, ich hab' zu tun bis dann :)

GrEeZ from SwIzZ: Miro Dietiker

Hallo,

Nach 3 Tagen auf der Suche nach Meinungen, Tatsachen, Benchmarks und
dem Durchsuchen mehrer Foren (haupsächlich english-sprachige), habe
ich einige interessante Aspekte mehr kennengelernt.

So ganz grundsätzlich kann man sagen, für gewisse Situationen passt
ein Templatesystem ganz gut.
Ganz allgemein sind Templates eine sehr gute Erfindung, nur nicht die Templateengine.

Ich fand einige sehr gute Artikel über Templatesysteme, die teilweise sehr nagativ, teilweise eher positiv darüber berichten.

Hier mal 2 Artikel, die kritisch über Tepmlates berichten:

http://phppatterns.com/...e/articleview/4/1/1/
http://www.massassi.com/...es/template_engines/


Und noch ein interessanter Thread:

http://www.sitepointforums.com/...d.php?threadid=67849


greez Pozor