Typo3 6.2 Fluid und eigene ViewHelper

In der Entwicklung von Typo3 Extbase-Extensions ist es wie im wahren Leben: Solange man das macht, was die breite Masse tut, ist alles in Butter. Aber wehe dem, wenn man beginnt darüber nachzudenken, aus der Reihe zu tanzen. Dann wird es nämlich etwas komplizierter. Nehmen wir mal an, dass man schön brav seine Datenstruktur (wie unter anderem in diesem Artikel beschrieben) angelegt hat. Man hat seine Getter und Setter mütterlich gepflegt und möchte nun die Daten ins Frontend bringen. Das funktioniert in Typo3 Extbase natürlich mit Fluid.

Fluid stellt eine Reihe von Methoden zur Verfügung, wie man seine Daten verarbeiten kann, wie man durch diese iteriert um diese schließlich an den Mann zu bringen. Diese Funktionalitäten heißen in Typo3 Fluid ViewHelper und man kann als gut trainierter Webentwickler alles in der offiziellen Dokumentation nachlesen. Neben Beschreibung der (erforderlichen) Parameter findet man dort auch Praxisbeispiele.

Warum eigene ViewHelper für Typo3 Extbase Fluid

Wenn man durch die Liste der ViewHelper geht, sich durch Schleifen und Verzweigungen durchwühlt, wird man zumindest bei einigen Webprojekten leider feststellen müssen, dass diese für ganz spezielle Fälle nicht ausreichen. Das ist so wie bei einem Anzug. Diesen hat man vor der Hochzeit ausgesucht und muss einige Monate nach der Hochzeit feststellen, dass er nicht mehr passt (ich spreche nicht aus Erfahrung). Jetzt muss man ihn zum Schneider geben, damit dieser einige Erweiterungen vornimmt. Genau so ist es im Fall der Fluid Entwicklung: Wenn man sich mit den bereits vorhandenen ViewHelpern nicht mehr begnügen kann, muss man eine Möglichkeit suchen, eigene ViewHelper zu implementieren. Daran haben die Kollegen von Typo3 natürlich gedacht und deswegen gibt es sie: die custom ViewHelper.

Die Dateistruktur vom eigenen ViewHelper

Bevor man sozusagen mit Schere und Nadel loslegt, um seinen Anzug zu erweitern, sollte man erstmal wie jeder gute Entwickler Maß nehmen. Folgende Fragen sollte man sich schon im Voraus stellen:

  • Was sollten meine ViewHelper können?
  • Welchen Input wird dieser verarbeiten?
  • Welchen Output stellt dieser in welcher Form bereit?
  • Möchte ich mit den verarbeiteten Daten meines ViewHelpers weiterarbeiten?

Wenn das geklärt ist, kann man direkt loslegen und seine Dateistruktur anlegen. Eine Extension liegt standardmäßig im folgenden Verzeichnis: [Typo3-Verzeichnis]/typo3conf/ext/[Meine Extension]. Dort gibt es einen Ordner Classes, der sowohl die Verabeitung der Daten (Logistikschicht) als auch die Schnittstelle zur Datenbank (das Model und die Repositories) beinhält. Und genau diesen Ordner kann man jetzt um einen weiteren Unterordner ViewHelpers erweitern. Wie der Name eben schon sagt, kommt dort unser eigener ViewHelper hinein.

Ein bisschen Standard bitte!

In Typo3 gilt besonders ab Version 6.2 immer mehr der Slogan: Convention over configuration. Das bedeutet für uns als deutschsprachige Bürger: Die Vereinbarungen stehen während der Entwicklung über der Konfiguration des Systems oder der eigenen Extension. Auch bei der Erstellung eigener ViewHelper wird hier keine Ausnahme gemacht. So hat zum Beispiel der Name des ViewHelpers auch Auswirkungen darauf, wie er im Fluid-Template aufgerufen wird und ob Typo3 das kleine Helferlein überhaupt findet.

Anwendungsbeispiel für einen eigenen ViewHelper (Typo3 6.2)

Nehmen wir an, wir bräuchten eine ganz simple Verarbeitungslogik: Wir möchten einen String splitten. Oder wie man auf PHP sagen würde: exploden. Dieser soll einen String (egal, ob dieser im Endeffekt aus der Datenbank oder aus einer anderen Quell kommt) in mehrere Teile zerteilen und die Möglichkeit bereitstellen, mit diesen einzelnen Teilen zu arbeiten. So kann man z.B. eine kommaseparierte Liste mit IDs nochmal mit einer .xlf-Übersetzungdatei übermalen, damit auch die Spanischen Websitebesucher glücklich sind. Sie ahnnen es bereits: Die Möglichkeiten mit custom ViewHelper sind schier unbegrenzt

