Ich würde hier gerne mal eine Diskussion zu Template Engines anstrengen.

Die perfekte Template Engine, was ist das?

Für meine Begriffe soll ein solches System eigentlich nur die Applikations Logik von der Darstellung des Contents abgekoppeln. Viele Lösungen (um nicht zu sagen fast alle) besitzen eine eigene Beschreibungssprache der Templates. Meistens werden dabei Konstrukte definiert, die wie Schleifen aussehen. Smarty treibt es hier auf die Spitze, die Komplexität der Templates lässt den Gedanken an eine eigene Sprache aufkommen, oder allenfalls ein Wrapper für PHP Code.

Es stellt sich also die Frage, ob es wirklich sinnvoll ist, eine eigene Sprache zur Template Beschreibung zu definieren? Wenn man eine Template Engine hätte, an die man die Variablen schickt, die aber ansonsten in den Templates auf PHP aufsetzt, wäre das so falsch?

Vergesst nicht, es geht bei Template Engines nicht darum HTML von PHP zu trennen. Es geht lediglich darum, die Applikationslogik von der Präsentationslgik zu entkoppeln, da dadurch der Designer dann nicht mehr dem Coder ins Handwerk pfuschen kann.

Ein weiterer Aspekt einer solchen Lösung wäre natürlich die Schnelligkeit. Die Template Engine an sich dürfte kaum länger als 100 Zeilen sein. Die Verwendung von PHP führt zu keinem Zeitverlust beim Übersetzen des Templates.

Wie sieht also für euch die perfekte Engine aus?
Was spricht zum Beispiel gegen Smarty, was dafür und was für wieder andere Ansätze?

Ciao, F.o.G.

Nur kurz von meiner Seite, so etwas wie eine perfekte Engine
gibt es wahrscheinlich nie. Ich denke du kannst hoechstens
versuchen die beste Mischung aus Vielfaeltigkeit und Geschwindigkeit
zu erreichen und das beste hoffen

Meine Idee war zusaetzliche Funktionen/Klassen einfach wie normale
Tags aussehen zu lassen um somit den Designern keine zu grossen
Umstaende zu machen.

z.B. <class name="" parameter=""> <method name=""><parameter=""></method></class>

Jona

P.S. wer sich ueber die "ue,ae,oe"s wundert, keine deutsche Tastatur
zur Hand gehabt.

Ein Satz spricht gegen Smartys:

keep it stupid simple

Danach sollte sich eine Template Engine richten. Denn wenn ich mich erst ewig
in ein Template Framework einarbeiten muss um $ZIEL zu erreichen, habe ich
ein Problem.

Ich erwarte von einem guten Template Framework, das so logisch aufgebaut ist
und logisch nutzbar ist, das ich ohne Erfahrungen damit haben zu müssen
gute Ergebnisse erzielbar sind.
Anweisungen in eine Template Engine zu stecken halte ich für den falschen weg.
Da ist es schlauer lieber gleich auf XML mit XSLT zu bauen.

@Nils

Meine Idee war zusaetzliche Funktionen/Klassen einfach wie normale

Das könnte dann aber keine allgemeine Template Engine sein, sondern etwas, das in einem bestimmten Projekt nur funktioniert, beispielsweise bei einem CMS das Auslesen und Darstellen eines Beitrags. Oder versteh ich dich falsch?

@Christian:
Hmm, Einfachheit ja, da stimm ich mit dir überein. Das Problem ist aber die Idee. Eine Template Engine muss ja zwangsläufig eine eigene Syntax mitbringen oder sie baut auf PHP auf.

Mir gehts vor allem darum, welche Konstrukte eine Template Engine braucht. Blöcke zum Beispiel (eigentlich ist das eine Art Schleife). Aber Einfachheit ist tatsächlich das wichtigste. Wir hatten bei unserem CMS patTemplate eingesetzt, aber obwohl das auf einer XML Syntax basierte war es immer noch zu kompliziert. Das ist also die Frage: Was braucht eine Template Engine und wie kann man solche Konstrukte am einfachsten realisieren, bzw so realisieren dass sie einfach zu handhaben sind?

Ciao, F.o.G.

Original geschrieben von F.o.G.

@Christian:
Hmm, Einfachheit ja, da stimm ich mit dir überein. Das Problem ist aber die Idee. Eine Template Engine muss ja zwangsläufig eine eigene Syntax mitbringen oder sie baut auf PHP auf.

