+ (PHP) Template-Parser/ -Engine und MVC

[Gunther]

Hallo Selfgemeinde!

Ich grübele immer noch an der Planung meines eigenen kleinen CMS. Da ich ja auch etwas lernen will und meine Fähigkeiten erweitern möchte, habe ich mich jetzt schon geraume Zeit mit dem MVC Muster beschäftigt und mir u.a. auch mal die diversen Template-Engines (in PHP) angeguckt.

Aber scheinbar habe ich damit ein gewisses Verständnisproblem und wäre für entsprechende Hilfe/ Aufklärung dankbar!

Annahme:
Ich habe jetzt verschiedene kleine einzel Templates, die je nach Bedarf in ein großes (Seiten-)Template inkludiert werden sollen, oder auch direkt ein großes (Seiten-)Template, welches mit den unterschiedlichsten Daten (die bspw. aus einer MySQL DB kommen) befüllt werden soll.

Fragen:
Alle Template-Engines/ -Parser (Klassen) die ich mir angeguckt habe, setzen alle voraus, dass die jeweiligen Werte für die Ein-/Ersetzung im jeweiligen Template in irgendeiner Form bereits vorhanden sind. Das ist ja auch durchaus logisch und leuchtet (selbst) mir ein.

• Die Frage, die sich mir dabei aber stellt ist, woher weiß ich (genauer: das Script), welche Daten denn nun genau benötigt werden? Es macht ja keinen Sinn, einfach immer alle Daten bereitzustellen/ -halten, wenn nur ein Bruchteil davon benötigt wird.

• Muss ich dafür dann diese Informationen wiederum separat irgendwo vorhalten und pflegen, oder gibt es "elegantere" Lösungen?

• Mir wäre ja eine "automatisierte" Lösung, die erst das/ die jeweilige(n) Template(s) "analysiert", und dann aufgrund der erforderlichen Werte quasi selbstständig die nötigen "Module" zur Bereitstellung der erforderlichen Daten inkludiert/ ausführt lieber. Wie setzt man so etwas prinzipiell am besten/ einfachsten um, bzw. gibt es das irgendwo schon fertig?

Bitte keine Hin- oder Verweise auf Smarty & Co. Mit solchen "Monstern" mit eigener Syntax möchte ich mich nicht beschäftigen, da sie für meine Zwecke auch der totale Overkill wären. Reines PHP (5 als OOP) wäre mir am liebsten.

Für Tipps, Hinweise und Ratschläge meinen besten Dank im Voraus.

Gruß Gunther

[dedlfix]

Hi!

Alle Template-Engines/ -Parser (Klassen) die ich mir angeguckt habe, setzen alle voraus, dass die jeweiligen Werte für die Ein-/Ersetzung im jeweiligen Template in irgendeiner Form bereits vorhanden sind. Das ist ja auch durchaus logisch und leuchtet (selbst) mir ein.

Das Template-System hat zur Aufgabe, Daten in eine Ausgabeform zu bringen. Seine Aufgabe ist in aller Regel weder, diese Daten zu beschaffen, noch diese Beschaffung anzuregen.

• Die Frage, die sich mir dabei aber stellt ist, woher weiß ich (genauer: das Script), welche Daten denn nun genau benötigt werden? Es macht ja keinen Sinn, einfach immer alle Daten bereitzustellen/ -halten, wenn nur ein Bruchteil davon benötigt wird.

Das ist im MVC-Muster Aufgabe des Controllers. Der holt die Daten aus dem Model, wobei er selbst weiß, welches Model dazu wie zu melken ist. Und er übergibt sie dem Template-System, wobei er dazu weiß oder ermittelt, welches Template genau zur Ausgabe verwendet werden soll. Im Falle eines Fehlers könnte beispielsweise ein anderes Template enommen werden als im Gut-Fall. Jedes Template universell zu gestalten, dass es sowohl Gut- und Fehlerfall abdeckt werden, oder dass die Template-Engine selbst entscheidet ein passendes Teil-Template nachzuladen, halte ich konzeptionell nicht für besonders gut gelöst.

• Muss ich dafür dann diese Informationen wiederum separat irgendwo vorhalten und pflegen, oder gibt es "elegantere" Lösungen?

