- typoblog - http://www.typoblog.de -

Teil 7: Fluid – die Templating Engine

Teil 7:

Fluid – die Templating Engine

 

Von pi_base Extensions sind wir Entwickler es gewohnt, das auszuliefernde HTML direkt im PHP Code zusammenzubauen oder Markertemplates zu verwenden. Dort hat man das HTML, das sich durch die Arbeit der Extension nicht verändert, definiert und die dynamischen Teile durch Platzhalter ersetzt. Liebevoll ‘Schweinegatter’-Templates genannt, gaben sie uns zumindest eine Möglichkeit der Trennung von funktionalem Code und Markup. Seien wir ehrlich, schön ist was anderes, aber wenn man sich einmal daran gewöhnt hatte, war es besser als gar kein Templating. Das ist aber kein Grund weiter daran festzuhalten, denn es geht eleganter.

Die von TYPO3 CMS mitgelieferte (und übrigens auch von TYPO3 Flow am besten unterstützte und von TYPO3 Neos verwendete) Templating Engine ist TYPO3 Fluid. Templates hierfür bestehen immer noch aus statischem HTML und Platzhaltern, die ViewHelper genannt werden. Insgesamt ist das Konzept aber deutlich flexibler. Beispielsweise können ViewHelper mit Parametern versehen werden, was zu einer angepassten Ausgabe führt. Außerdem muss man sich nicht mehr selbst um das Zusammenspiel zwischen funktionalem Code und Ausgabe kümmern, das erledigt Extbase.

Sobald man sich mit einer Extbase-Extension befasst, hat man die volle Fluid-Power zur Verfügung. Keine Konfiguration, keine Aktivierung, die Templating Engine steht bereit. Aufwendiger wird es, wenn man Fluid explizit nicht benutzen möchte, sondern vielleicht Twig oder Smarty. Diese sind nicht integriert und müssten selbst eingebaut werden. Ich hoffe allerdings, dass das ein theoretischer Fall bleibt. Von Fluid bin ich überzeugt, und wenn es keine zwingenden Gründe gibt, werde ich es auch verwenden.

 

Templates, Layouts, Partials

Im vorigen Teil hatte ich versprochen das Fluid-Template zu erklären, das ich da so kommentarlos verwendet habe. Dieses Versprechen löse ich nun ein:

In einer Minimalversion könnte man eine einzige Template-Datei benutzen – ohne Header und statische Teile, die die Seite selbst ja schon liefert – und keine weiteren, davon abhängigen Dateien. Mein Beispiel benutzt schon eine Template-Datei und ein Layout. In beliebiger Menge können dann noch Partials dazukommen, die auch noch geschachtelt sein können.

 

Templates

Der Einstiegspunkt ist das Template. Es liegt nach Konvention in <extkey>/Resources/Private/Templates. Welches Template benutzt wird bestimmen der Name des Controllers und der Name der ausgeführten Aktion. Für unser Beispiel ist das Biblio -> indexAction. Damit wird das Template innerhalb des Pfades unter Biblio/Index.html gesucht. Das ist alles kein Zufall, noch nicht einmal die Dateiendung. Das Ausgabeformat ist eingestellt auf HTML, das ist die default-Einstellung. Daraus ergibt sich dann die Dateinamenerweiterung. Deklariert man die Action als ein JSON-Konstrukt, wird eben nach Index.json gesucht. Wird die Datei nicht gefunden, gibt es die bereits vorgestellte Fehlermeldung.

 

Layouts

