Wieso/wofür nutzt ihr Templatesysteme?

Aufgrund der Diskussion hier:
Template-Engine
habe ich mal einen extra Thread aufgemacht in welchem es mir um den Sinn von Templatesystemen geht.
Wieso nutzt ihr ein Templatesystem und wofür?

Die Frage ist nicht ernst gemeint oder?
Der Vorteil liegt klar auf der Hand, du hast flexibiltät in Sachen Design und User Interface... du kannst schnell zwischen verschiedenen Designs wechseln oder halt dem User verschiedene Designs zur Verfügung stellen oder sogar welche vom User entwerfen lassen....

Um die Eingabelogik (Programmierung, Datenverarbeitung, etc.) von der Ausgabelogik (HTML, XHTML, SVG, PDF über den Umweg XML-FO, etc) zu trennen.
Korigiert mich fals ich falsch liege.

Die Frage IST ernst gemeint!
Ich habe in den über 8 Jahren Job (Systemprogrammierung) noch nicht ein Templatesystem benötigt.
Im Moment sehe ich nur, das man zwar eine Trennung vom Backend erreichen kann damit, aber dafür eine Erhöhte CPU-Last erzeugt, welche man z.B. durch Caching-Systeme abzufangen versucht.
Hier kommt wohl auch mein Job zum tragen... Analyse der Aufwände im Vergleich zum Nutzen. Bin da leider negativ geprägt und versuche sowas immer erst zu analysieren bevor ich es einsetze.

Eins der sinnvolsten Einsatzgebiete von Templates zeigt ja dieses Forum hier: ohne lang im Quellcode herumzustöbern und herumzubasteln, kann man mit Templates sehr schnell verschiedene Designs und Layouts für eine Seite erstellen.

Ok... Sinn und Zweck verstanden.
Jetzt muß ich nur noch rausbekommen welche für mich Nützlich sind.
Habe bisher nur mit CSS und HTML zu tun gehabt und mich von Sachen wie XSL, XML und Co. fern gehalten.

Original von MrMarco
Wieso nutzt ihr ein Templatesystem und wofür?

Weil Seitendesign im PHP-Quellcode zum würgen ist
Für ein BG kann es auch sinnvoll sein, Spielern unterschiedlicher Gruppenzugehörigkeit (z.b Rasse bei Fantasyspiel, Land bei Kriegsspiel) unterschiedliche Layouts zu verpassen.
Bei diesem Syndicates (heisst das so?)-Spiel wird das z.b. gemacht.

Nun ja...
So sieht bei mir eine Seite aus:

     





Ich bin halt Rückständig.. i know...

Das kannst du aber laut sagen.

Soweit ich sehen kann, setzen viele von euch ein eigenes Templatesystem ein, welches wohl im Groben auf ein "nimm das File, suche den Platzhalter und ersetze ihn mit Inhalt" hinaus laufen.
Hmmm... wo hatte ich doch gleich mein altes Templatesystem hin, was genau das auch machte?

Außerdem kann man so das Layout an andere Leute abgeben, ohne gleich den ganzen Code mitschicken zu müssen.
Und das Smarty-Templateformat ist recht HTML-Editorfreundlich, wer also unbedingt will kann sie mit Frontpage, Dreamwaver oder sonstwas bearbeiten, ein paar Designer schwören darauf.

Bei Sprachen wie PHP halte ich Templateengines für überflüssig. Bei Smarty werden tausende Mannstunden dafür verschwendet eine neue Scriptsprache zu entwickeln um Templates zu formulieren. Und wozu? Damit ich statt in Zukunft {var} schreiben kann. Klasse Ding, wirklich. Sprachen wie PHP sind an sich schon Template sprachen weil man sie in andere Texte einsetzen kann. Den einzigen Sinn den ich sehe ist seine Templates direkt in PHP zu schreiben und dann in der eigentlichen "Businesslogik" zu verwenden.
Was bei der ganzen Diskussion aber gerne übersehen wird: nicht jede Sprache kann man in HTML einbetten. Bei Java ist das z.B. so. Dort greift man dann besser auf ein Templatingsystem (JSP, Velocity, Freemarker, wenn man lustig ist auch PHP) zurück wenn man den HTML Code nicht gerade in seine Servlets einkompilieren will. Sprachen wie PHP sind aus dem Grunde entstanden und manche der Techniken wie Velocity und Freemarker implementieren teils schon Turing-komplette Scriptsprachen zwecks Templating. Also im Grunde die Domäne in die, zumindest ursprünglich, auch PHP fällt.
Anderer Einsatzbereich sind Systeme wo du grundsätzlich Templating benötigst, wie bei Content Management Systemen. Bei Bricolage kannst du z.B. auch PHP als Templatesprache verwenden. Sowas macht dann Sinn, Smarty - wo man auf Basis einer Templatesprache eine weitere Templatesprache entwickelt - halte ich für - höflich ausgedrückt - groben Unfug.
Bisschen Lektüre über den Sinn und Unsinn von Template Engines bei PHP: www.massassi.com/php/articles/template_engines/ und ein bisschen abgewandelt hier: www.sitepoint.com/article/beyond-template-engine