Nö genau das Brauch es nicht. Bloss keine eigene Syntax.

Templates sollen letztendlich HTML Anzeigen, geladen und ausgegeben werden. Alles andere, auch die Iterationen gehört in ein gutes Code Design versteckt.

Falls ich sehr viel mehr brauch, nehm ich eines der kostenlos erhaeltlichen Frameworks
wie struts oder aehnliches.
Dann ist die Webanwendung von einer groesse das PHP so oder so eine schlechte Wahl ist

Also ich kenne eine Seite auf der der Programmierer einen Vergleich machte zwischen Smarty und einer von Ihm ( nicht allzu kompleziert ) geschriebenen Template Klasse.

Er bezog sich darauf, das PHP an sich eigentlich eine Templatesprache ist. Und das man mit der template Klasse (
die weiter unten zu sehen,
sehr leicht verständlich,
übersichtlich und vorallem sehr leicht erweiterbar ist.
)

, ohne jede Mühe und viel simpler als mit Smarty, seine Idee in die Tat umsetzen kann. Man konnte ganz normal die PHP Vars im gesamten Bereich nutzen. Um Funktionen einzubinden oder auch selbst ausgedachte Codeschnipsel irgendwo zu platzieren. Anstatt des Smarty üblichen { blabla } fungierte <?=$template[$xyz][$soundso]?>.

ein kurzes Beispiel:

Um z.B. dynamische Inhalte zu generieren wird dann eine for Schleife genutzt. Kann mich nicht mehr genau erinnern, etwa so:

// das Template
<HEAD>
<TITLE><?=$template[$xyz][$header]?></TITLE>
</HEAD>
......................
..>
<TR>
<TD WIDTH="250" CLASS="blabla">
<TABLE WIDTH="90%" "und so weiter">
<?
for ($i=1;$i<$x;$x++)
{
echo "<TR><TD>" . $template[$x][$nav_left] . "</TD></TR>";
}
?>
</TABLE>

<...

... Ich werd jetz mal suchen, ob ich diesen Artikel wiederfinde ( leider url verschlampt ). Denn das ist wirklich genial und ich verstehe auch überhaupt nicht wieso es so kompliziert sein muss, das man als Amateur gleich mehrere 100 seiten Smarty Docu input braucht, um wirklich damit umgehen zu können. Ich habe 2 mal "auf die Schnelle" versucht smarty zu installieren und sinnvoll einzusetzen, ohne erfolg...

Für die PHP Version sind nichtmal 10 draufgegangen bis alles funktioniert hat. Nochdazu konnte ich sofort damit umgehen wegen der $gleichen $art[und][$weise].

Erweiterungen werden im Ordner PlugIns einfach eingebunden und stehen Projektweit zur Verfügung.

Das ganze tutorial benötigt ca zwei DinA4 Seiten platz bei einer Auflösung von 1024x768...

habs gefunden... wenn ich irgendwas falsches daherbringe, korrigiert mich!

ich zitiere::::

Ich habe längere Zeit Smarty extensiv genutzt und dachte tatsächlich immer,
dass Smarty wirklich unglaublich toll und praktisch ist. Nachdem ich dann
mal etwas nachgedacht habe, erkannte ich plötzlich, dass Smarty und andere
Static-Template-Engines für so ziemlich alle Zwecke, was PHP anbelangt, im
Grunde genommen vollkommener Blödsinn sind.

Und zwar deswegen, weil PHP selbst schon eine Template-Sprache ist,
zumindest war PHP dies am Anfang ausschließlich. Jetzt ist zwar jede Menge
Funktionalität hinzugekommen, aber die Eigenschaft, auch eine
Template-Sprache zu sein, hat PHP ja immer noch.

Ein Beispiel:

=== Static Template Engine Code ===
$tpl = new Smarty;
$tpl->assign('title', 'Titel');
$tpl->assign('heading', 'Important Heading');
$tpl->assign('data_array', $db_data_array);
$tpl->display('template.tpl');

=== Static Template ===
<html>
<head>
<title>{$title}</title>
</head>
<body>
<h1>{$heading}</h1>
<table>
{section name="x" loop=$data_arr}
<tr>
<td>{$data_arr[x].id}</td>
<td>{$data_arr[x].name}</td>
</tr>
{/section}
</table>
</body>
</html>