Ab diesem Punkt ist alles optional: Wurde das Template gefunden, wird sein Inhalt ausgegeben. Enthält das Template nur statisches HTML, so passiert weiter nichts. Ein Template kann aber auch ein Layout aufrufen. Ein Layout ist so etwas wie der äußere Rahmen für die Ausgabe des Templates. Pro Template kann aber nur ein Layout involviert sein. Sobald ein Layout verwendet wird, muss man im Template sections verwenden – minimal eine, gern auch mehrere. Was passiert beim Einsatz von Sections: Die Layout-Anweisung im Template führt dazu, dass zunächst das Template nicht weiter interpretiert wird. Stattdessen wird das Layout ausgewertet. Das Layout aus dem Beispiel enthält etwas statischen Wrapper-Code und eine einzige Section-Anweisung. An die Stelle dieser Section wird derjenige HTML-Code eingefügt, der im Template innerhalb der beiden Section-Tags mit diesem Namen erzeugt wird. Dieses Spiel lässt sich beliebig oft wiederholen: eine Section-Anweisung ins Layout, einen Section-Abschnitt ins Template und dazwischen statischen Code, den man so nur einmal schreiben muss. Das gibt maximale Freiheit beim strukturieren der Ausgabe der Extension. Sections können auch als optional deklariert werden, so dass man auf den aktuellen Zustand reagieren kann und bestimmte Teile nur in bestimmten Situationen anzeigt.

Für die Ausgabe einer Extension reicht normalerweise eine Section, schließlich will man in der Regel nur die Ausgabe der Extension zusammenhängend ausliefern. Wirklich interessant wird diese Möglichkeit allerdings, wenn man Fluid als Templating-Engine für die Seitenerstellung selbst benutzt. Dann wird nicht mehr über Extbase gesteuert, sondern über TypoScript. Das Objekt dafür heißt FLUIDTEMPLATE. Als Alternative zu den diversen Template Extensions, wie z.B. TemplaVoila oder Gridelements, bietet es vergleichbare Möglichkeiten und kommt ohne Extensions aus. Daher empfehle ich den Einsatz von FluidTemplate als Templating Mechanismus für jede Seite, die ohne FCEs (flexible content elements) auskommt. Das ist auf jeden Fall einen näheren Blick wert.
Beim TYPO3blogger gab es mal ein HowTo, ich verlinke es hier. Ist schon älter, aber als Einstieg nicht schlecht:

 

Partials

So, nun aber zurück zu der Extension. Das dritte Element im Bunde sind Partials. Dies sind die kleinsten Einheiten. Sie können sowohl in Templates, Layouts und auch in andere Partials integriert werden. Als Faustregel kann man im Hinterkopf behalten, dass aller Code – statisch oder nicht – den man mehr als ein Mal verwendet, in ein Partial ausgelagert wird.

Auch Partials können Sections enthalten. Selbst habe ich das bisher noch nicht gebraucht, man kann sich das aber super bei der Einbindung des Namespaces zunutze machen, der dann für die Textergänzung der Fluid ViewHelper in der IDE benutzt wird. Wie das geht, wurde in Teil 2 der Blogreihe beschrieben.

 

Fazit

Fassen wir zusammen: Der Einstiegspunkt ist das Template. Wo es liegt und wie es heißt unterliegt den Namenskonventionen. Als Rahmen um die Template-Ausgabe kann ein Layout mit Sections definiert werden. Beide können, müssen aber nicht, Partials enthalten. Weder Layout noch Partial unterliegen Namenskonventionen unterhalb ihres Ordners und können damit frei strukturiert werden.

So, das soll für die Theorie jetzt aber wirklich reichen. Es werden reichlich Gelegenheiten kommen, sich einzelne Details dieser Strukturen noch genauer vorzunehmen und dann im Einzelnen zu beleuchten.

Im nächsten Teil geht es dann weiter mit dem Dashboard für´s Backend. [3]

 

Übrigens, wer das alles gerne mal kompakt in einem Kurs lernen würde, bei der typovision academy [4] biete ich auch eine Schulung zum Thema an: TYPO3 Extbase/Fluid-Schulung für Einsteige [5]r. Der nächste Kurs findet Anfang Oktober statt.

 

Beitrag verpasst?
Extension-Entwicklung mit TYPO3 Extbase & Fluid

Teil 1: Entstehung der Blogreihe, Idee & Datenmodellierung
Teil 2: Das Grundgerüst
Teil 3: Implementierung
Teil 4: Implementierung Kunden Model
Teil 5: Implementierung Model Bibliothek
Teil 6: Implementierung Bibliothekscontroller & Backendmodul für die Verwaltung [6]