So die Aussage das die selbstgebauten Template-Systeme nur Platzhalter ersetzen.. da muss ich mich nun einfach mal einschalten, weil ich mein Templatesystem sicher nicht für Perfekt aber doch recht "weit entwickelt" halte.
Kernfunktionen für Tempaltes

• Variablen
• if / elseif / else - Strukturen
• Schleifen (Um Arrays z.B. als Tabelle aufzulisten)
• PHP-Parsing
• Kommentarfunktion und Noparse-Bereiche
• Counter und Wechselvariablen (z.B. für Hintergrundfarben)
• Erstellen von oder -Elementen mit Variablenwerten
• Variablenfilter (z.B. runden, ersetzen, BBCode, nl2br, usw.. )

Und noch paar andere Dinge..
Dazu gibts dann 2 Cache-Stufen. Sprich einmal ein normaler Cache der fertig berechnete Seiten zwischenspeichert, aber auch ein parse-cache der die Templates vorsortiert/zerlegt zwischenspeichert wodurch dynamsiche Seiten die man nicht richtig cachen kann/will nur die halbe Berechnungszeit brauchen.
Also nicht jeder Eigenbau ist nen simples Suchen/Ersetzen von Schlüsselworten.

DAS nenne ich mal eine Antwort
Merci!
Da muß ich mir mal Gedanken zu machen... Meine Regierung ruft leider... Soviel zum Urlaub... Küche aufräumen.... args...

Original von Mudder
Kernfunktionen für Tempaltes

• Variablen
• if / elseif / else - Strukturen
• Schleifen (Um Arrays z.B. als Tabelle aufzulisten)
• PHP-Parsing
• Kommentarfunktion und Noparse-Bereiche
• Counter und Wechselvariablen (z.B. für Hintergrundfarben)
• Erstellen von oder -Elementen mit Variablenwerten
• Variablenfilter (z.B. runden, ersetzen, BBCode, nl2br, usw.. )

Das sind aber auch nur Platzhalter die du entweder on-the-fly interpretierst oder nach PHP kompilierst. Im Grunde erfindest du nur eine Variante das Problem zu formulieren.
Ich sehe nicht den großen Vorteil