Es gibt mehrere Möglichkeiten. Eine wäre, dass jeder spezielle Action-Controller weiß, was anzusprechen ist, wozu die Daten im Action-Controller hart zu kodieren wären. Das mag je nach Anforderungen ungünstig sein, weil immer Quelltext beim Umkonfigurieren zu ändern ist. Eine andere Möglichkeit wäre deshalb, diese Daten in einem Konfigurationssystem abzulegen.

• Mir wäre ja eine "automatisierte" Lösung, die erst das/ die jeweilige(n) Template(s) "analysiert", und dann aufgrund der erforderlichen Werte quasi selbstständig die nötigen "Module" zur Bereitstellung der erforderlichen Daten inkludiert/ ausführt lieber. Wie setzt man so etwas prinzipiell am besten/ einfachsten um, bzw. gibt es das irgendwo schon fertig?

Der Action-Controller ist der Chef. Er frag praktischerweise nicht erst das Template, was es gern hätte, sondern weiß, was das Template kann. Er frag auch nicht die Models durch, was sie zu liefern in der Lage sind, sondern verlangt gleich vom passenden die Daten.

Lo!

[Gunther]

Hi dedlfix!

Vielen Dank für deine Antwort.
Jetzt ist mir auch endlich (endgültig) klar geworden, was mich bis dato immer (leicht) irritiert hat. ;-)

• Die Frage, die sich mir dabei aber stellt ist, woher weiß ich (genauer: das Script), welche Daten denn nun genau benötigt werden? Es macht ja keinen Sinn, einfach immer alle Daten bereitzustellen/ -halten, wenn nur ein Bruchteil davon benötigt wird.

Das ist im MVC-Muster Aufgabe des Controllers. Der holt die Daten aus dem Model, wobei er selbst weiß, welches Model dazu wie zu melken ist. Und er übergibt sie dem Template-System, wobei er dazu weiß oder ermittelt, welches Template genau zur Ausgabe verwendet werden soll.

Ich habe das ganze System immer mehr von der Seite der Templates aus betrachtet, weil diese ja schließlich und endlich das entscheidende Glied in der Kette sind, welches für die Darstellung/ Ausgabe zuständig ist. Bei der Planung erscheint es mir zumindest auch intuitiver, die möglichen Templates zu planen/ kreieren, als die verschiedenen Action-Controller zu konzipieren.

• Muss ich dafür dann diese Informationen wiederum separat irgendwo vorhalten und pflegen, oder gibt es "elegantere" Lösungen?

Es gibt mehrere Möglichkeiten. Eine andere Möglichkeit wäre deshalb, diese Daten in einem Konfigurationssystem abzulegen.

Ja, aber ...!
Schränkt nicht genau diese Variante die Flexibilität enorm ein, bzw. erhöht den Administrationsaufwand?

Wenn man es so herum macht, dann muss ich ja für jeden "Ausgabezweck" irgendwo definieren
a) welche(s) Template(s) benötigt wird und
b) zusätzlich noch definieren, welche Action-Controller dafür von Nöten sind, um alle erforderlichen Daten aus dem Model dafür bereitzustellen
richtig?

Und das jedes Mal ggf. beides pflegen, wenn sich das Template als solches, oder im Template etwas ändert?

• Mir wäre ja eine "automatisierte" Lösung, die erst das/ die jeweilige(n) Template(s) "analysiert", und dann aufgrund der erforderlichen Werte quasi selbstständig die nötigen "Module" zur Bereitstellung der erforderlichen Daten inkludiert/ ausführt lieber. Wie setzt man so etwas prinzipiell am besten/ einfachsten um, bzw. gibt es das irgendwo schon fertig?

Der Action-Controller ist der Chef. Er frag praktischerweise nicht erst das Template, was es gern hätte, sondern weiß, was das Template kann.

Was hieltest du denn von der Variante, diese Informationen jeweils in jedem Template mit zu speichern?

Beispiel:
Ich dachte mir das Ganze eher in vielen kleinen Einzel-Templates (mit jeweils zugehörigem Action-Controller zur Beschaffung der benötigten Daten), die sich dann im Baukasten-Prinzip zusammenstellen lassen.
Also bspw. ein Template mit Controller für die Breadcrumb-Navigation, eines für das Menü, eines für Kommentare zu einem Artikel, etc. Diese Einzel-Templates lassen sich dann nach Belieben in das Gesamt-Seiten Template integrieren (und zwar ohne irgendwelchen zusätzlichen Administrationsaufwand, bzw. Änderungen in irgendwelchen Konfigurationseinstellungen/ -dateien).

