Epic #84044: Admin Panel Rework
Refactor admin panel module registration
Currently the class `AdminPanelView` is one big class containing all code logic for rendering the admin panel.
For better extendibility and cleaner code, the modules should be extracted to own classes, an interface for a module should be added and a flexible registration possibility should be provided.
In a first step, the interface will be declared as internal to make it possible to change the interface during the admin panel rework.
[FEATURE] New API for the admin panel
The admin panel consisted of one big god class
that contained the complete rendering.
The hook to extend the admin panel only allowed to
add content but not to add new modules (with expandable
The code has been refactored as a first step for a more
flexible admin panel:
- All modules are now rendered by a class per module
- Modules have an interface
- Modules can be registered in ext_localconf (and overwritten) using
the dependency ordering service for priority
- All new classes are strictly typed
Reviewed-by: Frank Naegler <email@example.com>
Tested-by: TYPO3com <firstname.lastname@example.org>
Tested-by: Frank Naegler <email@example.com>
Reviewed-by: Benni Mack <firstname.lastname@example.org>
Tested-by: Benni Mack <email@example.com>