Trennung von Logik und Darstellung

[asdf]

Seufz,

ich weiss nicht warum sich das Gerücht, HTML und PHP Code trennen zu müssen, so hartnäckig hält. Es geht darum Applikationslogik von Darstellungslogik zu trennen.

Eine extra Templatesprache einzuführen, kommt eigentlich nur dann in Frage, wenn man die Templates vom Benutzer verwalten lassen will, so dass dieser keinen Unfug anstellen kann. Ansonsten ist es PHP -> Template (z.b. Smarty) -> PHP. Diesen sinnfreien Performanceschwund kann man sich auch einfach sparen.

Ein ziemlich einfacher Ansatz ist PHP selbst. PHP ist nichts weiter als eine poplige Templatesprache.

  
class Template  
{  
  public static function render($file, $args, $type = 'html')  
  {  
    $$args = $args;  
    extract($args);  
    include $file.'.'.$type.'.php';  
  }  
}  
  
// file test.html.php  
<h1>Hallo <?php echo $name ?></h1>  
<?php foreach($arr as $i): ?>  
<p><?php echo $i ?></p>  
<?php endforeach; ?>  
  
// irgendwo  
Template::render('test', array  
(  
  'name' => 'asdf',  
  'arr'  => array(1, 2, 3)  
));  
  

je nachdem, ob man vielleicht json o.ä. ausgeben möchte, könnte man den template typ ändern.

  
// irgendwo  
Template::render('test', array  
(  
  'name' => 'asdf',  
  'arr'  => array(1, 2, 3)  
), 'json');  
  
// test.json.php  
<?php echo json_encode($args); ?>  

Ich wüsste sonst kaum einen Grund, was den Einsatz einer billigen Templatesprache wie Smarty rechtfertigt.

Auch XLST funktioniert meines Erachtens ähnlich, aber hier werden die Anweisungen halt in der XLSTeigenen Sprache notiert. Die aber in anderen Sprachen besser unterstützt sein sollte, als der native HTMLPHP Mix. Ich würde es nutzen, wenn die Daten sowieso schon in XML vorliegen ("... used for the transformation of XML documents into other XML documents.").

Ich würde eher viel Wert auf Caching legen. Dann kann man sich auch eine schwachbrüstige Templateengine leisten.

Tschö