Tweet
Tja, ich verwende Smarty mit ein paar selbst geschriebenen Erweiterungen. Das ist ein guter Kompromiss.
Smarty erlaubt in den Templates gerade soviel Logik wie nötig und so wenig wie möglich. Das ist genau mein Ding
Das ist aber alles Ansichtssache. An der Uni hatten wir mal einen Spezi, der den Output von PHP Seiten mit XSLT erstellt hat. Weil's "modern" wäre. Diese "Webseiten" haben nicht lange überlebt - der nach ihm kommende Hiwi konnte nämlich damit nicht umgehen. Deshalb wurde alles wieder eingestampft.
Dann gibt's die Leute, welche gar keine Skins/Templates schreiben sondern in XML die Struktur der Datenbank beschreiben und sich alle Formulare automatisch erzeugen lassen. Nicht sehr hübsch, aber übersichtlich und für manche Anwendungen reicht das schon.
Ich kenne jemand, der hat ein umfangreiches OO PHP-Skript zu betreuen, welches Smarty verwendet... nicht das es etwas genützt hätte. Er weigert sich konsequent Smarty zu benutzen, weil er angeblich mit diesen Templates nichts zu tun hätte. Stattdessen erzeugt seine Template Engine nichts als eine leere HTML-Datei und alles was zwischen dem öffnenden und schliessenden Body-Tag steht, wird in seinem PHP-Code erzeugt, wo es seiner Meinung nach "schliesslich auch vom Sinn her hin gehört, weil ja dort auch der passende Code steht".
Für jemanden wie mich, dessen Herz an einer sauberen 3-Schichten-Architektur, Trennung von Business Logic, Daten und Layout, sowie an der OO Programmierung hängt, ist das natürlich ein Graus. Aber für Leute die in der prozeduralen Programmierung zuhause sind und die grundsätzlich in Prozessen und Modulen denken ist das eine logische Entscheidung.
Es kommt also immer auf den jeweiligen Standpunkt an. Deshalb wird es wohl niemals eine optimale Lösung geben, mit der man jeden zufrieden stellen kann.
Smarty erlaubt in den Templates gerade soviel Logik wie nötig und so wenig wie möglich. Das ist genau mein Ding
Das ist aber alles Ansichtssache. An der Uni hatten wir mal einen Spezi, der den Output von PHP Seiten mit XSLT erstellt hat. Weil's "modern" wäre. Diese "Webseiten" haben nicht lange überlebt - der nach ihm kommende Hiwi konnte nämlich damit nicht umgehen. Deshalb wurde alles wieder eingestampft.
Dann gibt's die Leute, welche gar keine Skins/Templates schreiben sondern in XML die Struktur der Datenbank beschreiben und sich alle Formulare automatisch erzeugen lassen. Nicht sehr hübsch, aber übersichtlich und für manche Anwendungen reicht das schon.
Ich kenne jemand, der hat ein umfangreiches OO PHP-Skript zu betreuen, welches Smarty verwendet... nicht das es etwas genützt hätte. Er weigert sich konsequent Smarty zu benutzen, weil er angeblich mit diesen Templates nichts zu tun hätte. Stattdessen erzeugt seine Template Engine nichts als eine leere HTML-Datei und alles was zwischen dem öffnenden und schliessenden Body-Tag steht, wird in seinem PHP-Code erzeugt, wo es seiner Meinung nach "schliesslich auch vom Sinn her hin gehört, weil ja dort auch der passende Code steht".
Für jemanden wie mich, dessen Herz an einer sauberen 3-Schichten-Architektur, Trennung von Business Logic, Daten und Layout, sowie an der OO Programmierung hängt, ist das natürlich ein Graus. Aber für Leute die in der prozeduralen Programmierung zuhause sind und die grundsätzlich in Prozessen und Modulen denken ist das eine logische Entscheidung.
Es kommt also immer auf den jeweiligen Standpunkt an. Deshalb wird es wohl niemals eine optimale Lösung geben, mit der man jeden zufrieden stellen kann.
)
Kommentar