Splitting the admin class or how to stop violating the SRP

[greg0ire]

The AbstractAdmin class is huge, with many unrelated responsabilities. We need plans and ideas to make it smaller, or even make it disappear (and any other class that does not seem to have a precise, focused goal). This should lead by also splitting the AdminInterface into something.

For instance, we could start by moving all security-related methods to a new service, and create a new Twig method called admin_is_granted instead of having people call admin.is_granted directly.

Also, I think we should think very hard before merging any new methods / properties in the Admin class. For instance, I probably should not have merged #3822 .

Of course, it will be quite hard to create components that are completely independent from the admin, so we should settle for tightly-coupled solutions like in #3791 , that should become less and less tighly coupled as we extract functionality into small services that we can inject into other, higher level services.

[greg0ire]

I think with that approach, it will be very clear what service is overriden thanks to debug:container --show-private

[greg0ire]

Tagging will be extremely easy to do with registerForAutoconfiguration(): https://github.com/symfony/symfony/blob/44b2f97dcd2ba10857dd545e424ad4f48c9dbea1/src/Symfony/Bundle/TwigBundle/DependencyInjection/TwigExtension.php#L154

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[VincentLanglet]

Closing due to lack of interest