=== PHP Code ===
$title = 'Titel';
$heading = 'Important Heading';
$data_array = $db_data_array;
include('template.php');

=== PHP Template ===
<html>
<head>
<title><?=$title?></title>
</head>
<body>
<h1><?=$heading?></h1>
<table>
<? for($x=0; $x<count($data_array); $x++): ?>
<tr>
<td><?=$data_arr[$x]['id']?></td>
<td><?=$data_arr[$x]['name']?></td>
</tr>
<? endfor; ?>
</table>
</body>
</html>

Das Ergebnis ist dasselbe und in letzterem Fall hast Du zusätzlich noch die
Möglichkeit, auf alle PHP-Funktionen zurückzugreifen. Abgesehen davon, dass
der Code um ein Vielfaches schneller ist. Wichtig ist nur das Prinzip, erst
alle Daten (bei Datensätzen in Form von Arrays) zuzuweisen und dann erst das
Template in's Spiel zu bringen.

Hilfreich ist auch die Syntax:
if(): (elseif: else endif;
for(): endfor;
foreach(): endforeach;
etc...
wie sie auch Smarty verwendet.

Ich hab' das für mich mittels folgender Klasse gelöst, die im Prinzip so gut
wie alles bietet, was Smarty kann, inkl. Erweiterungsmöglichkeit, dabei aber
überaus simpel ist.

Benutzung ist dieselbe wie bei Smarty.

$tpl = &new TemplateEngine;
$tpl->assign('title', 'Titel');
$tpl->assign('heading', 'Important Heading');
$tpl->assign('data_array', $db_data_array);
$tpl->display('template.php');

im Template selber hast Du dann alle zugewiesenen Werte im $TPL-Array zu
Verfügung. bei oberen Beispiel sähe das dann so aus:

=== PHP Template ===
<html>
<head>
<title><?=$TPL['title']?></title>
</head>
<body>
<h1><?=$TPL['heading']?></h1>
<table>
<? for($x=0; $x<count($TPL['data_array']); $x++): ?>
<tr>
<td><?=$TPL['data_array'][$x]['id']?></td>
<td><?=$TPL['data_array'][$x]['name']?></td>
</tr>
<? endfor; ?>
</table>
</body>
</html>

Im Template selber hast Du dann natürlich auch die Möglichkeit andere
Templates zu includen.

Das geht dann als Beispiel so:

<? include($this->TEMPLATE_DIR . 'header.tpl.php'); ?>

Erweiterungen kann man dann selbst schreiben und im template_plugins-Ordner
unter "Name_der_Funktion.php" ablegen.

Aufgerufen wird dann im Template so:

<?=$this->tpl_func('phpmysql_func', $var1, $var2, $etc)?>

Wenn Du Dir die folgende Klasse anschaust, wirst Du sicherlich verstehen,
wie sie funktioniert. Anpassungen natürlich möglich.

Ich finde, sie ist der perfekte Smarty-Ersatz und besser als jede andere
Template-Engine.

class TemplateEngine
{
var $TEMPLATE_DIR = '/your/path/to/templates/';

var $PLUGIN_DIR = '/template_plugins/';

var $TEMPLATE_VARS = array();

function MyTemplateEngine()
{
// do something? :o)
}

function setTemplateDir($tpl_dir)
{
if(!is_dir($tpl_dir)) {
exit('invalid template path');
}

$this->TEMPLATE_DIR = $tpl_dir;
}

function assign($key, $val=null)
{
$this->TEMPLATE_VARS[$key] = $val;
}

function display($tpl_file)
{
if(!is_file($this->TEMPLATE_DIR . $tpl_file)) {
exit('no such template file: ' . $tpl_file);
}

$TPL = &$this->TEMPLATE_VARS;

include($this->TEMPLATE_DIR . $tpl_file);
}

function tpl_func($func_name)
{
$func_file =
dirname(__FILE__) . $this->PLUGIN_DIR . $func_name . '.php';

if(!is_file($func_file)) {
exit('no such function: ' . $func_name);
}

include_once($func_file);

$code = "return $func_name(";
if(func_num_args() > 1) {
$args = array_slice(func_get_args(), 1);
for($x=0; $x<count($args); $x++) {
if($x>0) $code .= ',';
$code .= '$args[' . $x . ']';
}
}
$code .= ");";

return eval($code);
}
}


und hier noch den Link dazu: PHP Template Engine selbst gemacht

ich finds genial, denn nun thema Template bei mir auch ohne smarty und co und nochdazu hab ich dazugelernt ...

Meine Template Engine ist etwas simpler. Sie wandelt die Template Dateien einen echo Befehl oder einen Ausdruck um.
Die eingesetzten Variablen müssen lokal zur Verfügung stehen. Somit ist bei MySQL Abfragen meistens mit diesem Code getan:

Code :

1 2 3 4

while($entry=mysql_fetch_object($result))     {     eval(tmp("meinTemplate"));     }

Das Template:

Code :

1 2 3 4 5

<div class="entry"> <b>{$entry->title}</b><br /> Geschrieben von {getUserName($entry->owner)} am {DateTime($entry->time)}<br /><br /> {toHtml($entry->text)}</div>

In den geschweiften Klammern stehen beliebige PHP-Ausdrücke. Die Engine ist auch nicht unbedingt an diese eckigen Klammern gebunden. Für CSS-Templates verwende ich z.B. <? und ?>, weil die Klammern reserviert sind. Man kann damit auch Templates "includen":

Code :

1 2	<b>Master Template: {$name}</b> <br />{tmp("SubTemplate",0)}

Ich habe noch nie mehr benötigt. Wozu Iterationen in einem Template?

ch habe noch nie mehr benötigt. Wozu Iterationen in einem Template?

Für nen Array vielleicht?

@Agroman schöne Ausführung.

Das einzige wann ich wieso Smarty benütze ist die, dass jemand aussenstehndes nur den reinen HTML-Code sehen soll und die Variablen einfach und verständlich einsetzten kann. Da is es schon ein Unterschied ob er nunr {$Datum} oder <? echo $Datum; ?> schreibt. (Und kommt mir bitte jetzt nicht mit dieser Kurzschreibweise. Davon halte ich nun absolut garnichts.

Allerdings wird in diesem Vergleich zwischen Smarty und "PHP" vergessen, dass je nach Anwednungsfall das Caching recht viel Zeit beim parsen sparen kann....

und beim Rest stimme ich sicaine zu, auch was die Iteration angeht.

Nur um mal kurz was einzuwerfen:

Meines Erachtens wird der Begriff des Templates oft missbraucht, beziehungsweise der eigentliche Sinn dahinter verschwimmt.

Der Sinn von Templates liegt meines Erachtens in der Trennung von Anwendungslogik und Layoutlogik. Viele Engines gehen aber den Weg, dass sie das mit der Trennung von $programmiersprache und $layoutsprache gleichsetzen, was meines Erachtens das ganze einfach nicht wirklich trifft, da dies nichts mit dem Trennen der Logiken zu tun hat.

Das war der Einwurf/Denkanstoß, mal sehen was noch so kommt.

mit grossem interesse hab ich eure diskussion gelesen. ich selbst hab ein eigenes php basiertes cms programmiert, welches frame oder nonframe basierte auftritte modular aufbauen kann.

meine erfahrungen der letzten 6 jahre in diesem bereich gehen dahin, dass für den "endkunden" das system letztlich unerheblich ist welches zum einsatz kommt. sicher spielen performance faktoren eine rolle, aber ich meine von der technischen sicht aus.
was bleibt sind die anforderungen der personen die den auftritt realisieren bzw. pflegen und verschiedene kriterien anlegen:

1. falls der "endkunde" am design selbst eine änderung durchführen will muss dies möglichst einfach möglich sein
2. eine trennung von template dateien (in welchem format auch immer) und php script dateien muss schon wegen dem möglichen einsatz vom php optimizer möglich sein
3. falls der "entwickler" und "webdesigner" zwei unterschiedliche personen sind muss die template engine diese "teilung" mitmachen
4. das ganze muss unkompliziert sein um auch nach einigen wochen/monaten/jahren änderungen machen zu können ohne docu studieren zu müssen. das ist auch bei wechselnden zuständigkeiten hilfreich.

um es mal etwas analytischer anzugehen gibt es innerhalb eines webauftritts bestimmte, gleichbleibende bereiche, die immer wieder vorkommen. innerhalb dieser "bereiche" gibt es dann zumeist grosse unterschiede in der art und weise der darstellung. diese unterschiede lassen sich nicht immer alleine durch den einsatz von css lösen (man denke z.b. an eine spezielle navigationsart die wiederum vom design her abgeleitet wird).

aus meiner erfahrung heraus teile ich einen webauftritt in folgende bereiche auf:
1. navigation
2. content
3. teasing
4. sidebar
5. footer

zu 1: die navigation kann von projekt zu projekt sehr unterschiedlich sein. der eine will ein pulldown menu, der andere aufklappende menüpunkte. anforderungen wie "muss auch ohne javascript funktionieren" sind da natürlich auch eingeschlossen. aber auch der einsatz von flash elementen in der navigation muss in betracht gezogen werden können.

zu 2: der inhalt besteht aus texten und bildern, tabellen und sog. bausteinen die je nach projektumfang innerhalb des "contents" verwendet werden sollen.

zu 3: teasing mein elemente die aufgrund des webdesigns eingeführt werden sollen. so soll z.b. pro menüpunkt eine andere grafik eingeblendet werden.

zu 4: mit side meine ich den bereich der auf auftritten mit sehr dynamischen komponenten oder einem "benutzerbereich" informationen einbaut. das können streifen links oder recht vom "content" sein die je nach menüpunkt auch noch unterschiedlich aufgebaut sind. manchmal will der "endkunde" auch einfluss auf die positionierung der dynamischen elemente innerhalb des "sidebar"-bereiches haben (z.b. zuerst die news und dann den veranstaltungskalender usw.).

zu 5: zwar ist die fusszeile zumeist kein grosses thema, aber ich hatte auch schon projekte bei denen ich dankbar war auch diesen bereich noch den anderen gleichgestellt zu haben.

es ist klar das nicht immer alle webprojekte alle diese bereiche benötigen, aber ich sag mal im schnitt kommt es doch sehr häufig vor das es diese braucht. sicher gibt es projekte die noch viel mehr benötigen, aber diese komplexität staffelt sich dann innerhalb eines dieser benannten bereiche.

aus dieser analytischen sicht kann man nun eine lösung für das "parser" problem ableiten. die template engine meines cms z.b. teilt diese aufgabe auf. zwar wird die gesamte site durch einen parser gejagt, der wiederrum führt an den benannten bereichen sozusagen "subparser" aus die bestimmen wie sich der inhalt aufbaut. so ist es z.b. möglich auch komplexe anforderungen zu modularisieren - will heissen in applikationslogik und html bestandteile aufzuteilen.

zur performance: meine feststellung ist, dass auftritt mit viel traffik so oder so irgendwann auf caching umsteigen müssen. somit stellt sich die frage nach der "ausgangsgeschwindigkeit" nicht mehr unbedingt. selbst wenn der neuaufbau durch die php enginge ein paar millisekunden länger braucht macht das im schnitt den breit auch nicht mehr fett wenn dahinter dann gecached ausgeliefert wird.
grosse performancegewinne bzw. verluste erhält derjenige der datenbank-abfragen nicht konsolidiert behandelt und sich nicht mit den eigenheiten von SQL befasst. da steckt eine menge an optimierungspotential drin durch die man sich php code sparen kann.

sicher ist auch meine lösung nicht der letzte schluss, aber ich kann sagen das ich bislang kein projekt hatte das nicht so zu realisieren war. und dabei spielt es, wie bereits anfangs gesagt, letztlich keine rolle wie man es technisch nun anstellt - ob man nun {geschweifte} elemente ins template einsetzt oder <?php code ?> direkt platziert. entscheident ist nur ob man dem kunden zugang zu dieser informationen gewähren will oder nicht und in wie weit fehler entstehen könnten wenn der kunde etwas falsch macht.

zur sicherheit: ein ganz entscheidender faktor ist meiner erfahrung nach, dass man dem "endkunden" und "designer" möglichst keine "programmiersprache" zur verfügung stellt mit der er einfluss auf die applikationslogik hat. das kann dann ein böses erwachen werden wenn da sicherheitslöcher bekannt werden. auch hier muss ich sagen, dass php oder auch andere scriptsprachen wie z.b. perl sich da nicht gross unterscheiden. wenns "" programmiert wurde bringts die sprache dahinter auch nicht mehr.

mehr informationen zu meinem bescheidenen cms gibts unter static2dynamic.de