Custom Fluid ViewHelper anlegen

Wir vertiefen uns in den Lieblingseditor und erstellen die Datei SplitViewHelper.php im Verzeichnis [Typo3-Verzeichnis]/typo3conf/ext/[Meine Extension]/Classes/ViewHelpers/. Der Inhalt des frischen ViewHelpers wird hier Schritt für Schritt erläutert:

<?php

Das bedarf eigentlich keiner Erläuterung. Ich möchte aber trotzdem darauf verweisen (da man das gelegentlich selber vergisst), dass man zwar ein öffnendes PHP-tag braucht, aber kein schließendes.

namespace SchwarzerDE\Glossareditor\ViewHelpers;

Hier wird für die Datei ein Namespace angegeben. Der erste Teil ist der Vendor, in unserem Fall SchwarzerDE.

use \TYPO3\CMS\Fluid\Core\ViewHelper\AbstractViewHelper;
class SplitViewHelper extends AbstractViewHelper {

Um von AbstractViewHelper erben zu können, muss man logischerweise irgendwo auf diese Klasse verweisen. Das tut man mit dem use-Statement. Diese Vorgehensweise bietet dem Entwickler einige vordefinierte Funktionen und Methoden, wie zum Beispiel: initializeArguments(). Hier kann man festlegen, welche Parameter unser ViewHelper annehmen wird und wie diese gehandhabt werden sollen.

Jetzt kommen wir zum Kern unserer Datei. Die Funktion render ist für das Ausgeben der Inhalte verantwortlich. Das hört sich im ersten Moment unspektakulär an: Man gibt ihr etwas Input und bekommt dafür etwas Output. Ja, das stimmt. Der Clou ist aber, dass man hier nicht nur Plain-Strings zurückbekommen kann, sondern auch Variablen, mit denen man dann wie gewohnt weiterarbeiten kann. So gibt es zum Beispiel die Variable $this->templateVariableContainer, in die man zusätzliche, eigene Variablen ablegen kann, um sie dann z.B. mit einer f:if-Abfrage zu prüfen oder anderweitig zu verarbeiten. Die Funktion $this->templateVariableContainer->add($variableName, $variableValue) bietet genau diese Funktionalität.

Einbindung des eigenen ViewHelpers in Fluid

Jetzt sind die groben Formalitäten abgeschlossen und der ViewHelper ist fertig. Nun kann man endlich seinen Code von der Seele tippen und das Fluid-Template erweitern: Zuerst muss vor der eigentlichen Verwendung eine Referenz zu unserer neuen PHP-Datei rein:

{namespace t=SchwarzerDE\Glossareditor\ViewHelpers}

Warum macht man das? Na, das ist ganz einfach: Jetzt weiß Typo3, wo er unseren ViewHelper finden kann. Nun kann man den Beispielcode ausgeben, um zu checken, ob alles funktioniert:

<t:Split content="1,2,3,4" glue="," as="splittedStrings">
    <f:debug>{splittedStrings}</f:debug>
</t:Split>

Der Inhalt 1,2,3,4 wird hier anhand des SplitStrings , in ein Array splittedStrings zerteilt und anschließend mit der Debug-Ausgabe ausgegeben. Damit kann man dann alles weitere anstellen: Ausgeben, verarbeiten, prüfen, usw.

Wie in Butter: Eigene ViewHelper in Typo3 6.2

Somit haben wir unseren ersten ViewHelper fertig und einsatzbereit. Wenn man erstmal die Struktur und Funktionsweise von eigenen Typo3 6.2 Fluid ViewHelpern verstanden hat, geht jede weitere Änderung — um die Analogie vom Anfang nochmal aufzugreifen — genau so leicht von der Hand wie bei einem geübten Schneider.

Ich würde mich freuen, wenn auch ich eine Schere und eine Nadel in die Hand nehmen darf, um Ihnen bei Ihren Webprojekten maßgeschneiderte ViewHelper entwickeln zu können und bin gespannt auf Ihre Ideen!

By Wolfgang Sauber (Own work) [CC BY-SA 3.0], via Wikimedia Commons