Neben der vom Kickstarter bekannten Starthilfe leistet der „Extension Builder“ [1] auch nach Beginn der Entwicklung noch wertvollen Beistand. So ist das nachträgliche Editieren der Modelle mithilfe der grafischen Oberfläche möglich.

Kern der kürzlich im TER veröffentlichten Erweiterung ist ein grafischer Editor, der den Domain-Driven-Design-Ansatz unterstützt – ein Ansatz, bei dem der Fokus ganz auf der Business-Logik statt auf der technologischen Implementierung liegt. Darin erzeugt der Benutzer per Drag & Drop Modelle, denen im Anschluss die benötigten Eigenschaften und Relationen hinzugefügt werden. Das Ergebnis ist eine optische Darstellung aller beteiligten Komponenten und Relationen, die in der Extension eine Rolle spielen werden. Diese Komponenten und ihr Kontext repräsentieren sie die so genannte „Domain“ der Anwendung.

Gemäß dem Domain-Driven-Design-Ansatz [2] sollte der Fokus bei der Softwareentwicklung auf dieser Domain liegen, die als Grundlage der Kommunikation zwischen Entwickler und Kunde dient. Eine einheitliche Sprache („Ubiquituous language“) ist die Voraussetzung für ein gemeinsames Verständnis des Projekts. Sie soll vermeiden, dass Kunde und Entwickler aneinander vorbei reden.

Ein Beispiel: Während der Kunde, wenn er vom Autor eines Artikels redet, an eine Person denkt, meint der Entwickler drei MySQL-Tabellen und ihre Verknüpfungen. Der Fokus auf der Domain, wie eingangs beschrieben, bedeutet, sich als Entwickler nicht von technologischen Besonderheiten ablenken lassen (wie etwa den Beschränkungen von Datenbankrelationen), denn das sind Framework- und Implementierungs-Probleme, welche die Domain nicht belasten sollten. Auch im Quellcode der Anwendung sollte sich die Domain widerspiegeln: Methoden-Namen wie Blog.getAuthor() oder Blog.addPost(…) sind selbsterklärend und auch für Nicht-Entwickler verständlich. Nebenbei erleichtern sie auch die Pflege einer Extension und verkürzen die Einarbeitungszeit für andere Entwickler.

Lerne jetzt in unserem Videokurs die Grundlagen der Agilität kennen!

Um eine neue Extension zu erstellen, sind viele Dateien nötig; die meisten davon enthalten nur Konfigurationen, Datenbank-Definitionen und Ähnliches. Gemäß dem MVC-Prinzip findet sich die eigentliche Logik zusammengefasst in wenigen Dateien: den Controllern- und Model-Klassen. Der Extension Builder erzeugt anhand des grafisch erstellten Modells alle notwendigen Dateien und Klassen, sodass sich der Entwickler ganz auf die Implementierung der spezifischen Logik konzentrieren kann. Dies spart nicht nur Zeit, es vermeidet auch Fehler in der Konfiguration, die oft durch Schreibfehler entstehen.

Der Builder legt auch einfache Tests an, die mit der „PHPUnit“-Extension [3] direkt im Backend oder über die Kommandozeile ausgeführt werden können. Das soll Entwickler dazu anregen und es ihnen erleichtern, eigene Tests für ihre Extension zu schreiben und so eine bessere Qualität zu gewährleisten.

Nachdem das Modell definiert wurde, kann die Extension erstellt und die gewünschte Logik implementiert werden. Oft merkt der Kunde aber beim ersten Ausprobieren, dass das Modell noch nicht endgültig seinen Anforderungen entspricht. Um solche Rückmeldungen schnell aufnehmen zu können, sollte der Kunde möglichst früh erste Beta-Versionen ausgehändigt bekommen, da so sein Feedback in die Weiterentwicklung einfließen kann. Dieses Verfahren wird (zusammen mit weiteren Konzepten) als agile Softwareentwicklung bezeichnet. Der Extension Builder unterstützt diesen Ansatz, da er in einem Editier-Modus betrieben werden kann. Dabei werden sowohl Änderungen, die der Entwickler bereits am Quelltext vorgenommen hat, als auch Änderungen am Modell, die nachträglich über den grafischen Editor vorgenommen wurden, zusammengeführt. Der eigens entwickelte „ClassParser“ sorgt dafür, dass PHP-Klassen eingelesen und die notwendigen Änderungen am Quelltext vorgenommen werden können, ohne bestehende Logik zu zerstören oder zu überschreiben.