{if $var == "foo}

blubb
{else}
blah
{/if}
statt

blubb
blah
zu schreiben. Ok, ist etwas leserlicher aber deswegen hunderte Stunden verschwenden? Die Rechnung stimmt IMHO nicht so ganz ..

Er hat damit eine Trennung vom Presentationlayer vom Businesslayer erreicht.
Aber... ich sehe hier eine erhöhte CPU-Last, welche mir bei anderen Features dann vielleicht fehlen würde.

Nun zu versuchen dich von einer Template-Engine zu überzeugen versuch ich garnicht erst.
ICH verwende Templates um eine klare Trennung von PHP und HTML zu haben (meine alten Scripts mit dem ganzen gemixe kenn ich noch zu gut). Wiso ich nun eine Templateengine und keine einfachen "PHP"-Templates nehme, liegt daran das ich mit der Templateengine auch ohne zusätzliche PHP-Anweisungen z.B. wechselnde Hintergrundfarben für Listen einbauen oder Schleifen mit Start/End-Werten auszustatten kann und dabei z.B. nicht:
[FONT=courier new][/FONT]
sondern "nur":
{&wert1 nl2br}{&wert2}
schreiben muss. Das ist für mich dann auch eine klare Trennung von PHP und Design.
Wiso ich nun auch noch meine eigene Engine schreibe und dabei hunderte Stunden verschwende.. Wiso schreibt jemand ein neues Gästebuch wo es doch hunderte Fertigscripts gibt? Wiso gibt es Linux oder Firefox wo doch MS mit Windows und IE schon fertige Produkte geliefert hat? Wiso schreibt Ihr an neuen BGs wo es doch schon so viele gibt?

Mit einem Templatesystem wird der Code unabhängig.
Die gleiche Anwendung (der gleiche Scriptcode) kann einen Code für eine Webseite liefern, kann Code für ein Handy liefern oder gar eine XUL-Oberfläche? Und das sind nur die Möglichkeiten, die XML (in Gecko) einem bieten.. theoretisch könnte die Templateengine auch PDFs erzeugen (über Sinn und Unsinn braucht man sich jetzt nicht zu streiten).
Wichtig ist nur.. dem Code kann das egal sein.
Jetzt wird man natürlich sicher das Argument einwerfen "Aber, das soll doch eh nur 'Html' sein". Klar, das Hauptziel im Internet wird HTML (oder XHTML?) sein. Aber wenn man seine Ausgaben zentralisiert, ist man fast jederzeit in der Lage, seine Ausgabe anzupassen. Bei einzelnen Smartytemplates stell ich mir das noch schwierig vor (habe wenig Ahnung von Smarty..), aber bei Templatesystem, die jedes Layoutelement nur einmal definieren kann man das gesamte Ausgabeformat immer neu definieren.
Im konkreten Beispiel? Eine Anwendung läuft erfolgreich, nutzt aber HTML 1.0 Trans und CSS 1. Nun, jetzt sind vllt 2 Jahre vergangen und man denkt sich.. HTML 1.1 könnts ja schon sein, CSS 2.. vllt sogar multiple Styles... wenn man ein Template hat, lässt man den Code in Ruhe und ändert nur das Template.
Eins muss man sich natürlich klarmachen: Wenn man vorher genau weiß, das sein Projekt nie, nie und nochmals nie anders verwendet wird, kann man sich die ganzen tollen Klassen, Objekte und weiß der Teufel für Universalsachen schenken und sie lieber hart, effizent erstellen. Nur Anwendungsspezifisch, ohne Ausnahmen..

Original von exe
Und wozu? Damit ich statt in Zukunft {var} schreiben kann.

Naja, meist ist es dann doch nicht so einfach.
Mit $var passiert ja in den meisten Fällen noch so einiges.
Gerade bei Browsergames stehen ja oft recht komplexe Berechnungen an,
die man eben nicht im HTML-Code stehen haben will.
Dann steckt hinter $var vielleicht 20 Zeilen Code im PHP-Script.

Interessante Diskussion...
Ich sehe deutlich wo die Grenzen liegen. Da ich bei mir z.B. nie vorhatte ein Frontend von Usern erstellen zu lassen (habe heute noch die Schnauze voll davon aus dem Vorgängerspieler...), kann ich auf ein Templatesystem verzichten, oder ich nutze nur ein relativ einfach gestricktes.
Da ich als Designentscheidung PHP nur für die Erzeugung vom Frontend nehme, kann ich hier entweder eine komplette Loslösung von PHP erreichen (MONO/.NET läßt grüssen), oder ich behalte das bisher erreichte bei, was dann aber eine vermischung von PHP, HTML, CSS, JavaScript und wenigen SQL-Statements ist.
Hat halt alles seine Vor- und Nachteile.

Original von MrMarco
Er hat damit eine Trennung vom Presentationlayer vom Businesslayer erreicht.

Die erreicht er auch wenn er in seinen Templates PHP statt Smarty (oder einer Eigenentwicklung) verwendet Es geht im Grunde darum, dass mit der Benutzung einer eigenen Scriptingsyntax im Template zusätzlicher Code ausgeführt werden muss, was aber nicht nötig wäre weil die Sprache (PHP) die Templatingfeatures schon von Haus aus unterstützt.

Original von Mudder

Das ist für mich dann auch eine klare Trennung von PHP und Design.
Es geht um Trenning von Businesslogik von Präsentationslogik. Das man PHP und HTML Trennen muss wie der Teufel das Weihwasser scheut ist eine gängige Missinterpretation dieser Aussage bei Entwicklern von Templateengines für PHP.
Auch dein Codebeispiel demonstriert keine andere Trennung von Business und Präsentation (oder Design und Code) als wenn du es direkt in PHP machst.
PHP: die Begrenzung von Templateanweisungen läuft mit
Templatescript: die Begrenzung läuft mit { und }
PHP: nl2br(wert)
Templatescript: wert nl2br (oder wert|nl2br oder wert?nl2br).
Was du mit deiner Templateengine machst ist ein syntaktischer Unterschied zu PHP, kein funktioneller.

Original von Blabbo

Gerade bei Browsergames stehen ja oft recht komplexe Berechnungen an,
die man eben nicht im HTML-Code stehen haben will.
Dann steckt hinter $var vielleicht 20 Zeilen Code im PHP-Script.
Was sich mit PHP-Templates nicht ändern würde. Der Unterschied ist, dass du die Templates mit PHP anstatt einer (mehr Overhead produzierenden) Templatescriptingsprache formulierst.

Dann ist es eben überflüssiger Balast. Genauso wie das Kopfkissen im Bett oder das Radio im Auto. Man würde auch ohne auskommen und beides kostet nur Geld.. aber wiso hat es dann jeder?

Weil es wie z.B: AJAX leet ist?
Ich denke mal, daß es einfach eine Designentscheidung ist.
Bin jetzt in Gedanken mehrmals die Vor- und Nachteile, die Zeitaufwände, die erkannten Risiken etc. durchgegangen und werde bei mir kein Templatesystem einsetzen.
Das Layout wird von mir vorgegeben. Das Rahmendesign ist in ein paar Includes gesteckt. Von daher kann ich gezielt Sachen anpassen und ändern.
Da mein nächstes Projekt auf einer anderen Sprache aufsetzen wird und eventuell gar kein Browsergame mehr wird, kann ich hier auf ein echtes Templatesystem verzichten.
Danke nochmal an alle Beteiligten für diese offene und recht interessante Diskussion!

Eigentlich sind Template-Engines nur eine komfortfunktion, welche den HTML-Code vom PHP-Code trennen und ihn evtl. etwas leserlicher machen.

ich nutze templates weil:

• ich die Darstellungslogik von der Programmielogik trennen möchte
• weil ich wenig ausgabe doppelt programmieren will (z.b. kein extra "/body" vor den die(); )
• weil ich so mein design schneller ändern kann (um es w3c-konform zu machen oder auf userwünsche einzugehen)
• weil ich so auf einfache weise eine multilingualität umsetzen kann

was nutze ich hierzu?
Savant 3. Weil es nix aufgeblähtes ist und wenn jemand an meine templates kommt, dann kann er auch an meine anderen scripte (argument sicherheit einer templatesprache zählt somit nicht)
Außerdem: wieso sollte jemand an meine templates? HTML ist keine Designsprache sondern eine Beschreibungssprache. ich beschreibe damit den aufbau der seite (1 navi-liste, 1 div mit ner ressliste, 1 div content,...).
Die Positienierung/das Aussehen läuft strikt und ausschlisslich über css und kann vom Benutzer individuell angepasst werden.
Desweiteren hab ich für jede sprache einen templatesatz, der dann auch extern übersetzt werden kann und dann (nach prüfung) eingesetzt wird.
Wieso nimmst du nicht ...?
ich nehme kein smarty, weil es
[list=a]
[*]zu überladen ist
[*]keine "neue" Funktionalität bietet die ich brauchen könnte
[*]"caching" bei einem spiel, wo sich mit jedem aufruf etwas ändert unsinn ist
[*][strike]es sich nicht durch "acceleratoren" beschleunigen lässt (das kompilierte script cachen), da es eine "eigene" sprache hat [/strike][/list=a]
Wer sich mal überlegt.. PHP ist eine Template-engine, geschrieben in C/C++. nun setzt man auf eine template-engine noch eine andere template-engine (smarty)?! da nehme ich lieber eine "trenner"-engine, die php als "syntax" nutzt.
so. nu dürfen alle smarty-trolls einmal auf mich einhauen..
edit: neit sollte mal durchstreichen von text erlauben .. :/

Original von Mudder
Dann ist es eben überflüssiger Balast. Genauso wie das Kopfkissen im Bett oder das Radio im Auto. Man würde auch ohne auskommen und beides kostet nur Geld.. aber wiso hat es dann jeder?

Nicht alles was hinkt ist ein Vergleich.

Original von Drezil

ich nehme kein smarty, weil es
[list=a]
[*] [...]
[*]es sich nicht durch "acceleratoren" beschleunigen lässt (das kompilierte script cachen), da es eine "eigene" sprache hat
[/list=a]
Nicht ganz richtig, Smarty kompiliert intern PHP-Scripts aus den Templates. D.h. die kompilierten Templates werden von Bytecodecaches auch in den Cache aufgenommen.

Wer sich mal überlegt.. PHP ist eine Template-engine, geschrieben in C/C++. nun setzt man auf eine template-engine noch eine andere template-engine (smarty)?! da nehme ich lieber eine "trenner"-engine, die php als "syntax" nutzt.

Meine Rede ... verzichtet (bei PHP) einfach auf den Unsinn mit Engines die neue Scriptsprachen implementieren. Man formuliere seine Templates mit den Bordmitteln von PHP und benutze oder schreibe einen Wrapper wie Savant (wenn ich das auf den ersten Blick richtig sehe).

Original von Drezil
was nutze ich hierzu?
Savant 3.
[...]
Wieso nimmst du nicht ...?
ich nehme kein smarty, weil es
[list=a]
[*]zu überladen ist
[*]keine "neue" Funktionalität bietet die ich brauchen könnte
[*]"caching" bei einem spiel, wo sich mit jedem aufruf etwas ändert unsinn ist
[*]es sich nicht durch "acceleratoren" beschleunigen lässt (das kompilierte script cachen), da es eine "eigene" sprache hat
[/list=a]

Mal ne blöde Frage, ich hab mir Savant nur kurz angesehen, aber für mich sieht das so aus, als ob man da bloß die Zwischenstufe von Smarty weglässt. Smarty macht aus den Templates ja auch PHP-Templates, wandelt diese eben um. Daher sehe ich jetzt den Vorteil von Savant nicht.
Smarty hat eben den Vorteil, das man da einen Designer dransetzen kann, der muss kein PHP können und Smarty selber ist sehr gut dokumentiert und überschaubar.
Auch Multilingualität kann man damit herstellen, einfach die Templates übersetzen und eben in unterschiedlichen Verzeichnissen speichern. Smarty kann das bei dem vorkompilierten Templates mit berücksichtigen.
Ich benutze Smarty, weil mir das eben Vorteile bringt und mir die Performance nicht so absolut wichtig ist (da hol ich lieber woanders Geschwindigkeit raus). Besonders wenn man eben Darstellung und Code getrennt haben will, führt für mich kein Weg an Templates vorbei.
Aber muss ja jeder selber wissen. Ich find HTML in PHP-Code grässlich, das macht den Code absolut unleserlich. Meine Meinung.

Original von Toby

Original von Drezil
was nutze ich hierzu?
Savant 3.
[...]
Wieso nimmst du nicht ...?
ich nehme kein smarty, weil es
[list=a]
[*]zu überladen ist
[*]keine "neue" Funktionalität bietet die ich brauchen könnte
[*]"caching" bei einem spiel, wo sich mit jedem aufruf etwas ändert unsinn ist
[*]es sich nicht durch "acceleratoren" beschleunigen lässt (das kompilierte script cachen), da es eine "eigene" sprache hat
[/list=a]

Smarty hat eben den Vorteil, das man da einen Designer dransetzen kann, der muss kein PHP können und Smarty selber ist sehr gut dokumentiert und überschaubar.
Ich will mal ganz frech behaupten das, wenn ein Designer das {if $foo == $bar} blubb {else} blah{/if} von Smarty versteht, dass er dann auch das if($foo == $bar) { blubb } else { blah } von PHP hinkriegt
Smarty ist imho syntaktisch nicht viel einfacher als PHP. Schleifen, Abfragen usw. sind anders formuliert aber nicht zwangsläufig einfacher.

Auch Multilingualität kann man damit herstellen, einfach die Templates übersetzen und eben in unterschiedlichen Verzeichnissen speichern. Smarty kann das bei dem vorkompilierten Templates mit berücksichtigen.

Wunderbar, dann änderst du was am Design und musst zig Kopien der Templates durchackern. Oder man vergisst eine Änderung an einer anderen Sprache und schwupps die wupps sieht das Layout in den verschiedenen Sprachen anders aus. Das Ende ist dann, dass du vor jedem Release deine Templatesätze durchchecken musst um dafür zu sorgen, dass sie alle synchron sind.
Gute Idee

Besonders wenn man eben Darstellung und Code getrennt haben will, führt für mich kein Weg an Templates vorbei.

Wie schon geschrieben, Trennung von Präsentation und Business hat nichts mit Trennung von PHP und HTML zu tun ...

Original von exe

Original von Blabbo
Gerade bei Browsergames stehen ja oft recht komplexe Berechnungen an,
die man eben nicht im HTML-Code stehen haben will.
Dann steckt hinter $var vielleicht 20 Zeilen Code im PHP-Script.

Was sich mit PHP-Templates nicht ändern würde. Der Unterschied ist, dass du die Templates mit PHP anstatt einer (mehr Overhead produzierenden) Templatescriptingsprache formulierst.
Nein, der Unterschied ist, dass im Template nur {{var}} steht,
anstatt 20 Zeilen PHP-Code.
Von einer Template-Scripting-Sprache hab ich nie gesprochen.

Auch ein Grund, warum für mich direkte Texte in einem Template nichts zu suchen haben. Das Script muss entscheiden, welche Sprache angezeigt wird - oder aber das Template ist so intelligent, und kann die Texte selbstständig ersetzen.. aber das sprengt dann in meinen Augen die "Templatefunktionalität".
Ich halte auch nix von Smarty, weil es für mich einfach überladen ist.
Meine Entscheidung, auf XML-Basis umzusatteln, habe ich noch nicht bereut.. und schnell ist es allemal.
edit:

Original von Blabbo

Nein, der Unterschied ist, dass im Template nur {{var}} steht,
anstatt 20 Zeilen PHP-Code.
Von einer Template-Scripting-Sprache hab ich nie gesprochen.
Dann steht im späteren PHP-Template eben
Wofür nochmal Smarty?

Original von knalli

Original von Blabbo
Nein, der Unterschied ist, dass im Template nur {{var}} steht,
anstatt 20 Zeilen PHP-Code.
Von einer Template-Scripting-Sprache hab ich nie gesprochen.

Dann steht im späteren PHP-Template eben
Wofür nochmal Smarty?
Nene, nix smarty.
Mir gings erstmal um den Sinn von Templates an sich.
Und ich finds einfach besser, das Tpl einzuladen, dann die Platzhalter zu ersetzen, anstatt mir alle Variablen zurechtzulegen und dann das Tpl zu includen.
Ein Template sollte imo sowieso auf .html enden, denn das ist, was es ist, ein HTML-Layout.
Dann kann ichs auch einfach doppelklicken und seh im Browser, wie mein Layout aussieht.
Und noch was an die Programmiererfront:
Glaubt mir wenn ich euch sage, dass für einen Designer

{{var}}

ein himmelweiter Unterschied dazu

ist

Original von Blabbo

Original von exe

Original von Blabbo
Gerade bei Browsergames stehen ja oft recht komplexe Berechnungen an,
die man eben nicht im HTML-Code stehen haben will.
Dann steckt hinter $var vielleicht 20 Zeilen Code im PHP-Script.

Was sich mit PHP-Templates nicht ändern würde. Der Unterschied ist, dass du die Templates mit PHP anstatt einer (mehr Overhead produzierenden) Templatescriptingsprache formulierst.
Nein, der Unterschied ist, dass im Template nur {{var}} steht,
anstatt 20 Zeilen PHP-Code.
Von einer Template-Scripting-Sprache hab ich nie gesprochen.
Entweder ist {{var}} eine Variable die von deiner Businesslogik in 20 Zeilen PHP-Code mit einem Wert gefüllt wurde (dann heisst im PHP-Template) oder es ist eine 20 Zeilen lange Funktion, dann heisst es halt .

Original von exe
.

hehe, das ist ein Argument.
Dennoch find ichs einfach unschön.
Genauso wie ichs nicht schön finde, HTML auszugeben, bevor nicht das ganze script durchgelaufen ist.
Weiss nicht, woher das kommt, ist aber so.
Deutsche Ordentlichkeit oder sowas

Findet bei einem PHP-Template genauso wenig statt wie bei einem manuell geparsten Template.
Ob ich in meinem Script

$foo = "foo";

$bar = "bar";
include "template.php";
oder

$tpl = str_replace("{{foo}}", "foo", $tpl);

$tpl = str_replace("{{bar}}", "bar", $tpl);
echo $tpl;
schreibe macht in dem Zusammenhang keinen Unterschied.

ok, punkt für dich

XSLT bietet einige Vorteile. Zum einen generiere ich mit PHP die Daten als XML und gebe sie mit einem XSl wie gewünscht aus. Z.B. als XHTML oder als WML Seite, ein anderes mal als PDF (für Berichte), wieder ein anderes mal als SVG. Wenn ich wollte sogar VRML. Zweitens bietet es Schnelligkeit. Und dies alles auf den selben Grunddaten. Und da wir hier in einem Browsergameforum sind, spreche ich noch die Möglichkeit der Userinteraktion aus. Man z.B. stündlich XML-Daten generieren lassen, und User schreiben auf Basis dieser XML-Daten ihre eigene Skripte, z.B. einen Wegzeit-Rechner.

Original von exe
Und wozu? Damit ich statt in Zukunft {var} schreiben kann. Klasse Ding, wirklich.

naja zumindest vermeidest du Shorttags
jeder muss es für sich entscheiden ... der Vorteil an Templatessystemen ist einfach die Möglichkeit schnell zwischen Designs zu switchen ... ob nun Smarty oder XYZTemplate besser ist steht doch gar nicht zur Debatte

Original von TheHawk
XSLT bietet einige Vorteile. Zum einen generiere ich mit PHP die Daten als XML und gebe sie mit einem XSl wie gewünscht aus. Z.B. als XHTML oder als WML Seite, ein anderes mal als PDF (für Berichte), wieder ein anderes mal als SVG. Wenn ich wollte sogar VRML. Zweitens bietet es Schnelligkeit. Und dies alles auf den selben Grunddaten. Und da wir hier in einem Browsergameforum sind, spreche ich noch die Möglichkeit der Userinteraktion aus. Man z.B. stündlich XML-Daten generieren lassen, und User schreiben auf Basis dieser XML-Daten ihre eigene Skripte, z.B. einen Wegzeit-Rechner.

Zack. Bumm. Da hats einer geschnallt - Juhuu *g*
Willkommen im Web2.0, wo der User mitarbeitet ;O
Ein Grund, Ausgabe und Script zu trennen: Fehlerbehandlung und vollständige Freiheit der Ausgabegenerierung.
Wenn man die Ausgabe komplett von der Code-struktur trennt, hat man alle Freiheiten, die man braucht.
- ich kann zu einem späteren Zeitpunkt den Titel des Dokuments noch ändern
- ich kann zu einem späteren Zeitpunkt die Standardausgabeform noch ändern
- ich kann zu einem späteren Zeitpunkt noch externe Dokumente (Javascript, CSS) einladen (/html/head/script oder link)
- ich kann ein outline der dokumentstruktur machen
oder auch:
Ich kann abhängig von der Menge an Daten (!=Ausgabedaten) die Art und Weise der Präsentation ändern, zB mehrspaltige Tabelle, alternierende Tabellenzeilen (komplett XSL, da brauch mir kein PHP-Script rumzuwurschteln), vllt zwei spaltige Dokumentansicht, weil es viel Text ist.. usw..

Das setzt aber auch vorraus, daß man den User mitarbeiten lassen will.
Ich persönlich habe da so meine Bedenken. Jede Schnittstelle stellt eine mögliche Sicherheitslücke dar. Und ich habe mit meinen eigenen Sachen schon genug zu tun.

Original von MrMarco
Das setzt aber auch vorraus, daß man den User mitarbeiten lassen will.

Warum das? Wie kommst du da drauf?
ps: das muss nicht unbedingt der Fall sein

So eine XML-Schnittstelle für bestimmte Daten kann schon Sinn machen.
Beispiel OGame: dort gibt es haufenweise Seiten die z.B. die Highscores auswerten und daraus Statistiken generieren. Warum nicht die Entwicklung solcher externen Tools fördern indem man die Daten sauber aufbereitet zur Verfügung stellt? Normalerweise grabben sich die Helfer solcher Tools die Daten indem sie einfach Copy&Paste aus dem Spiel machen (was ziemlich umständlich ist).

XSL bietet sicher einige weitreichende Fähigkeiten und grade für "offene" Communites bietet sich hier ein grosses Potenzial. Doch für eine normale "Homepage" oder auch BGs finde ich XSL ehr als negativ.
Es bringt zwar alle weitreichenden Fähigkeiten einer Templateengine mit, doch grade für BGs dürfte sich das freie Design als Schädlich erweisen.
Bots und Scripts bietet man mit der XML-Seite eine komfortable Basis die nun nichtmal den HTML-Code auslesen müssen und angesichts der Tatsache das BGs hauptsächlich über Werbung finanziert werden, so dürften eigene Designs ohne lästige Werbebanner bei den Spielern sicher guten Anklang finden.
Es hat einfach auch immer zwei Seiten und im Moment halte ich solche Wechsel eh für etwas problematisch, da zig neue "Sprach"-Versionen in der Mache sind und die Browser (auch in Entwicklung) oftmals nichtmal die alten "Sprachen" richtig interpretieren.

Wie Mudder sagte, beherschen nicht alle Browser die XSL-Transformationund darum verwende ich die interne libxsl von PHP um den HTML Code zu generieren. So kann keiner an meine XML-Daten ran, außer die freigegeben.

Für die Rangliste etc. gab es im alten Spiel schon einen XML-Extrakt.
Der war dokumentiert. Für die neue Version gibt es auch schon ein Grobkonzept für diese und weitere Schnittstellen.
Hmm.. ich merk immer wieder das ich wirklich von der alten Garde bin. Die neuen Techniken verschließen sich mir immer wieder, weil ich einfach keinen wirklichen Nutzen an den Mehraufwänden sehe... Mist
Das scheiß Wissen über COBOL, Assembler und Co. hat sich so heftig festgesetzt, das es schwer wird hier umzudenken.

Original von TheHawk
Wie Mudder sagte, beherschen nicht alle Browser die XSL-Transformationund darum verwende ich die interne libxsl von PHP um den HTML Code zu generieren. So kann keiner an meine XML-Daten ran, außer die freigegeben.

Die einzige aktuelle Möglichkeit, das stimmt. Aber man kann jederzeit - sofern man keine serverseitigen Einschränkungen wie zB PHP-Funktionen im XSL-Template verwendet - das serverside durch clientside austauschen.
Seit Opera 9 sind alle aktuellen und nennenswerten Browser XSLT tauglich; es ist also nur noch eine Frage der Zeit, bis XSLT soweit verbreitet ist, dass man die entsprechende Randgruppe einkalkulieren kann. Macht man heute doch schon.. oder beachtet jemand noch Randerscheinungen wie NN4? Lange geisterten Scripts im Netz, die bestimmte Verhaltensmuster auszumerzen wussten.. heute schert sich keiner mehr drum.
Ich seh den Sinn in einem Template, das ich mir im "Programm" keine Gedanken um die Ausführung der Ausgabe machen muss. Man denkt im abstrakten Wege an die Ausgabe (hier: Da ist ein Absatz, da ist eine Überschrift, da ist eine Tabelle) aber eben nicht explizit ("Das ist ein p oder ein div mit p? - Das ist ist ein h2, h3, h4? - Das ist eine Tabelle mit tbody/head? Oder doch list?)..
Oder klassich: Script sagt: Füge Textbox ein, Template entscheidet, ob es input (einzeilig) oder textarea (mehrzeilig) ist. Und wenn in 2 Jahren der große textarea2.0 Hype ausgebrochen ist, ändere ich eine Bedingung im Template. Andere wurschteln in ihren Smartytemplates oder gar im Sourcecode, weil sich ein Anzeigeelement geändert hat.

Ich hab in unserem altem BG ohne so ein Templatesystem gearbeitet, hab mich dann, auch aufgrund der Unübersichtlichkeit, dafür entschieden mich mal darüber ein wenig zu informieren, hab aber anscheinend erstmal den Falschen Fuß dafür erwischt, gibt es denn einen Unterschied zwischen den hier beschriebenen Templatesystemen und einem CMS? Ich hatte mich damals zuerst für Jommla entschieden, dacht das ist bestimmt schön und gut, war auch ziehmlich aufgetakelt und die Funktionen hatten mich schon irgendwie fasziniert, allerdings bin ich heute ins Zweifeln gekommen, als dieses, ja eigentlich garnicht so unpopuläres Opensource-Projekt, hier nicht eines Wortes gewürdigt wurde. Hab mich nun erstmal für smarty entschieden, savant konnte mich irgendwie nicht überzeugen. Jommla ist nicht so für die Entwicklung von nicht-Blogs geeignet, kann dies sein?
Greetz,
xXx

Jommla ist eine große CMS-Lösung.. ich muss muss selber gestehen, ich wäre nicht auf die Idee gekommen, ein Browsergame mit einem bestehenden, großen CMS zu realisieren. Also, neutral gemeint..
Vom Umfang halte ich Jommla, soweit ich das einschätzen kann, aber etwas zu mächtig, zu groß. Und da ich Smarty schon zu groß halte..

also ich habe die komplette anzeige logik ins template verbannt.
also übergebe wirklich nur vorgefertigte objekt eand die Template Engine udn der rest ist in den Templates also kann ich locker zwischen XHTML, XML oder XUL wechseln

Anmerkung:
Das CMS heisst Joomla!

Original von Blabbo
Anmerkung:
Das CMS heisst Joomla!

Oh, mir ist garnicht aufgefallen, dass ich es falschgeschrieben hatte, ich hatte mich schon gewundert warum mein Nachrredner das ständig falsch schreibt...
Trotzdem bleibt bei mir die Frage, wo ist der Unterschied zwischen CMS und Templatesystem (haltet mich meinetwegen für dumm ).
Greetz
xXx

Ein CMS ist viel mehr,
da ist ne Userverwaltung dabei, Content-Module ect.
Ein CMS kann auch templatebasiert laufen,
dann braucht es eine Template-Engine.
Diese ist aber nur ein kleiner Teil des CMS.
Mit nem CMS kannst du die Inhalte der Website online ändern.

.. weil ich selber nur Mambo kannte, und Joomla (!) nur vom Hörensagen bzw. einem konkreten Anwendungsfall. Und da nehm ich dann schon mal die Schreibweise meines Vorgängers, nimmt man doch an, die wäre korrekt
Das Problem bei einem CMS (ganz allgemein) ist - so finde ich - ganz natürlich: Es muss viele Dinge abwickeln können, gute CMS-Lösungen können ja noch weitaus mehr als "nur" Content-Managen (wobei das alleine eine Riesensache werden kann) oder ein paar Benutzerrollen.
Bei einem Browsergame liegt das Augenmerk meistens eher auf die Spieltechnik; es ist wichtig, wie die Funktionen zueinenader aufgebaut sind, wann was in Kraft trifft oder zur Verfügung steht. Hin und wieder braucht man vllt soetwas wie Permissions, aber grundsätzlich sind das eher zwei verschiedene Welten.. oder nicht?
Wie genau hast du denn dein BG da integriert? Ich kenn mich mit Joomla wie gesagt nur schlecht aus.. ich weiß dementsprechend auch nicht, wie dort Templates oder wie auch immer aufgebaut sind.

Also es war nur ein Anfang eines Portales den ich integriert habe, danach, bzw. vllt besser jetzt, waren wir immernoch an dem Konzept zugange, aber ansonsten hatte ich mir gedacht einzelne Spielfunktionen als Module in PHP zu schreiben und diese dann über das Joomla Menü hinzuzufügen, templates kann man sich da auch selber schreiben, das hatte ich auch größtenteils gemacht, ist auch nciht großartig anders als das bei Smarty, lässt sich aber alles relativ chillig (yeah, ein Unwort :twisted über das Joomla Admin Tool dann verwalten, das war echt ein derber Pluspunkt.
Greetz,
xXx