Wäre das (deiner Meinung nach) eine praktikable Lösung (auch wenn sie vielleicht nicht 100%ig dem MVC-Modell entspricht)?

Der Entwicklungsschwerpunkt soll ja eindeutig auf größtmöglicher Flexibilität bei gleichzeitig möglichst niedrigem Pflege- und Administrationsaufwand liegen.

Gruß Gunther

[dedlfix]

Hi!

Ich habe das ganze System immer mehr von der Seite der Templates aus betrachtet, weil diese ja schließlich und endlich das entscheidende Glied in der Kette sind, welches für die Darstellung/ Ausgabe zuständig ist. Bei der Planung erscheint es mir zumindest auch intuitiver, die möglichen Templates zu planen/ kreieren, als die verschiedenen Action-Controller zu konzipieren.

Du schaust dir die Geschichte von außen an. Ich gehe da lieber der Reihenfolge nach. Da wäre als erstes ein Request. Ohne den, nützt dir das beste Template nichts. Vom MVC ausgehend startet der Request ja nicht gleich ein Template, sondern er landet typischerweise beim Front-Controller, der außer grundlegenden Initialisierungen zu einem bestimmten ActionController routet. Dieser Action-Controller erledigt (oder überwacht zumindest) die eigentliche Aufgabe, die im Hintergrund stattfindet, die Business-Logic (meist Speichern oder Abfragen von Daten). Daraus ergibt sich dann eine Ausgabe.

In deinem Fall scheint mir es so zu sein, dass neben der Hauptausgabe eine Menge "Nebensächlichkeiten" in der Ausgabe zu finden sein sollen. "Oberflächlich" betrachtet werden das mehr oder weniger Kästen sein, die verschiedenen Zwecken dienen: Navigation, Login-Bereich, Werbung, News-Ticker und so weiter. Diese willst du anzunehmenderweise mit den Einzel-Templates abdecken. Es ist nun aber nicht so, dass sich ein Action-Controller um alles kümmern muss. Besser ist es dann, die Teilaufgaben auf einzelne Controller zu verteilen, was dann je Ausgabemodul eine eigene Kombination aus M, V und C ergibt. Es muss dann natürlich einen Koordinator geben, der die einzelnen Action-Controller der benötigten Module abgrast und deren Ergebnis in das grundlegende Seitengerüst einbaut.

Es gibt mehrere Möglichkeiten. Eine andere Möglichkeit wäre deshalb, diese Daten in einem Konfigurationssystem abzulegen.
Ja, aber ...!
Schränkt nicht genau diese Variante die Flexibilität enorm ein, bzw. erhöht den Administrationsaufwand?

Mehr Flexibilität setzt ein Mehr an Möglichkeiten voraus, und diese Möglichkeiten müssen erst einmal geschaffen und gewartet und auch administriert werden. Jedes hinzukommende Feature erhöht insgesamt die Komplexität und den Betriebsaufwand. Die Frage ist dann nur noch: Wer soll das System betreiben, und wie soll er das tun? Soll er direkt im Code rumfuhrwerken müssen oder bekommt er ein für ihn leichter zu handhabendes System. Woraus sich bei letzterem ergibt: neues Feature => mehr Komplexität. Du musst also immer abwägen, ob du Komfort oder weniger Komplexität haben möchtest.

Wenn man es so herum macht, dann muss ich ja für jeden "Ausgabezweck" irgendwo definieren
a) welche(s) Template(s) benötigt wird und
b) zusätzlich noch definieren, welche Action-Controller dafür von Nöten sind, um alle erforderlichen Daten aus dem Model dafür bereitzustellen
richtig?

Spontan fallen mir zwei wesentliche Arten von Action-Controllern ein: Der eine Typ soll eine allgemeine Art von Aufgaben erledigen, die mehrfach vorkommt, sich aber nur in Kleinigkeiten unterscheidet. Den kann man mit übergebenen Parametern steuern. Der andere Typ ist konzipiert für Spezialfälle. Dieses Controller sind so individuell, dass se nur für einen einzigen Fall zu gebrauchen sind und deshalb nicht flexibel mit Parametern versorgt werden müssen. Zwischen beiden Arten kann es beliebig viele Zwischenstufen geben.

