Für einen klassischen Extension-Entwickler kann der Einstieg in die Programmierung mit Extbase bisweilen steinig sein. Zum einen muss er sich in neue Konzepte und Techniken wie Domain Driven Design, MVC oder die Template-Engine Fluid einarbeiten. Zum anderen ist es durch das Prinzip „Convention over Configuration“ besonders wichtig, die neuen Namenskonventionen für Klassen, Eigenschaften und Datenbanktabellen sowie die von Extbase geforderte Ordnerstruktur einzuhalten. Außerdem ist es zeitaufwändig, die Ordner- und Dateistruktur anzulegen, die jetzt tiefer und verzweigter ist als bei klassischen Extensions.

Obwohl man den Extbase Kickstarter noch nicht als fertig bezeichnen kann, hilft er sowohl Anfängern als auch Profis bereits jetzt bei der Erstellung von Extbase-Extensions. Ein kleiner Produktkatalog mit Kategorien und Produkten soll im Folgenden als Beispielanwendung dienen. Dieser Produktkatalog soll Auflistungen von Kategorien und deren Produkte enthalten, aber auch Listen wie „Meistverkaufte Produkte“. Aus Sicht des Domain Driven Design bedeutet das, dass die Kategorien und Produkte Aggregate-Root-Elemente sind.

Für die erste eigene Anwendung benötigt man die aktuelle TYPO3 Version 4.4 sowie die neueste Entwicklungsversion des Extbase-Kickstarters. Ein zur Installation geeigneter Snapshot steht bei Sourceforge.net zum Download bereit [1].

Die reguläre Installation über den Extension-Manager erweitert das Backend um ein neues Modul – eine Startansicht erklärt hier die Konzepte des Kickstarters. Mit einem Klick auf „Go to Domain Modeller“ geht es zum Herzstück des Moduls.

Bevor man sich dem Domain-Modelling widmet, steht der langweilige Teil an: ein Klick auf den Pfeil des linken Panels öffnet dieses und es erscheint ein Formular, das mit dem Extension-Key, einem Titel, einer Beschreibung, dem Status sowie den Daten des Entwicklers gefüllt werden muss. Nach der Eingabe kann man das Panel wieder zur Seite schieben und sich dem spannenden Teil widmen.

Auf der karierten Fläche in der Mitte des Screens erstellt man die benötigten Models und setzt sie in Beziehung zueinander. Zum Anlegen eines neuen Models klickt man einfach auf den Button „New Model Object“ und zieht diesen in die Bearbeitungsfläche. Der neu entstandene blaue Kasten steht für ein bestimmtes Domain-Model.

Durch einen Klick auf „click to edit“ im Kopfbereich lässt sich der Titel bestimmen. Für das Beispiel steht zuerst das Anlegen eines Models für die Kategorien an. Bei diesem Arbeitsschritt sollte man beachten, dass die Namen der Models in UpperCamelCase notiert und im Normalfall im Singular verwendet werden. Für die Kategorien ist daher „Category“ ein passender Titel.

Anschließend folgen unter „Domain Object Settings“ ein paar Angaben zum Model. Das Model „Category“ soll vom Typ „Entity“ sein und da es im Vorfeld als Aggregate Root definiert wurde, muss man hier die entsprechende Option aktivieren. Eine knackige Beschreibung rundet diesen Part ab.

Für die Beispielanwendung ignoriert man vorerst den Punkt „Default Actions“ und definiert statt dessen noch die Eigenschaften („Properties“) von „Category“. Die einzige Eigenschaft, die zu diesem Zeitpunkt Relevanz hat, ist der Titel der Kategorie. Die Namen der Eigenschaften werden in lowerCamelCase notiert, aus diesem Grund ist „title“ eine gute Wahl. Den vorgewählten Typ „Text String“ kann man so belassen und noch eine Beschreibung vergeben. Außerdem sollte „title“ ein Pflichtfeld („required“) sein.

