nicht angemeldet
Hellihello dedlfix,
Es gibt mehrere.
Fein (;-).
Nach kurzem Googlen (http://www.phpforum.de/forum/showthread.php?t=205289, http://de.wikipedia.org/wiki/Template_Engine) finde ich aber u.a. bei Wikipedia den Satz: "Aufgrund eines Missverständnisses werden viele Template Engines von Programmierern eingesetzt, um im Kontext von Web-Applikationen Programm-Code (einer Programmiersprache) vom Design zu trennen."
Das Prinzip PHP-Code von HTML-Code zu trennen ist so schön klar, einfach zu verstehen - und nicht unbedingt das allerbeste.
Gnurf.
Man landet dann schnell wieder bei Code, der nicht unbedingt dem EVA-Prinzip folgt, sondern Teile der Ausgabelogik mit Teilen der Geschäftslogik vermischt. Die Frage ist, wer die Entscheidungen auflösen soll, was am Ende dargestellt wird.
Naja, die Überlegung ist ja, eine dieser drei Varianten
<?php echo Document::$title?>
oder Domfunktionen wie
$simple_xml->$title="mein Titel";
oder gar
foreach ($data as $datum)
{
echo "<td>$datum</td>\n";
}
zu ersetzen eben durch die Ersetzung in einem Template. Dadurch ensteht _eine_ zusätzliche Form der Variablencodierung (quasi ein Alias für eine Variable). Die Logik aber bleibt doch, wo sie vorher war, denn auch bei <?php echo Document::$title?> muss ja vorher der Wert gesetzt sein. Ob ich das durch eine PHP-Funktion "echo" mache, oder von PHP ersetzen lasse, ändert ja im Grunde die Sache eher marginal.
Gibt es Datensätze aus einer Abfrage, oder gibt es keine?
Ja, die gibt es, eine oder mehrer Zeilen einer Tabelle.
Soll bei einer leeren Menge eine entsprechende Meldung angezeigt werden, oder war etwa ein Fehler aufgetreten, über den berichtet werden soll?
Da hätte ich jetzt gedacht, dass die Fehlerkontrolle a) sein muss und b) komplett unabhängig von der "Template-'engine'" wäre.
Ist u.g. zielführend, verbesserungsfähig und/oder Geschmacksache?
[ein Template-Engine-Code]Das ist noch recht einfach von seinen Möglichkeiten. Du wirst schnell herausfinden, dass dir das nicht reichen wird.
Nun, die Darstellung mehrer Einträge durch einen dynamischen Block. Das wars dann aber auch.
Das ganze müsste ja im zweiten Schritt noch irgendwie rekursiv aufgerufen werden können mit einem Template a la:
<!-- /DBLOCK --><td>{name}</td><td>{contact}</td><td>{since}</td><!-- DBLOCK/ -->Da fängt es schon an, du rufst nach mehr Funktionalität. Bleibt trotzdem die Frage, wo du die Anzeigelogik unterbringen möchtest. Möchtest du eine eigene Syntax erstellen, die Steuerelemente (Bedingungen, Schleifen, Blöcke) enthält?
Nein, nur die o.g. Markierung. Es braucht also vier Definitionen: öffnender und schließender Begrenzer für die Spalten/Variablennamen und selbiges für einen dynamischen Block.
Lohnt sich der Aufwand, einer solchen zusätzlichen Syntax? Bedenke, du hast bereits PHP, HTML, CSS und vielleicht Javascript. Bedenke weiterhin, dass PHP bereits selbst eine Template-Engine (TE) darstellt. Eine weitere TE einzusetzen und/oder zu entwerfen verbraucht Ressourcen bei der Ausführung und für deren Entwicklung. Letzteres kann man auf Lernaufwand für eine neue Syntax abkürzen, denn TEs jeder Geschmacksrichtung gibt es ausreichend.
Ja, und dann wieder die Crux, tu ich mir das an, die alle anzuschauen und durchzutesten oder mach ich o.g. "einfach" selber. Zumal historisch bedingt Vorlagen nach dem o.g. Format schon existieren. Meine Idee war eher, das zu optimieren und evtl. sowas wie ein grundsätzliches Fazit zu ziehen.
Vielleicht ist dein Wunsch nach einer TE entstanden, weil du zu viel unübersichtlichen Code gesehen oder gar selbst produziert hast.
Als er entsteht glaube ich, weil mir die Beimischung (s.o.) von HTML-Text im PHP-Code nicht gefällt. Da habe ich es mit Dom-Funktionen versucht. Das ist dann wenigstens eine saubere Sache und hat im Grunde auch noch den Vorteil, dass der PHP-Code einem (unobstrusive) JS-Code recht ähnlich ist. Aber irgendwie bläht sich das ganze dann doch ziemlich auf.
Dabei kann man auch mit reinen PHP-Mitteln recht übersichtlich bleiben. Es gibt die Alternative syntax for control structures, die durch endxxx; mehr Zusammengehörigkeit zum jeweils öffnenden xxx zeigen kann, als das mit } der Fall ist. Und man kann sich Mühe geben bei der Formatierung des (mit PHP-Code gespickten) HTML-Templates.
Ich hatte auch schon
<?php
foreach ($data as $datum)
{
?>
<td><?php echo $datum;?></td>
<?php
}
?>
Gerade für überschaubare 1-Mann-Projekte finde ich das nicht die schlechteste Herangehensweise. Wenn das Projekt eine Aufgabenteilung zwischen Designer ohne großartige Programmierkenntnisse und dem Anwendungslogik-Programmierer vorsieht, ist es vielleicht angebrachter, ein System zu verwenden, das auch der Designer versteht, um nicht seine Vorlagen noch selbst mit der Ausgabelogik versehen zu müssen. Das bindet eigene Ressourcen und schränkt die Änderbarkeit durch den Designer ein.
um Übersichten für Lists of Hashes herzustellen. Der Framesworks hierzu scheint es ja einige zu geben, eine Art "Standard" (a la CSV für ein Tabellenformat) aber scheints nicht, oder?
Zu vielfältig sind die Anforderungen, als dass man sie mit einem System oder einem Lösungsprinzip erschlagen könnte.
Naja, ich hatte gedacht, dass man sich vielleicht auf Begrenzer für Templates "geeinigt" hätte wie beim CSV auf das Komma, die doppelten Hochkommas und den einfachen Absatz. Aber so richtig durchgesetzt hat sich da ja auch nischt. Möglich ja auch was wie <span class="placeholder">name</span>.
Das von dir Eingangs erwähnte MVC-Muster trennt auch nicht strikt Programmcode von HTML-Code, sondern überlässt es dem V(iew)-Teil, die vom M(odel) abgefragten Daten darzustellen. So erreicht man, dass sowohl M als auch V austauschbar sind, ohne dabei den jeweils anderen Teil anpassen zu müssen. Dass die View sich ihrerseits weiterer Programmiermuster (wie Templates) bedienen kann, wird durch die Verwendung von MVC nicht ausgeschlossen.
Ja, das leuchtet ein. Dieses Templatehandling ist Sache der View und berührt deshalb das übergeordnete Model nicht.
Dank und Gruß,
Struppi