Trennung von Logik und (HTML-)Template

[Tom]

Hello,

ich denke nun schon länger darüber nach, wie man am besten die HTML-Templates und die PHP-Logik für die Datenaufbereitung einerseits voneinander getrennt halten kann und andererseits aufeinander abstimmen kann.

Das bereitet bei festgelegten Ergebnismengen und keine Probleme. Dann ist ein statisches, passives Template möglich, dessen Daten von PHP einfach an Platzhalterstelle eingestanzt werden. Interessant wird es aber immer dann, wenn Listen oder sonstige x-mal wiederholte Ergebnisdarstellungen ins Spiel kommen. Wie macht man es am geschicktesten, dass dann auch HTML (stellvertretend für die Darstellungssprache) und PHP so getrennt wie möglich bleiben?

Ich stelle mir dabei vor, dass es mit den wenigsten Handgriffen (Konfigurationsänderungen) möglich sein soll, z.B. von HTML auf FOO-ML umzustellen, also die Darstellungssprache zu wechseln.

Man könnte jetzt für alle Wiederholelemente (Tabellenzeilen, Tabellenzellen, Listen, Selects, usw.) "Übersetzungsmodulchen" vorschreiben, aber wer garantiert denn, dass FOO-ML dann genau die gleichen Elemente zur Verfügung stellt; dann würde sie sich ja von HTML nicht großartig unterscheiden.

Es geht mir also um eine eher theoretische Diskussion. Fragen, wie "wofür willst Du das haben?" oder "was hast Du denn schon? Zeig mal" würde ich als eher verblödet empfinden [auch, wenn sie wahrscheinlich gerade JETZT erst recht kommen. Ich kenn Euch doch :-) ].

Hat sich denn von Euch darüber schon mal jemand Gedanken gemacht?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Steel]

Hi!

Das ist ein Thema, mit dem ich mich gerade beschaeftige. Ich bin auf CMS Suche und dort stolpert man immer wieder ueber XSLT.

[suit]

Hat sich denn von Euch darüber schon mal jemand Gedanken gemacht?

Guck dir Smarty an - die haben sich schon darüber gedanken gemacht und ermöglichen eine recht saubere Trennung von PHP- und HTML-Code.

[Phil]

Hallo Tom.

Du könntest dir auch einfach klitze kleines MVC-Framework basteln.

Einfachen Dispatcher den du auf den URL-Aufbau abstimmmst. www.example.com/Klassen/Methode/Parameter1/Parameter2/Parameter3...

OrdnerStruktur: Models, Views, Controllers
Und so hast du nicht nur Logik von Ausgabe getrennt sonder. Datenbank von Logik von Ausgabe.

;)

Grüße, Phil

[Tom]

Hello Phil,

Du könntest dir auch einfach klitze kleines MVC-Framework basteln.

Genau, darum eht es. :-)

Einfachen Dispatcher den du auf den URL-Aufbau abstimmmst. www.example.com/Klassen/Methode/Parameter1/Parameter2/Parameter3...

Das gehört in die Steuerung

OrdnerStruktur: Models, Views, Controllers

Und wie man die Views, bzw. daraus die Darstellungsfestlegungen so passiv wie möglich halten kann, das ist jetzt die Frage. Es sollen nachher Templates dabei herauskommen, die keinerlei Einfluss auf die Steuerung haben können, selbst, wenn man darin herumbastelt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[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ö