A TYPO3 több mint egy CMS
Üzleti alkalmazások építése a TYPO3 backendjével.
Csak egy másik nézőpontot szeretnék kínálni.
A DevDays a befejezetlen ötletek helye — egy kísérlet, néhány döntés és pár dolog, ami nem működött. Ez nem termékbejelentés.
Vidd magaddal a számodra hasznos ötleteket. Néha nem új eszközre van szükség — ugyanazt a dolgot kell más oldalról néznünk.
Tavaly karácsonykor…
…úgy döntöttem, a téli szünetet vibecodinggal töltöm — saját ERP-, időnyilvántartó és „minden” alkalmazást építek. Valódi projekttel, nem tutoriallal.
Nem előadást akartam írni. Azért ültem le, mert valami a munkában már régóta zavart.
Egy rendszer, ami nem követett minket.
Egy normál ERP-t használtunk. Az évek során a folyamataink változtak, a rendszer nem. A válaszok sokáig tartottak, a módosítások még tovább, és a szükséges riportokat nagyon nehéz volt megkapni.
Aztán abban a decemberben egyszerűen nem értem el őket. Ekkor hagytam abba a várakozást. A termék rendben volt — csak nem a miénk volt.
A fejlesztő bennem — és az ügyvezető bennem.
A fejlesztő azt akarja: uralni a kódot, az alkalmazás logikájára koncentrálni, és egy tesztelt, biztonságos keretrendszert, ami könnyen használható marad.
Az ügyvezető azt akarja: gyors eredmény, kevesebb licencköltség, semmi idő triviális alapokra — csak értékteremtés.
„Ez már létezik a TYPO3-ban.“
Az első ösztönöm a Symfony volt — kiváló, és a TYPO3 sok komponensét használja. Ez nem Symfony-kontra-TYPO3 harc. De minden képességnél, amit felsoroltam — admin felület, felhasználók & jogosultságok, modulnavigáció, rekordszerkesztés, listák, ütemezett feladatok, naplózás, dashboardok — ugyanaz a mondat tért vissza.
Miért építsem újra, amim már megvan, ami már tesztelt, és amit már ismerek?
És mivel építené ezt meg egyáltalán?
Az asszisztens, ami megírja — Gemini, Claude, ChatGPT, Kimi?
A keretrendszer alatta — Symfony, .NET, React?
Képzeld el, hogy a TYPO3 nem „csak“ egy CMS, hanem alkalmazáskeret.
Képzeld el a TYPO3-at tartalom nélkül. Nincsenek oldalak. Nincsenek tartalmi elemek. Nincs weboldal.
Mi marad?
Ha a válasz „semmi”, ez az előadás két perc múlva véget ér. Ahelyett, hogy találgatnánk, nézzük meg, hogyan épül fel valójában a TYPO3 — a Composer már elárulja a válasz nagy részét.
Hol vannak valójában a darabok.
A modern TYPO3 Composer-csomagok halmaza. Az oldalak mélyen a core-ban élnek; a tt_content — a tartalmi elemek — a frontend csomagból jönnek. A tartalom frontend-ügy; az oldalak core-ügy. Tehát a frontend az, amit elvehetünk.
Igen.
Technikailag semmi alapvető nem függ tőle. A függőség fordítva megy — a frontend függ a core-tól, nem a core a frontendtől. Ez nem hack; ez a szándék szerint működő architektúra.
Sok minden mégis használja.
# az alaprendszernek nem kell a frontend —
# de körülötte sok kód feltételezi, hogy ott van.
RuntimeException: No site configuration found for request
TypeError: a rendering context was expected
Error: a page id is required (pid)…
Két dolog egyszerre igaz: a TYPO3-nak erős backend-platformja van, amelyhez nem kell a frontend — és (még) nem elsődleges backend-only termékként tervezték. Nem hibás; a fő használati esetén kívül használva.
Dolgok, amiket a TYPO3 backendnél alapból megkapsz.
Ezek azok a dolgok, amikre egy fillért sem kell költened — a keretrendszer lefedi, tesztelt és biztonságos.
Identitás és hozzáférés.
Egy üzleti alkalmazásnak tudnia kell, ki vagy és mit láthatsz, módosíthatsz. Nem találtam ki auth-réteget — egy sok éven át, sokak által átnézett réteget bővítettem ki.
A TCA az adatszerkezetből használható backendet csinál.
Írd le egy táblát TCA-val, és a FormEngine működő szerkesztőfelületet készít — plusz a rekordlistát bármely táblához. Őszinte figyelmeztetés: ez nem váltja ki a UX-tervezést. De a különbség aközött, hogy gondolkodsz egy űrlapon és hogy űrlap-keretrendszert építesz, óriási.
A munka akkor is folyik, amikor senki sem figyel.
Éjszakai importok. Reakció, amikor megérkezik a pénz. Értesítés egy másik rendszernek. Az ütemezés és annak kezelése már létezik. Egy új modul pedig nem új architektúra — egy controller, egy repository, egy Fluid-sablon, egy TCA-definíció. Minden más el van döntve.
A technikai háttér.
Senki sem mutat be naplózást. De amikor reggel hétkor elromlik valami az élesben, ehhez a réteghez nyúlsz — és az első naptól ott volt.
Az alkalmazás-alaprendszer már létezik.
A TYPO3 közelebb enged az üzleti problémához. Négy alapréteg, egy vékony réteg a tetején — és ez a vékony réteg az egyetlen, ami valóban az üzletemről szól.
DigiTrack — TYPO3 14-en fut.
Nincs weboldal. Nincsenek tartalmi elemek. Csak a backend. Nem konferencia-prototípus — a cégünket futtatjuk rajta. Minden ismerős a TYPO3-ból jött; minden ismeretlen a mi üzletünk.
A backend maga az egész alkalmazás.
TYPO3-csomagokból építve.
A controllerek nem kérdezik le az adatbázist — az üzleti logika service-ekben, az adathozzáférés repository-kban él. Ezért a kódbázis egy évnyi gyors változás után is érthető.
Most a gyakorlati rész.
Egy akadály. Egy megkerülés. Három ötlet.
pid
Parent id-ként tárolva. Page id-ként kezelve. A jogosultságok, az oldalfa, a modulkontextus — mind ezt feltételezik. Egy oldalak nélküli alkalmazás ezen az egy mezőn akad el. A pid nem rossz; egy CMS-hez helyes.
A határ a szervezet, nem az oldal.
record.pid = 0 # nincs oldal, nincs fa
record.organisation = currentOrganisation # mentéskor egy DataHandler hook állítja be
# minden olvasás & írás a szervezetre szűkül — a fejlesztő nem felejtheti el.
Minden az oldalfán kívül tárolódik. A tulajdonlás a saját kontextusunkba kerül: egy CMS-ben a határ az oldal — a DigiTrackben a szervezet. Ez megkerülés, és annak is nevezem. De kicsi és jól körülhatárolt.
Három dolog, amit a backendhez építettünk.
1. Backend-felhasználó meghívás — egy kis kiterjesztés, amit közzéteszünk: szerkesztők meghívása e-mailben, a csoportjaik kiválasztásával, ahelyett, hogy kézzel hoznánk létre fiókokat.
2. Rendezhető listaoszlopok — nem csak azt választjuk ki, mely oszlopok látszanak, hanem rendezünk is szerintük. Jobb rálátás az adatokra.
3. Szűrők a listanézetben — TCA-alapú logika a szűrők definiálására és alkalmazására közvetlenül a listanézetben.
A sebesség kétélű.
Az MI és a kódügynökök segítségével több kódot építek kevesebb idő alatt. De most nagyon könnyű inkonzisztens, nem biztonságos vagy karbantarthatatlan kódot előállítani — a generált kód nem hoz magával biztonsági modellt. Egy gyenge alap következményei továbbra is drágák.
Egy jó alap a fejlesztési sebességet értékké alakítja.
A fejlesztés olcsóbb lesz, így több belső eszköz válik lehetővé. És mivel többet építhetünk, az alap minősége jobban számít, nem kevésbé.
A licencmegtakarítás nem a legnagyobb nyeremény volt.
Mi lenne, ha a TYPO3 backend a te alkalmazáskereted lenne?
Vedd el a weboldalt, és meglepően teljes alaprendszer marad. A TYPO3 CMS marad — ez az erőssége. De talán abbahagyhatjuk, hogy a backendre csak úgy tekintsünk, mint ahol a szerkesztők weboldalakat kezelnek.
Te mit építenél vele?
Köszönöm.