Und das jedes Mal ggf. beides pflegen, wenn sich das Template als solches, oder im Template etwas ändert?

Irgendwo musst du die Änderung vornehmen. Die Frage ist dabei wieder: wer, wie und wo?

Was hieltest du denn von der Variante, diese Informationen jeweils in jedem Template mit zu speichern?

Prinzipiell Abstand. Das Template soll nur ausgeben und keine grundlegenden Entscheidungen treffen. Die Entscheidung, was auszugeben ist, ist abhängig vom Request. Bei einer Zeitung wird der Inhalt vom Chefredakteur bestimmt und nicht vom Layouter.

Ich dachte mir das Ganze eher in vielen kleinen Einzel-Templates (mit jeweils zugehörigem Action-Controller zur Beschaffung der benötigten Daten), die sich dann im Baukasten-Prinzip zusammenstellen lassen.

Im Grundgerüst der Seite müssen Platzhalter für die Module vorgesehen sein. Wenn das Grundgerüst-Template keine Daten für einen Platzhalter bekommt, dann fliegt letzterer eben einfach so raus und in der Ausgabe erscheint an der Stelle nichts.

Also bspw. ein Template mit Controller für die Breadcrumb-Navigation, eines für das Menü, eines für Kommentare zu einem Artikel, etc. Diese Einzel-Templates lassen sich dann nach Belieben in das Gesamt-Seiten Template integrieren (und zwar ohne irgendwelchen zusätzlichen Administrationsaufwand, bzw. Änderungen in irgendwelchen Konfigurationseinstellungen/ -dateien).

Der Aufwand bei einer Änderung ist immer da, ob du nun eine Konfigurationsdatei oder das Template änderst. Wie wird aber letzlich bei einem Request die Ausgabe der Einzel-Templates in das Grundgerüst eingefügt? Willst du das Grund-Template nach den Modul-Informationen scannen, die Module abarbeiten und deren Ausgabe einfügen oder willst du das Grund-Template ausführen und die Einzel-Templates sind als Funktionsaufruf (oder ähnlich) integriert?

Wäre das (deiner Meinung nach) eine praktikable Lösung (auch wenn sie vielleicht nicht 100%ig dem MVC-Modell entspricht)?
Der Entwicklungsschwerpunkt soll ja eindeutig auf größtmöglicher Flexibilität bei gleichzeitig möglichst niedrigem Pflege- und Administrationsaufwand liegen.

Das MVC ist ja kein Gesetz und man muss diesem Prinzip auch nicht bis ins kleinste Detail folgen. Es ist eine Orientierungshilfe, die man annehmen kann oder nicht. Das MVC-Muster hat sich bewährt, so dass ich ihm zu folgen versuche, das aber immer mit einer Beurteilung als Praktiker und nicht als Evangelist. Wie auch immer, es lohnt sich auf alle Fälle ein Blick über den Tellerrand. Wie haben es die anderen gelöst, was gefällt mir daran und was nicht?

Beispielsweise DotNetNuke. Ein Modul wird dort über die Administrationsoberfläche hinzugefügt. Man wählt das Modul aus und gibt an, in welche Pane - also in welchem Bereich des Grundgerüst - es hinzugefügt werden soll. Jenes Video zeigt ab kurz vor Minute 4:00, wie das dort gemacht wird. Dabei wird nicht das Template direkt geändert sondern die Konfigurationsdaten. Bei einem Request wird also nicht das Grundgerüst-Template nach Inhaltsmodulen durchsucht, sondern in der Konfiguration wird nachgesehen, welche Module verwendet werden sollen und an welcher Stelle sie im Grundgerüst einzufügen sind. Ohne Adminoberfläche kann man die Daten, welches Modul wo ausgegeben werden soll, in einer Konfigurationsdatei anlegen. Das Grundgerüst selbst wird sich selten ändern. Die Module und ihre Positionierung lassen sich jedoch auch so schon an einer zentralen Stelle konfigurieren und man braucht dazu noch nicht mal HTML-Kenntnisse, um über das Template gehend die Seite (in gewissen Grenzen natürlich) umgestalten zu können.

Lo!

[Gunther]

Hi!

