Datenstrukturen von Extbase-Extensions anpassen
Anpassen von Typo3-Extbase-Extensions ist nicht trivial
So haben wir also unsere erste Extbase-Extension angelegt und mit dem Extenstion Builder die notwendigen Datenstrukturen erstellt. Alles läuft also nach Plan. Nur jetzt kommt der Kunde und möchte einige zusätzliche Attribute auf der Website ausgegeben haben.
Ja, das Ausgeben ist jetzt nicht das Problem. Ein bisschen die Fluid-Templates anpassen und eventuell etwas am Controller drehen. Aber wenn es um die Datenbasis geht, wird es etwas komplizierter. Die Datenbanktabelle mit den Attributen, die Model-Struktur und die Repositories sind hier nicht ausgenommen. Wir haben die Extension nämlich schon mit eigenen Gettern und Settern bestückt, und sehr, sehr viel Quellcode angepasst. Natürlich kann man jetzt hergehen und im Extension Builder neue Attribute eintragen. Dieser wird für uns dann die Klassen erneut erstellen. Und je nach Konfiguration leider auch unsere Anpassungen überschreiben. Bei wirklich komplexen Anpassungen möchte man das aber nicht riskieren und braucht deswegen einen tieferen Einblick in die Datenstrukturen von Extbase-Extensions.
Änderungen des Models einer Extbase-Extension
Langer Rede kurzer Sinn: Im Folgenden werden wir die einzelnen Schritte aufzeigen, welche Schrauben an welcher Stelle man drehen muss, um ein neues Attribut in die Extension einzubringen.
Extbase-Daten: Aller Anfang ist … die Datenbank
Logischerweise liegen die Daten unserer Extbase-Extension auch in der MySQL-Datenbank. Und dort beginnt unsere Erweiterungsaktion. In der Datei ext_tables.sql
befindet sich der MySQL-Code, der ausgeführt wird, wenn die Extension installiert wird. Wenn man diese Datei aufmacht, wird man feststellen, dass dort ganz gewöhnlicher MySQL-Code mit (im ersten Moment) gewöhnlichen CREATE TABLE
-Statements steht. Denn wenn wir hier eine Änderung vornehmen, indem wir eine zusätzliche Spalte info_phone
einfügen, wird beim erneueten Installieren geschaut, ob schon eine gleichnamige Tabelle existiert. Falls ja, dann wird hier nicht die ganze Tabelle gelöscht oder geleert, sondern einfach nur unsere zusätzliche Spalte eingefügt. Der Inhalt der Tabelle bleibt also erhalten. Gut, also erst einmal durchatmen. Die Daten gehen nicht verloren. Aber wir empfehlen trotzdem vor jeder Änderung einer Extension ein Backup der Extension-Daten zu machen, in dem man im Extension-Manager einen Datenbankkopie zieht, denn auch hier ist sicherer sicher.
Datenbank zu Model
Wenn die Datenbasis in Form der MySQL-Datenstruktur angepasst ist, dann geht man an das Model. Im Verzeichnis Classes/Domain/Model
befinden sich eine oder mehrere Klassen, die die Schnittstelle zwischen Programmcode und Datenbank bilden. Diese enthalten unsere Getter und Setter. Und wenn ein neues Attribut (in unserem Fall Info Phone) eingefügt werden soll, muss logischerweise auch hier etwas passieren. Dabei orientert man sich am Besten an bereits vorhandenen Attributen und kopiert diese mit einigen Anpassungen zu eigenen. Oder man ist ganz bequem und benutzt eine intelligente IDE, wie zum Beispiel PHPStorm. Dort hat man einige Tools zur Hand, die einem das Erweitern der Objekte leichter und vor allem schneller machen. Beim manuellen Kopieren wäre anzumerken, dass die Annotationen, genau wie die Funktionsnamen und Attribute im CamelCase benannt werden müssen.
Fluid-Templates anpassen
Somit wäre die Datenbasis fertig. Aber noch sieht man logischerweise nichts im Frontend. Deswegen ist nun das Template oder die Templates der Extension an der Reihe: Unter dem Pfad Resources/Private/Template/
im Extension-Verzeichnis finden Sie den HTML-Code mit Fluid-Tags, den man entsprechend anpassen muss — eben je nach dem, wo das neue Attribut Info Phone ausgegeben werden soll. Auch hier ist Extbase-Fluid wie ein strenger Mathematik-Lehrer: Das case-sensitive CamelCase darf auch hier nicht vernachlässigt werden, ansonsten fällt man durch. Anmerkung am Rande: Hier kommt wieder die Genialität von Extbase-Extensions zum Vorschein: Unser neues Attribut kann man hier auch weiterhin z.B. mit ViewHelper anpassen und hat so noch mehr Kontrolle über die Daten.
TCA-Konfiguration für Extbase-Extensions
Schön, dass wir die Datenstrukturen in der Datenbank verändert haben. Und auch sehr schön, dass es nun eine Möglichkeit gibt, diese im Frontend, auf der schönen Website, auszugeben. Aber wo um alles in der Welt gebe ich nun die Information zur Telefonnummer („Info Phone“) im Backend ein? Dazu muss nun das Backend angepasst werden. Man setze es auf den Stuhl binde ihm ein Tuch um den Hals und fange an, etwas am TCA herumzuschnibbeln. In der Datei Configuration/TCA/*.php
kann man das Typo3-Configuration-Array bearbeiten. Alles, was man dort ändert, spiegelt sich in der Eingabemaske im Backend wieder. Der Schlüssel showRecordFieldList
in diesem Configuration-Array enthält unter anderem die Auflistung der sichtbaren Attribute. So müsste in unserem Fall der String dahin gehend abgeändert werden, dass dort auch unser frisches Attribut phone_info
aufgelistet wird. So sagt man Typo3 im Grund genommen: Bitte spiele mir diese oder jene Eigenschaft im Backend aus, damit ich dort endlich meine Daten eintragen kann. Aber auch noch ein weiterer Schlüssel ist für uns interessant: Das types
-Array. Dieses beinhaltet die Konfigurationsdaten zu den einzelnen Felder. Ist unser Feld zum Beispiel ein Datumsfeld oder ein normales Textfeld? Gibt es zu dem phone
-Attribut eine mögliche Auswahlliste? Das und noch viel mehr kann man hier justieren.
Sprachen für alle! (Auch für Extbase-Extensions)
Es gibt Kunden, die haben nicht nur eine Sprache im Backend. Die Benutzer dieser internationaler Firmen sind auf der ganzen Welt verstreut und bevorzugen logischerweise auch eine bestimmte Sprache. Wie das im Frontend geht, das ist uns als Typo3-Veteranen ja bekannt. Im Backend ist es glücklicherweise auch sehr ähnlich. Auch dort gibt es Language-Files, die meist die Endung .lxf
haben. Wenn unsere Eigenschaft auf Englisch „Info phone“ heißt, dann kann man hier in der entsprechenden Übersetzungsdatei das deutsche Äquivalent „Info Telefon“ eintragen — und schon ist die eigene Extbase-Extension auch im Backend internationalisiert.
Kleine Helferlein
Je nach dem, wie die eigene Extension veranlagt ist, ist es nötig entweder den Cache zu löschen oder sogar die Extension neu zu installieren. Wir erinnern uns: Wenn man Änderungen an der Datenstruktur der Datenbank vorgenommen hat, dann wird die Datei ext_tables.sql
mit der bereits vorhandenen Datenbank zusammengeführt. Aber eben nur bei der Installation. Das ist zwar etwas umständlicher, ist aber aufgrund der Tatsache, dass man nicht allzu oft die Struktur der Datenbanktabellen verändert, noch halbwegs zu verkraften.
Extbase-Extensions: Wir machen das
Wenn Sie sich jetzt denken: Ja, es ist schön, dass das so funktioniert. Aber ich möchte aufgrund von zeitlichen oder organisatorischen Gründen diese Anpassungen meiner Datenbank outsourcen, dann stehen wir Ihnen sehr gerne zur Verfügung. Ich freue mich auf Ihren Anruf!
Titelbild: By Figugegl (Own work) [CC BY-SA 4.0], via Wikimedia Commons
Auch Interessant:
14. Januar 2016
Einführung in die Typo3-Extension Entwicklung mit Extbase
Einführung in die Typo3-Extension…
3. Juli 2015
ElasticSearch Tutorial: Das Konzept verstehen
Der Suchserver ElasticSearch ist schwer im…