„Category“ ist fürs Erste fertig – Zeit für ein „Product“-Model. Dieses Model legt man nach dem selben Schema an. Product ist ebenfalls ein Aggregate-Root-Element und soll die Eigenschaften „title“, „description“ und „price“ haben. Natürlich muss man „Product“ und „Category“ noch miteinander verbinden. Dies kann man für „Product“ unter „Relations“ definieren, indem man einfach eine neue Relation erstellt und diese als „category“ bennent. Anschließend zieht man mit gedrückter Maustaste eine Verbindung vom Andockpunkt der Eigenschaft „category“ zum Andockpunkt des Models „Category“.

Das soll soweit für einen Testlauf genügen. Ein Klick auf den Save-Button am unteren Rand startet den Schreibprozess.

Jetzt lohnt sich ein Blick auf das Dateisystem: Der Kickstarter hat einen Ordner mit dem Namen des Extension-Keys erstellt, der die generierten Dateien und Ordner enthält. Außerdem befindet sich eine kickstarter.json-Datei in diesem Verzeichnis, die der Kickstarter benötigt, um die Extension zum Bearbeiten neu laden zu können.

Es lohnt sich, sich einen Moment Zeit zu nehmen und in den erstellten Klassen und Dateien zu stöbern, um einen Überblick zu erhalten. Wenn man bereits ein wenig mit Extbase vertraut ist, sollte einem das nicht schwer fallen.

Auffallend ist, dass noch kein Templates-Ordner mit Fluid-Templates vorhanden ist. Trotzdem ist es möglich, die Extension bereits jetzt im Frontend aufzurufen, indem man einfach das Extension-Template in TypoScript einbindet und das Plugin auf einer Seite platziert. Es bietet beispielhaft einige Funktionen zum Erstellen, Bearbeiten und Ansehen von Datensätzen.

Dieser Modus dient dazu, das Model zu diesem Zeitpunkt noch einfach bearbeiten und testen zu können. Würde man die Templates statt dessen selbst bearbeiten, würde man diese bei einem neuen Schreibvorgang des Kickstarters wieder überschreiben.

Jetzt ist der beste Zeitpunkt, um das Model so gut wie möglich fertigzustellen. Für spätere Änderungen eignet sich der Kickstarter im jetzigen Entwicklungsstand nicht. Ist der gewünschte Reifegrad der Models erreicht, kann man die Template-Dateien erstellen. Hierzu wechselt man im Kickstarter über die Selectbox oben links in den Bereich „Convert Dynamic to Static Scaffolding“ und klickt für jeden Controller einmal auf den entsprechenden Link. Anschließend findet man ein paar vordefinierte Actions in den Controllern und die dazugehörigen Fluid-Templates im Templates-Ordner.

Die Arbeit des Kickstarters ist an dieser Stelle beendet. Nun kann man die eventuell nicht benötigten Actions entfernen, eigene hinzufügen und die benötigte Logik in den Controllern und Templates implementieren.

Wer noch etwas Nachhilfe in Sachen Extbase braucht, dem sei der Einstiegsartikel von Patrick Lobacher [2] ans Herz gelegt. Außerdem lohnt sich für Anfänger und Fortgeschrittene die Anschaffung des Buchs „Zukunftssichere TYPO3-Extensions mit Extbase und Fluid“ von O’Reilly.

Der Extbase-Kickstarter ist zwar in der Praxis schon recht nützlich, steckt aber noch tief im Entwicklungsprozess. Das Team freut sich deshalb immer über Feedback jeglicher Art. Dreh- und Angelpunkt der Entwicklung ist das TYPO3-Forge.

In Zukunft soll es möglich sein, auch bereits manuell bearbeitete Extensions im Kickstarter weiterzuentwickeln oder die Datenmodelle bestehender Extensions einzulesen. Außerdem wird mit verschiedenen Schnittstellen experimentiert, um Datenmodelle anderweitig einzulesen oder weiterzuverwerten. Schließlich wird das Interface mit Hilfe von ExtJS noch einmal komplett überarbeitet, damit es zukünftig noch benutzerfreundlicher und flexibler ist.