Du schaust dir die Geschichte von außen an. Ich gehe da lieber der Reihenfolge nach. Da wäre als erstes ein Request. Ohne den, nützt dir das beste Template nichts. Vom MVC ausgehend startet der Request ja nicht gleich ein Template, sondern er landet typischerweise beim Front-Controller, der außer grundlegenden Initialisierungen zu einem bestimmten ActionController routet. Dieser Action-Controller erledigt (oder überwacht zumindest) die eigentliche Aufgabe, die im Hintergrund stattfindet, die Business-Logic (meist Speichern oder Abfragen von Daten). Daraus ergibt sich dann eine Ausgabe.

Ja, genau. Das war mein (Denk-)Fehler. Ich habe das Pferd sozusagen von hinten aufgezäumt. Du hast natürlich Recht, dass ich sowieso zuerst die 'Actions' definieren muss, bevor überhaupt irgendetwas in ein Template kommt.

In deinem Fall scheint mir es so zu sein, dass neben der Hauptausgabe eine Menge "Nebensächlichkeiten" in der Ausgabe zu finden sein sollen. "Oberflächlich" betrachtet werden das mehr oder weniger Kästen sein, die verschiedenen Zwecken dienen: Navigation, Login-Bereich, Werbung, News-Ticker und so weiter. Diese willst du anzunehmenderweise mit den Einzel-Templates abdecken. Es ist nun aber nicht so, dass sich ein Action-Controller um alles kümmern muss. Besser ist es dann, die Teilaufgaben auf einzelne Controller zu verteilen, was dann je Ausgabemodul eine eigene Kombination aus M, V und C ergibt. Es muss dann natürlich einen Koordinator geben, der die einzelnen Action-Controller der benötigten Module abgrast und deren Ergebnis in das grundlegende Seitengerüst einbaut.

Exakt so soll es sein. Um eben möglichst flexibel in den Möglichkeiten zu sein, möchte ich für die verschiedensten (Klein-)Aufgaben eben jeweils einen separaten 'Mini Action-Controller' erstellen.

Spontan fallen mir zwei wesentliche Arten von Action-Controllern ein: Der eine Typ soll eine allgemeine Art von Aufgaben erledigen, die mehrfach vorkommt, sich aber nur in Kleinigkeiten unterscheidet. Den kann man mit übergebenen Parametern steuern. Der andere Typ ist konzipiert für Spezialfälle. Dieses Controller sind so individuell, dass se nur für einen einzigen Fall zu gebrauchen sind und deshalb nicht flexibel mit Parametern versorgt werden müssen. Zwischen beiden Arten kann es beliebig viele Zwischenstufen geben.

Jo, leuchtet ein.

Was hieltest du denn von der Variante, diese Informationen jeweils in jedem Template mit zu speichern?

Prinzipiell Abstand. Das Template soll nur ausgeben und keine grundlegenden Entscheidungen treffen. Die Entscheidung, was auszugeben ist, ist abhängig vom Request. Bei einer Zeitung wird der Inhalt vom Chefredakteur bestimmt und nicht vom Layouter.

Nach eine Nacht drüber geschlafen, stimme ich dir voll und ganz zu. Ich weiß auch nicht, warum ich es vorher immer andersherum betrachtet habe!?

Beispielsweise DotNetNuke. Ein Modul wird dort über die Administrationsoberfläche hinzugefügt. Man wählt das Modul aus und gibt an, in welche Pane - also in welchem Bereich des Grundgerüst - es hinzugefügt werden soll. Jenes Video zeigt ab kurz vor Minute 4:00, wie das dort gemacht wird. Dabei wird nicht das Template direkt geändert sondern die Konfigurationsdaten. Bei einem Request wird also nicht das Grundgerüst-Template nach Inhaltsmodulen durchsucht, sondern in der Konfiguration wird nachgesehen, welche Module verwendet werden sollen und an welcher Stelle sie im Grundgerüst einzufügen sind. Ohne Adminoberfläche kann man die Daten, welches Modul wo ausgegeben werden soll, in einer Konfigurationsdatei anlegen. Das Grundgerüst selbst wird sich selten ändern. Die Module und ihre Positionierung lassen sich jedoch auch so schon an einer zentralen Stelle konfigurieren und man braucht dazu noch nicht mal HTML-Kenntnisse, um über das Template gehend die Seite (in gewissen Grenzen natürlich) umgestalten zu können.

Vielen Dank für den Link. Ich hab's mir mal angeguckt - sehr 'inspirierend'!

