Eine Template-Engine erweckt statische HTML-Templates zum Leben, indem es ermöglicht wird, Platzhalter mit Inhalten einer externen Datenquelle zu füllen. Die dafür notwendige Anwendungslogik übernimmt die Template-Engine (siehe: Abb.). Das klassische Templating mit TYPO3 ist von Markern und Subparts in der Designvorlage abhängig, was der Konsistenz im Template schadet. Im Gegensatz zu bekannten PHP-basierten Template-Engines (Smarty, PHPTAL, etc.), vereint Fluid folgende Eigenschaften: leicht verständliche Syntax, flexibel und einfach erweiterbar, objektorientierter Quellcode (PHP5) und strikte Trennung zwischen Layout und Steuerung (PHP-freies Template). Vgl.: [Kurfürst 2009] – t3n, H.16, Fluid – Templating leicht gemacht.
Template-Engine als zentraler Verarbeitungsprozess der View
Fluid ist eine von Sebastian Kurfürst entwickelte Systemextension für TYPO3 4.3, die neben Extbase ebenfalls ihren Ursprung als Bestandteil im FLOW3-Framework hat. Dabei sind Extbase und Fluid eng miteinander verknüpft, denn Fluid stellt die Anwendungslogik der Template-View für das MVC-Framework von Extbase dar. Das bedeutet, Fluid erweitert die vorhandene View, die ausschließlich für das einfache Darstellen von Inhalten zuständig ist, um zusätzliche Kontrollmechanismen für das Template-Rendering. Dazu gehört zum Beispiel das Traversieren von Arrays und ganzen Objekten. Im folgenden PHP-Code-Beispiel wird das assoziative Array als Inhalt in die View gesteckt. Das erste Argument der assign()-Methode dient dabei als Bezeichner, das zweite enthält das Daten-Array. Das der Controller-Action zugehörige Fluid-Template ist nun in der Lage, den gewünschten Key des übergebenen Arrays anhand einer punkteseparierten Notation („{…}“ – ähnlich JSON-Notation) auszuwählen und den dazugehörigen Wert darzustellen. Hinter dieser neuen Anwendungslogik steckt ein Template-Parser von Fluid, der dem Rendering zwischengeschaltet ist.
Controller-Action (PHP-Datei):
$array = array('key' => 'value', 'key2' => 'value2'); $this->view->assign('identifier', $array);
Fluid-Template (HTML-Datei):
<h3>{identifier.key2}</h3>
Wie erwähnt, ist Fluid auch dazu fähig, ganze Objekte zu traversieren: Das entsprechende Objekt wird wie gewohnt an die View übergeben. Dabei handelt es sich vorzugsweise um ein Domänenmodell, das diverse Getter- und Setter-Methoden besitzt, die dessen Objekt-Eigenschaften repräsentieren. Der beispielhafte Ausdruck {identifier.objektname.objekteigenschaft} aus dem Fluid-Template ist daher gleichbedeutend mit dem Methoden-Aufruf: $objektname->getObjekteigenschaft(). Diese Getter- und Setter-Methoden im Modell folgen einer Lower Camel Case-Namenskonvention mit festgelegtem Präfix: get oder set.
Je nach Domänen-Kontext können auch ganze Modell-Ketten im Aggregat vorliegen. Um derartige Strukturen nach ihren Objekten und Eigenschaften zu iterieren, benötigt man die Kontrollstruktur einer Schleife. Jegliche Ausgabelogik wird bei Fluid über sogenannte ViewHelper realisiert, wobei hinter jedem ein XML-Element steckt, das wiederum einer PHP-Klasse aus dem Fluid-Core zugeordnet ist. Die Tatsache, dass ausschließlich Tags in der View benötigt werden, führt zu einem einheitlichen und übersichtlichen Template-Aufbau, zu dessen Verständnis keine direkten Programmierkenntnisse notwendig sind. Der For-ViewHelper <f:for> verhält sich als Kontrollstruktur im Fluid-Template wie eine PHP-Foreach Schleife. Die folgende Foreach-Kontrollstruktur stellt die Eigenschaften der vorhandenen Tochter-Objekte, in Form einer Liste dar:
<ul> <f:for each="{parentobject.objects}" as="object"> <li>{object.eigenschaft}</li> </f:for> </ul>
Außerdem ist es möglich eigene ViewHelper zu entwickeln, falls die schon vorhandenen nicht ausreichen sollten. Fluids ViewHelper besitzen dafür einen eigenen Namensraum (ähnlich XML-Namespace), der durch das Präfix f gekennzeichnet und standardmäßig implementiert wird. Durch das Implementieren eigener Namensräume ist es damit unmöglich, vorhandene ViewHelper mit eigenen zu überschreiben. Um sich wiederholende Template-Strukturen zu minimieren, existiert die Möglichkeit, Template-Layouts zu schreiben. Diese enthalten neben dem Standard-Layout einen Render-ViewHelper, dessen Section-Attribut die darzustellende Sektion aus dem Ziel-Template kennzeichnet. Abschließend muss auf den Zielseiten noch deklariert werden, um welches Layout-Template es sich handelt <f:layout name=”…” /> und welche Sektion davon im Ziel-Template betroffen ist:
<f:section name=”inhalt”>…</f:section>
Unter den Kontrollstrukturen existiert noch der sehr nützliche If-ViewHelper <f:if>, der mit dem Then- und Else-ViewHelper verschachtelt werden kann. Für diese If/Else-Bedingungen sind nur boolesche Ausdrücke miteinander vergleichbar. Neben den Link-ViewHelpern <f:link.email> und <f:link.external>, erlaubt es der ViewHelper <f:link.action> Links an Controller-Actions anzugeben. Ebenso können GET/POST-Parameter eines Formulars durch den Form-ViewHelper an beliebige Actions gesendet werden. Der Zugriff auf Sprach-Labels (XML-Format) ist über den Translate-ViewHelper möglich. Dadurch liegt eine simple und zugleich systemumfassende Lösung für die Mehrsprachigkeit in Extension-Templates vor.
Hinter diesen und weiteren ViewHelpern steckt das Kernkonzept von Fluid, das dem Template-Designer eine weitreichende Anwendungslogik in Form von leicht verständlichen XML-Tags anbietet.
Literatur:
Jim