Extension Builder dla TYPO3

Extension Builder to narzędzie scaffoldingu, bez którego żaden deweloper TYPO3 nie jest naprawdę produktywny

Extension Builder od ponad dziesięciu lat jest oficjalnym narzędziem, którym deweloperzy tworzą w TYPO3 nowe rozszerzenia z niczego. Kto potrzebuje rozszerzenia Extbase z Domain-Model, Repository, Controller i modułem backendowym, otrzymuje przez Extension Builder wizualny edytor, który z diagramu domeny podobnego do UML generuje kompletny kod boilerplate: konfigurację TCA, schemat SQL, ext_localconf, stuby kontrolerów, szablony Fluid, pliki językowe. Dla agencji i zespołów produktowych, które regularnie dostarczają własne rozszerzenia, narzędzie pozostaje najszybszą drogą od koncepcji do pierwszego działającego prototypu.

Grupą docelową są zespoły deweloperskie TYPO3 w agencjach i w obszarze inhouse, które poza Site Packages odwzorowują w TYPO3 własną logikę biznesową. Typowe są rozszerzenia dla katalogów produktów, zarządzania wydarzeniami, portali pracy, portali klientów lub branżowych struktur danych. Bez Extension Builder każde z tych rozszerzeń musiałoby rosnąć ręcznie z pustego katalogu, z ryzykiem, że struktura odchyli się od schematu core TYPO3 i pęknie przy następnym upgrade.

Typowe scenariusze zastosowania

Pierwszym scenariuszem jest prototyp portalu klienta. Producent maszyn z 2000 części zamiennych potrzebuje rozszerzenia, które udostępnia w backendzie rodziny produktów, produkty i dokumentacje jako własne struktury danych. Extension Builder tworzy w mniej niż 30 minutach kompletne rusztowanie: TCA, repozytoria, kontrolery, widok listy i detalu. Zespół natychmiast rozpoczyna logikę biznesową zamiast boilerplate.

Drugim scenariuszem jest sytuacja szkoleniowa i wdrożeniowa. Deweloper, który po raz pierwszy buduje rozszerzenie TYPO3, uczy się przez wygenerowany scaffold konwencji frameworka, bez gubienia się w dokumentacjach. Wygenerowany kod nie jest doskonały, ale jest idiomatyczny i pokazuje, jak jest pomyślany Extbase.

Trzecim scenariuszem jest migracja istniejących struktur danych. Kto musi postawić z starego eksportu CSV nowe rozszerzenie TYPO3 z dziesięcioma entytami, może wyklikać model domeny w Extension Builder, wyeksportować i następnie wypełnić wygenerowany kod komendą importu. To oszczędza kilka dni osobowych w stosunku do ręcznej budowy.

Czwartym scenariuszem jest standaryzacja w puli agencyjnej. Usługodawca z 15 deweloperami TYPO3 chce zapewnić, że każde nowe rozszerzenie ma ten sam podstawowy układ. Extension Builder wymusza ten układ przez generowanie, a własne szablony dla generatora kodu dbają o to, aby styl kodu, nagłówki licencyjne i struktura katalogów pozostawały identyczne między projektami.

Architektura techniczna

Extension Builder to klasyczne rozszerzenie backendowe TYPO3 z własnym interfejsem użytkownika. W backendzie pojawia się moduł, w którym model domeny jest tworzony przez interfejs drag-and-drop: entyty jako skrzynki, properties jako pola, relacje jako linie. Przy eksporcie jest persistowany schemat JSON, z którego generator zapisuje kompletny kod rozszerzenia.

Instalacja odbywa się klasycznie przez Composer (friendsoftypo3/extension-builder). Rozszerzenie nie ma znaczenia produkcyjnego, należy do środowiska deweloperskiego i nie powinno być w ogóle aktywne w produkcji. Przy generowaniu Builder sięga do szablonów podobnych do Twig, które można w razie potrzeby dostosować projektowo, na przykład aby wymuszać własne style kodu lub odmienne nagłówki licencyjne.

Ważne, że Extension Builder nie opanowuje roundtripu: kto raz generuje, a potem rozszerza kod ręcznie, może wprawdzie otworzyć rozszerzenie w Builderze, ale w żadnym wypadku nie powinien generować ponownie, inaczej Builder nadpisze części ręcznie uzupełnionej logiki. W praktyce Builder jest używany jako jednorazowy krok scaffoldu, a potem rozszerzenie żyje w repozytorium Git.

Częste problemy i rozwiązania

Pierwszym problemem jest pułapka nadpisywania po pierwszym uruchomieniu generatora. Zespoły, które uruchamiają Buildera po raz drugi, aby dociągnąć pole, tracą własne zmiany kodu. Rozwiązaniem jest jasna reguła w zespole: Extension Builder jest używany raz, reszta to praca ręczna. Późniejsze zmiany pól odbywają się ręcznie w TCA, SQL i modelu.

Drugim problemem jest kompatybilność z nowoczesnymi konwencjami PHP. Generator nadal tworzy kod, który opiera się na starszych wersjach PHP i starszych konwencjach Extbase. Rozwiązaniem jest pass cleanup bezpośrednio po generowaniu: uzupełnianie deklaracji typów, ustawianie return-types, wprowadzanie readonly-properties, zastępowanie przestarzałych komentarzy adnotacji natywnymi atrybutami.

Trzecim problemem jest nierefleksyjne używanie jako cudu kodu. Niektóre zespoły oczekują, że Extension Builder dostarczy aplikację gotową do produkcji. Tego nie robi, dostarcza rusztowanie. Każda logika biznesowa, każda walidacja, każda koncepcja bezpieczeństwa pozostaje zadaniem deweloperki.

Czwartym problemem są przestarzałe wzorce backendowe w wygenerowanym kodzie. Dostarczone kontrolery używają czasem jeszcze deprecated wzorców Extbase, które w aktualnym TYPO3 generują deprecation-warnings. Rozwiązaniem jest krok lint bezpośrednio po generowaniu, który sprawdza kod wobec aktualnych standardów kodowania i oznacza brakujące deklaracje typów lub przestarzałe adnotacje. Nowoczesne pipeline’y łączą ten krok z automatycznym przepisywaniem kodu przez Rector, aby nakład cleanupu był możliwie mały.

Migracja i kompatybilność wersji

Extension Builder jest oficjalnie dostępny dla TYPO3 v11 i v12 i jest dalej utrzymywany przez Friends of TYPO3. Dla TYPO3 v13 istnieje zaktualizowana wersja, która podąża za nowymi konwencjami Extbase. Zespoły, które aktualizują istniejące rozszerzenia, z reguły nie potrzebują już Buildera, upgrade przebiega przez Upgrade Wizards w Install Tool i ręczne dostosowania.

Ciekawsze jest strategiczne spojrzenie: w czasach, gdy generatywna AI potrafi tworzyć kompletne szkielety rozszerzeń wraz z logiką biznesową z jednego promptu, wizualny Builder traci część swojej pierwotnej przewagi. Gosign łączy oba światy: dla standardowych scaffoldów z wieloma entytami Builder pozostaje efektywny, dla wymagających rozszerzeń z logiką specyficzną dla domeny generujemy kod bezpośrednio z briefingu merytorycznego ze wsparciem AI i oszczędzamy w porównaniu do klasycznej budowy ręcznej do 80 procent czasu rozwoju przy jednocześnie wyższej jakości kodu.