Überhaupt meinen allerbesten Dank für deine Zeit, Mühe und Hilfe. Als 'Einzelarbeiter' verrennt man sich halt manchmal, und dann braucht es fremde Hilfe, um wieder auf die richtige Spur zu kommen. Das ist dank deiner Unterstützung jetzt wieder der Fall!

Dank & Gruß
Gunther

[Struppi]

Bitte keine Hin- oder Verweise auf Smarty & Co. Mit solchen "Monstern" mit eigener Syntax möchte ich mich nicht beschäftigen, da sie für meine Zwecke auch der totale Overkill wären. Reines PHP (5 als OOP) wäre mir am liebsten.

Meines erachtens benötigt PHP keine Template Sprache, da es schon eine ist. D.h. die Templates werden in PHP geschrieben und nutzen dort einerseits PHP Syntax und die Objekte, die deine Anwendung zu Verfügung stellt. Alles andere halte ich für unnötigen Lernaufwand (da jede Templatesyntax neu erlernt werden muss) und es bremst die Anwendung.

Struppi.

[dedlfix]

Hi!

Bitte keine Hin- oder Verweise auf Smarty & Co. Mit solchen "Monstern" mit eigener Syntax möchte ich mich nicht beschäftigen, da sie für meine Zwecke auch der totale Overkill wären. Reines PHP (5 als OOP) wäre mir am liebsten.

Meines erachtens benötigt PHP keine Template Sprache, da es schon eine ist. D.h. die Templates werden in PHP geschrieben und nutzen dort einerseits PHP Syntax und die Objekte, die deine Anwendung zu Verfügung stellt.

Soweit richtig, aber darum geht es hier nicht direkt. Es geht mehr um die Organisation des Projekts als Ganzes. Auf welche Weise konkret die (einzelnen Teil-)Ausgabe(n) erzeugt wird, ist grad nebensächlich.

Alles andere halte ich für unnötigen Lernaufwand (da jede Templatesyntax neu erlernt werden muss) und es bremst die Anwendung.

Mit der Maxime kann man an eine Lösungsfindung herangehen, doch die muss sich nicht zwangsläufig als effektiv herausstellen. Dazu ein kleines, etwas absurdes Beispiel: Bei einem Request soll eine Zahl als Wort ausgegeben werden, also http://example.com/1 soll "eins" ausgeben, .../2 soll "zwei" ergeben und so weiter. Man kann nun zwei Dokumente erstellen, eins das das HTML-Grundgerüst und das Wort "eins" enthält, und das andere mit dem gleichen Grundgerüst aber einer "zwei" drin. Aufgabe gelöst, man muss nichts dazulernen und performant ist es auch. Es ist jedoch sehr unflexibel. Schon bei zwei Zahlen muss man zwei Dokumente bearbeiten, wenn am Grundgerüst etwas geändert werden soll. Je mehr Zahlen es werden, desto größer der Änderungsaufwand. Das Programieren einer Lösung macht das System flexibler, man muss nur noch an einer Stelle das Grundgerüst ändern. Doch dazu muss man eine Programmiersprache lernen und das Erstellen der Ausgabe auf Anforderung hin braucht auch mehr Zeit als das reine Ausliefern einer Datei. Obendrein ist das Gesamtsystem komplexer geworden. Alles hat Eigenschaften, die sich in konkreten Situationen als vorteilhaft oder nachteilhaft bewertet werden können.

Es ist also nicht immer sinnvoll, die vermeintlich einfachere Lösung zu nehmen. Template-Engines wie Smarty können durchaus auch einen Mehrwert gegenüber reinem HTML+PHP liefern, für den es sich lohnt, den hoffentlich nur anfänglich vorhandenen Mehraufwand in Kauf zu nehmen. Prinzipien können die Entscheidungsfindung abkürzen, sollten aber meines Erachtens nicht das einzige Entscheidungskriterium sein.

Lo!

[ChrisB]

Hi,

Dazu ein kleines, etwas absurdes Beispiel: Bei einem Request soll eine Zahl als Wort ausgegeben werden, also http://example.com/1 soll "eins" ausgeben, .../2 soll "zwei" ergeben und so weiter. [...]

Wenn von vor dem Template zuständigen Instanzen die Requests /1, /2 und /x bereits ausgewerte und die Übersetzung in "eins", "zwei", ... vorgenommen wurde - dann braucht im eigentlichen "Template" doch nur noch irgendwo die Ausgabe zu stehen: <?php echo $zahlAlsWort; ?> reichte theoretisch schon aus.

