nimcore dla TYPO3

Bez centralnej biblioteki bazowej rodziny rozszerzeń generują zduplikowany kod i zduplikowane błędy

Agencje TYPO3, które tworzą kilka powiązanych ze sobą rozszerzeń, stają przed problemem architektonicznym: każde rozszerzenie reimplementuje funkcje pomocnicze takie jak odczyt konfiguracji, rejestracja modułów backendowych, obsługa FAL i logowanie. Przy pięciu rozszerzeniach oznacza to pięć kopii tych samych funkcji pomocniczych, pięć miejsc na ten sam błąd. Rozwiązaniem jest centralna biblioteka bazowa: klasy abstrakcyjne, funkcje narzędziowe i wspólna konfiguracja znajdują się w jednym miejscu, a wszystkie zależne rozszerzenia dziedziczą z niej i muszą implementować tylko swoją logikę biznesową. nimcore to z nazwy taka biblioteka dla rozszerzeń NIM, ale nie jest opublikowana ani w TER, ani na Packagist, ani na GitHubie, dlatego nie da się sprawdzić, co zawiera.

Ten wzorzec jest rzadki w ekosystemie TYPO3, ale dobrze znany w architekturze oprogramowania: Shared Kernel, który hermetyzuje horyzontalne aspekty (logowanie, konfigurację, modele bazowe), podczas gdy rozszerzenia pionowe (odtwarzacz audio, galeria, slider) przejmują logikę biznesową.

Typowe scenariusze dotyczą agencji z własnymi portfoliami rozszerzeń

Scenariuszem głównym jest agencja utrzymująca zestaw czterech do dziesięciu własnych rozszerzeń TYPO3. Bez wspólnej biblioteki bazowej rozszerzenia rozchodzą się: jedno używa GeneralUtility::makeInstance, drugie kontenera DI, trzecie ma własną konfigurację loggera. Wspólna biblioteka bazowa wymusza jednolity standard: wszystkie rozszerzenia używają tych samych abstrakcyjnych klas kontrolerów, tej samej obsługi wyjątków i tej samej struktury konfiguracji.

Drugim scenariuszem są wewnętrzne zespoły deweloperskie, które rozszerzają swoją instancję TYPO3 kilkoma własnymi rozszerzeniami. Zamiast traktować każde rozszerzenie jako izolowany pakiet, zespoły mogą zbudować własną bibliotekę Core według tego wzorca: wspólne modele bazowe, wspólne klasy modułów backendowych, wspólne fixture testowe. Redukuje to nakład utrzymania i obniża próg wejścia dla nowych programistów, którzy muszą nauczyć się tylko jednej architektury.

Trzeci scenariusz to wersjonowanie przy aktualizacjach. Gdy rdzeń TYPO3 zmienia API używane w pięciu rozszerzeniach, wystarczy pojedyncza aktualizacja w bibliotece bazowej. Wszystkie zależne rozszerzenia korzystają z tego natychmiast, bez konieczności dostosowywania każdego osobno. Przy aktualizacji do TYPO3 v12 z siedmioma zależnymi rozszerzeniami oszczędza to zwykle dwa do trzech dni roboczych programisty.

Architektura techniczna podąża za zasadą Shared Kernel

Taka biblioteka bazowa rejestruje się jako zwykłe rozszerzenie TYPO3 i jest deklarowana przez Composer jako zależność w zależnych rozszerzeniach; ich plik ext_emconf.php wymienia ją jako required constraint. Przy instalacji zależnego rozszerzenia biblioteka jest automatycznie dociągana.

Wewnętrznie dostarcza ona klasy abstrakcyjne dla kontrolerów, repozytoriów i modeli, które poprawnie inicjalizują framework Extbase TYPO3. Klasy narzędziowe hermetyzują powtarzające się zadania: odczyt konfiguracji TypoScript, rozwiązywanie referencji FAL, rejestracja toolbarów backendowych, standaryzowane wyświetlanie Flash-Messages. Centralny rejestr konfiguracji może umożliwiać definiowanie ustawień specyficznych dla rozszerzenia w jednolitym formacie, dostępnym w backendzie TYPO3 przez moduł ustawień.

Tam można też zgrupować infrastrukturę testową: klasy bazowe TestCase, loader fixture i narzędzia mockingu, które ułatwiają pisanie testów funkcjonalnych dla rozszerzeń Extbase. Obniża to próg pisania testów, ponieważ setup nie musi być konfigurowany od nowa w każdym rozszerzeniu.

Częste problemy powstają przy konfliktach wersji i zależnościach cyklicznych

Największym ryzykiem architektury Shared Kernel jest przymus wydania w lockstep: gdy biblioteka bazowa wprowadza Breaking Change, wszystkie zależne rozszerzenia muszą zostać jednocześnie zaktualizowane. W praktyce oznacza to, że musi ona ściśle przestrzegać semantic versioning. Wersje minor nie mogą zmieniać publicznych interfejsów, a wydania major wymagają instrukcji migracji.

Drugi problem: cykliczne zależności. Gdy rozszerzenie A zależy od biblioteki bazowej, a biblioteka używa serwisu zdefiniowanego właściwie w rozszerzeniu A, powstaje cykl. Rozwiązaniem jest czysta zasada Dependency Inversion: biblioteka definiuje interfejsy, które zależne rozszerzenia implementują, i sama nie zna konkretnych implementacji.

Trzeci temat to kolejność ładowania rozszerzeń. Przy dużych instalacjach z 30 lub więcej rozszerzeniami zależne rozszerzenie może oczekiwać konfiguracji biblioteki bazowej, zanim zostanie ona załadowana. Rozwiązanie: wpisać bibliotekę w sekcji require pliku composer.json każdego rozszerzenia, które z niej korzysta. Z tych zależności TYPO3 w trybie Composer wyprowadza kolejność ładowania; same klasy autoloader Composera ładuje i tak dopiero przy pierwszym użyciu.

Rozszerzenie nimcore nie jest publicznie dostępne, wzorzec można wdrożyć samodzielnie

Rozszerzenie nimcore nie jest opublikowane ani w TER, ani na Packagist, ani na GitHubie, dlatego nie da się sprawdzić, które wersje TYPO3 obsługuje. Biblioteka bazowa oparta na Extbase jest ściśle związana z jego stabilnością API: gdy rdzeń TYPO3 zmienia interfejsy Extbase lub konfigurację Dependency Injection, trzeba ją dostosowywać przy każdej wersji głównej.

Ponieważ nimcore nie jest rozwijane publicznie, każdy dalszy rozwój zależy od tych, którzy dysponują kodem źródłowym. Zespoły, które używają nimcore w istniejących projektach, powinny utrzymywać kod źródłowy we własnym repozytorium, aby nie być zależnymi od cudzych cykli wydań. Gosign przy portfoliach własnych rozszerzeń generalnie zaleca budowanie architektury Shared Kernel wewnętrznie i utrzymywanie jej pod własną kontrolą, zamiast polegać na zewnętrznych bibliotekach Core.