Sonataadminbundle: ControllerTrait::render() is final since Symfony 3.4

[javiereguiluz]

Seen while upgrading a Symfony app to 3.4:

The "Symfony\Bundle\FrameworkBundle\Controller\ControllerTrait::render()" method
is considered final since version 3.4. It may change without further notice as of
its next major version. You should not extend it from
"Sonata\AdminBundle\Controller\CRUDController".

[greg0ire]

This is reopened because the solution I found is not good enough: the plan was to rename the method, and to use __call to simulate several signatures, but this does not work with public methods, as illustrated here: https://3v4l.org/pPBhA

[greg0ire]

I might have a horrible solution, resorting to 2 parent classes for AbstractAdmin + class aliases dependent on the current sf controller class

[greg0ire]

A saner solution might be to drop sf 2 before adding support for sf 4: maintaining 3 major versions of Symfony is maybe not the best idea. That would imply releasing a major version of the admin bundle.

[hanzi]

Another option would be to drop \Symfony\Bundle\FrameworkBundle\Controller\Controller as a base class for CRUDController.

The FrameworkBundle's Controller has no inherent function in the Symfony framework. It's mainly a collection of helper methods that you do not actually require for having a controller. In order to mostly maintain backwards compatibility, those methods could also be copied or wrapped somehow.

We would still break checks like $controller instanceof Controller but given the fact that you cannot really rely on every controller inheriting from that class, I would not consider that a promise for backwards compatibility.

[greg0ire]

Thanks a lot for your answer.
the instanceof is not really worrying, but the BC would could still be very tricky to maintain given that the code changes from one version of symfony to another: not sure copying it would be the solution (and what version should we copy?) Using composition + proxy methods that have the old interface might be a solution though.

[hanzi]

BC would not require keeping up to date with future changes to the original Controller class.

We only have to make sure that what's available today still works in the future. Which probably means supporting methods all the way up to Symfony 3.4.

Most of the methods merely wrap calls like $this->container->get('foo')->bar(), so there shouldn't be much compatibility issues anyway.

[greg0ire]

I might give it a try unless you beat me to it, feel free to anyway!

[hanzi]

Actually, there might be a slightly better option:

Since Symfony 3.3 the Controller is an empty shell that includes the ControllerTrait which now contains all the helper methods.

Traits are great in that regard, since we can say use ControllerTrait { ControllerTrait::render as originalRender; } and have exactly what we want.

We still need a BC polyfill, but that would only need to support Symfony 2.8, 3.0, 3.1 and 3.2. Which means we would still be up to date on any new fancy methods in the ControllerTrait in future versions.

[hanzi]

I'll give it a shot!