Es ist also nicht immer sinnvoll, die vermeintlich einfachere Lösung zu nehmen. Template-Engines wie Smarty können durchaus auch einen Mehrwert gegenüber reinem HTML+PHP liefern, für den es sich lohnt, den hoffentlich nur anfänglich vorhandenen Mehraufwand in Kauf zu nehmen.

Das mag in manchen Fällen durchaus so sein - nur dein konkretes Beispiel sehe ich jetzt eher als Argument für Struppis Aussage.

MfG ChrisB

[dedlfix]

Hi!

Dazu ein kleines, etwas absurdes Beispiel: Bei einem Request soll eine Zahl als Wort ausgegeben werden, also http://example.com/1 soll "eins" ausgeben, .../2 soll "zwei" ergeben und so weiter. [...]

Wenn von vor dem Template zuständigen Instanzen die Requests /1, /2 und /x bereits ausgewerte und die Übersetzung in "eins", "zwei", ... vorgenommen wurde - dann braucht im eigentlichen "Template" doch nur noch irgendwo die Ausgabe zu stehen: <?php echo $zahlAlsWort; ?> reichte theoretisch schon aus.

Ja, damit hast du ein Programm, dass diese Ausgabe erst erzeugen muss und mit allem damit verbundenen Mehraufwand, im Gegensatz zu einfacheren komplett statischen Dokumenten.

Ich vergleiche hier den Mehraufwand von Smarty (stellvertretend für auf PHP aufgesetzte Template-Systeme) gegenüber "reinem PHP" mit programmatisch erzeugter Ausgabe versus statischem Dokument. Man könnte ja Struppis Argumentation weiter zuspitzen und fragen, warum überhaupt PHP und nicht gleich einfache und performante statische Dokumente?

Es ist also nicht immer sinnvoll, die vermeintlich einfachere Lösung zu nehmen. Template-Engines wie Smarty können durchaus auch einen Mehrwert gegenüber reinem HTML+PHP liefern, für den es sich lohnt, den hoffentlich nur anfänglich vorhandenen Mehraufwand in Kauf zu nehmen.

Das mag in manchen Fällen durchaus so sein - nur dein konkretes Beispiel sehe ich jetzt eher als Argument für Struppis Aussage.

Seine Aussage war, dass man erst Smarty zusätzlich zum bereits als vorhanden anzunehmenden PHP erlernen muss und die Smarty-Engine jedes Mal Rechenaufwand kostet. In meinem Beispiel muss man eine Programmiersprache zusätzlich zum bereits vorhandenen HTML lernen und der Rechenaufwand des programmierten Systems gegenüber einer statischen Auslieferung Minuspunkte bei der Performance-Betrachtung ergibt.

Diese Betrachtung geht übrigens von einem Einzelkämpfer aus. Wenn die Arbeit für einen Programmierer und einen mit Programmierung wenig am Hut habenden Webdesigner aufgeteilt werden soll, kann eine Template-Engine auch wieder in der insgesamten Bilanz Punkte pro Template-Engine ergeben, weil deren Syntax vielleicht leichter zu erlernen ist und eventuell robuster gegenüber "echtem" Programmcode sein kann.

Lo!

[Struppi]

Diese Betrachtung geht übrigens von einem Einzelkämpfer aus. Wenn die Arbeit für einen Programmierer und einen mit Programmierung wenig am Hut habenden Webdesigner aufgeteilt werden soll, kann eine Template-Engine auch wieder in der insgesamten Bilanz Punkte pro Template-Engine ergeben, weil deren Syntax vielleicht leichter zu erlernen ist und eventuell robuster gegenüber "echtem" Programmcode sein kann.

Naja, das ist so hypothetisch wie meine Argumentation. Aber es stimmt, wenn man demjenigen, der die Templates anfassen soll, nicht traut, ist die PHP Lösung nicht angebracht.

Wordpress geht ja z.b. diesen Weg. Ich fand das Sinnvoll, da es für mich noch zusätzlich den Vorteil hat, dass ich dabei PHP lerne. Ich habe aber auch schon Wordpress Templates mit grausamen PHP Code gesehen.

Aber wenn ich das richtig verstehe (ich hab da nicht wirklich Ahnung), nutzen auch viele Java MVC Umgebungen Java Code in den Templates/Views.

Struppi.