Auch nach der Fertigstellung der Extension können somit noch Änderungen vorgenommen werden, etwa um neue Funktionen zu implementieren. Darüber hinaus dient die grafische Darstellung als Dokumentation für Entwickler und Kunden, ganz ähnlich einem UML-Diagramm. Der Entwickler kann überdies genau festlegen, welche Dateien vom Extension Builder überschrieben, beibehalten oder zusammengeführt werden sollen. Hinzugefügte Klassen und überschriebene Methoden bleiben aber dennoch erhalten, es wird zur Sicherheit ein zusätzliches Backup der alten Version angelegt.

Wer keine Erfahrung mit der Extension-Entwicklung auf Extbase/Fluid-Basis hat, für den bietet das enthaltene Scaffolding, also das automatisierte Erzeugen aller benötigten Templates, einen guten Einstieg. Die eigene Extension entsteht in fünf einfachen Schritten:

1. Extension-Name und -Key eingeben.
2. Ein Plugin hinzufügen.
3. Ein einfaches Modell mit mindestens einer Eigenschaft durch Drag & Drop erstellen.
4. Das anzuzeigende Modell als „Aggregate Root“ markieren (unter Domain Object Settings).
5. Extension speichern.

Nun kann die eigene Extension installiert und als Plugin auf einer Seite eingefügt werden. Neben der Listenansicht (Standard) ist bereits eine Detailansicht und ein Formular zum Anlegen neuer Daten im Frontend vorhanden. Die so erstellte Extension sollte aber keinesfalls produktiv eingesetzt werden, da keine Kontrolle der Zugriffsrechte für das Anlegen neuer Objekte implementiert wurde. Sie bildet aber einen guten Ausgangspunkt zum Verständnis der Struktur einer Extbase-Extension und kann als Basis für die Entwicklung eigener Erweiterungen dienen. Eine ausführliche Anleitung sowie eine detaillierte Dokumentation ist darüber hinaus im TYPO3-Wiki zu finden [4].

Der Extension Builder liegt derzeit in Version 2.0 vor. Neue Funktionen sind in Planung und werden nach und nach ergänzt. So ist vorgesehen, auch bereits existierende Modelle anderer Extensions oder TYPO3-spezifische Modelle (wie etwa den Frontend User) in den Editor einzubeziehen. Viele noch fehlende Konfigurationsmöglichkeiten werden ebenfalls nach und nach hinzugefügt. Mittelfristig sollen so alle Optionen über Formulare eingestellt oder geändert werden können. Der aktuelle Status lässt sich sowohl auf Forge [5] als auch über die Mailingliste [6] verfolgen.

Das Extbase/Fluid-Framework ist bekanntlich eine Portierung wesentlicher Prinzipien des neuen FLOW3-Frameworks nach TYPO3 4.x. Die Struktur und die Abläufe einer Extbase-Extension sind denen eines FLOW3-Packages sehr ähnlich. So werden sich Entwickler, die mit Extbase vertraut sind, auch mit FLOW3 schnell zurechtfinden. Entsprechend ist mittelfristig geplant, den Extension Builder auch zum Erzeugen von FLOW3-Packages einzusetzen. Dabei müssten lediglich TYPO3-4.x-spezifische Konfigurationen geändert werden; das eigentliche Modell kann – da es unabhängig vom Framework ist – weiter verwendet werden.

Der Extension Builder ist besonders für Agenturen hilfreich, die oft Extensions entwicklen müssen, da er einerseits den Entwicklungsprozess beschleunigt und andererseits die Einarbeitung für Kollegen, die nicht an der Entwicklung beteiligt waren, erleichtert. Da das Projekt derzeit nur in der knapp bemessenen Freizeit der Projektmitglieder weiterentwickelt wird, würde sich das Team über Sponsoring für bestimmte Features oder für die allgemeine Beschleunigung der Entwicklung sehr freuen.