-
Enabling future enhancements for the adminpanel without having to make breaking changes for existing module providers is a key ingredient for providing a future proof extensible solution. Using single big interfaces that need to change on updates break backwards compatibility and do not provide sufficient feature encapsulation. The adminpanel APIs have been refactored to use a composition pattern to allow modules more flexibility. Modules can now only implement the interfaces they need instead of implementing all functionality. For example an adminpanel module that only provides page related settings does no longer have to implement the getContent method. Small interfaces have been provided as building blocks for modules with rich functionality. Easy addition of new interfaces that _can_ (not must) be implemented allow future improvements. Additionally the API has been modified to allow a more object-oriented approach using simple DTOs instead of associative arrays for better type-hinting and a better developer experience. Storing and rendering data have been separated in two steps allowing to completely disconnect the rendered adminpanel from the current page. This is a preparation for a standalone adminpanel that can be implemented separately. Resolves: #86003 Releases: master Change-Id: I88236a86e612dee9085b9f6ad7da34f90770d5ed Reviewed-on: https://review.typo3.org/57987 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Benjamin Kott <benjamin.kott@outlook.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
d7ea9a75
