- Official Post
Hallo,
dieses Thema stellt die Fortführung von
dar. Nachdem wir in WoltLab Suite 5.5 die Unterstützung für HTTP-Antworten auf Basis von PSR-7 integriert haben, werden wir die Unterstützung mit WoltLab Suite 6.0, wie geplant, weiter ausbauen.
Beginnend mit WoltLab Suite 6.0 besteht eine Unterstützung für PSR-15-basierte Controller und Middlewares, die in einem ersten Schritt sowohl die AbstractActions, als auch die AbstractDatabaseObjectActions („DBOAction“) ablösen sollen, also alles was primär mit JSON oder Redirects arbeitet. Die AbstractPage und AbstractForm bleiben erst einmal so wie sie sind, da der Mehrwert der Umstellung dort zum einen geringer ist und zum anderen die bekannten alten Events („readParameters“, „readData“ und co) deutlich stärker verbreitet sind, als es bei AbstractAction oder DBOAction der Fall ist.
Neben dem bekannten AJAX-basierten Zugriff auf die DBOActions via AJAXProxyAction, ist auch das Konzept der DBOAction an sich als Auslaufmodell zu verstehen. Die DBOActions leiden praktisch alle darunter, dass diese im Laufe der Zeit immer größer und damit immer unübersichtlicher werden. In vielen Fällen sind die DBOActions auch nicht wirklich wiederverwendbar, da diese oftmals fest auf globalen Zustand (bspw. WCF::getUser()) zugreifen, nur dann korrekt funktionieren, wenn zuvor ->validateAction() aufgerufen wird – was möglicherweise unerwünschte Berechtigungsprüfungen vornimmt und damit die programmatische Verwendung verhindert – und für die programmatische Verwendung mitunter auch Nebeneffekte haben, die nicht immer erwünscht sind – etwa die Registrierung der FloodControl für eine Aktion, die der Benutzer nicht selbst angestoßen hat.
Stattdessen gibt es zukünftig sogenannte „Commands“, die explizit wiederverwendbar entwickelt werden, nur explizit übergebene Werte nutzen und annehmen, dass nur gültige Werte übergeben werden. Etwaige Berechtigungs- oder semantische Prüfungen, wie die Zensurfunktion müssen vorab vom Controller vorgenommen werden. An passenden Stellen feuern die Commands selbstständig passende Events auf Basis der Event-Klassen von WoltLab Suite 5.5. Ein generisches Event wie finalizeAction ist nicht vorgesehen.
Weitere Details haben wir in der Dokumentation in diesen Abschnitten erklärt:
- Application Boot: https://docs.woltlab.com/6.0/migration/…pplication-boot
- Request Processing: https://docs.woltlab.com/6.0/migration/…uest-processing
„Lesenswerte“ PRs sind folgende:
#5176 hat zwar nicht unmittelbar mit dem Request-Processing zu tun, zeigt aber die Validierung strukturierte Daten mittels Valinor recht gut. Selbiges gilt für #5117, dieser zeigt die Verwendung von Commands und Events.
Naturgemäß kann die Dokumentation und auch dieser Beitrag nicht alle Fragen klären. Entsprechend stehen wir hier im Thema für (konzeptionelle) Rückfragen zu „best practices“ zur Verfügung.
