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. nimcore rozwiązuje ten problem jako centralna biblioteka bazowa rodziny rozszerzeń NIM. Klasy abstrakcyjne, funkcje narzędziowe i wspólna konfiguracja znajdują się w jednym miejscu. Wszystkie zależne rozszerzenia NIM dziedziczą z nimcore i muszą implementować tylko swoją logikę biznesową.

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. nimcore wymusza jednolity standard. Wszystkie rozszerzenia NIM 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 wzorca nimcore: 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 nimcore. Wszystkie zależne rozszerzenia korzystają z tego natychmiast, bez konieczności dostosowywania każdego osobno. Przy aktualizacji do TYPO3 v12 z siedmioma rozszerzeniami NIM oszczędza to zwykle dwa do trzech dni roboczych programisty.

Architektura techniczna podąża za zasadą Shared Kernel

nimcore rejestruje się jako zwykłe rozszerzenie TYPO3 i jest deklarowane przez Composer jako zależność w zależnych rozszerzeniach. Plik ext_emconf.php rozszerzeń NIM wymienia nimcore jako required constraint. Przy instalacji rozszerzenia NIM nimcore jest automatycznie dociągane.

Wewnętrznie nimcore dostarcza 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 umożliwia definiowanie ustawień specyficznych dla rozszerzenia w jednolitym formacie, dostępnym w backendzie TYPO3 przez moduł ustawień.

Infrastruktura testowa jest również zgrupowana w nimcore: 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 nimcore wprowadza Breaking Change, wszystkie zależne rozszerzenia muszą zostać jednocześnie zaktualizowane. W praktyce oznacza to, że nimcore musi ś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 nimcore, a nimcore używa serwisu zdefiniowanego właściwie w rozszerzeniu A, powstaje cykl. Rozwiązaniem jest czysta zasada Dependency Inversion: nimcore definiuje interfejsy, które zależne rozszerzenia implementują. nimcore sam nie zna konkretnych implementacji.

Trzeci temat to kolejność autoload w Composer. Przy dużych instalacjach z 30 lub więcej rozszerzeniami kolejność autoloadingu może prowadzić do tego, że klasy nimcore nie są jeszcze dostępne, gdy ładowane jest zależne rozszerzenie. Rozwiązanie: w composer.json instalacji root zdefiniować nimcore jako pierwsze w install-order.

TYPO3 v12 działa, kompatybilność v13 zależy od warstwy abstrakcji Extbase

nimcore opiera się na frameworku Extbase i jest tym samym ściśle związany z jego stabilnością API. Pod TYPO3 v12 aktualna wersja działa stabilnie. Dla v13 potrzebne są dostosowania, gdy rdzeń TYPO3 zmienia interfejsy Extbase lub restrukturyzuje konfigurację Dependency Injection.

Ponieważ nimcore jest produktem niszowym dla rodziny rozszerzeń NIM, dalszy rozwój zależy bezpośrednio od opiekuna. Zespoły stawiające na nimcore powinny sforkować kod źródłowy i utrzymywać go we własnym repozytorium, aby nie być zależnym od zewnętrznych 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.