Skip to content

[Bridge\Doctrine][FrameworkBundle] Deprecate some remaining uses of ContainerAwareTrait #24409

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 5, 2017

Conversation

nicolas-grekas
Copy link
Member

Q A
Branch? 3.4
Bug fix? no
New feature? no
BC breaks? no
Deprecations? yes
Tests pass? yes
Fixed tickets -
License MIT
Doc PR -

With this PR, the last two remaining uses of ContainerAwareTrait will be Symfony\Component\HttpKernel\Bundle\Bundle and Symfony\Bundle\FrameworkBundle\Controller\Controller.
For Bundle, I think it's legitimate, for Controller, I think it's not, but that we should wait for 4.1 before considering its deprecation, alongside with ContainerAwareCommand (maybe).

private $httpPort;
private $httpsPort;

public function __construct(ContainerInterface $container = null, $httpPort = null, $httpsPort = null)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about passing a UrlGenerator here instead of a container?

use ContainerAwareTrait;
protected $container;

public function __construct(ContainerInterface $container = null)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as for the redirect one. What about passing a Twig and an Engine here instead. By the way, we should probably also deprecate the templating path.

@nicolas-grekas
Copy link
Member Author

Comments addressed.

Status: needs review

private $templating;
private $twig;

public function __construct(EngineInterface $templating = null, Environment $twig = null)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would put Twig first as the other one will be deprecated.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

*/
public function setContainer(ContainerInterface $container = null)
{
@trigger_error(sprintf('The "%s()" method is deprecated since version 3.4 and will be removed in 4.0. Inject a PSR-11 container using the constructor instead.', __METHOD__), E_USER_DEPRECATED);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

huh? the constructor does not accept a container.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

*/
public function setContainer(SymfonyContainerInterface $container = null)
{
@trigger_error(sprintf('The "%s()" method is deprecated since version 3.4 and will be removed in 4.0. Inject a PSR-11 container using the constructor instead.', __METHOD__), E_USER_DEPRECATED);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

abstract ManagerRegistry does not accept a container in its argument. only \Doctrine\Bundle\DoctrineBundle\Registry does. also https://github.com/doctrine/DoctrineBundle/blob/master/Registry.php#L41 still calls the deprecated method

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'll do the PR next on DoctrineBundle.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's wait for the PR on DoctrineBundle before merging this one.

<argument>%request_listener.https_port%</argument>
</service>

<service id="Symfony\Bundle\FrameworkBundle\Controller\TemplateController" public="true">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this service belongs in routing.xml. It has nothing to do with routing?!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These services are useful only when a route references them, that's why I made it this way.
Did I miss something else?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't one use them without routing using fragments?

@nicolas-grekas
Copy link
Member Author

Here is the doctrine-bundle PR:
doctrine/DoctrineBundle#710

} elseif ($this->container->has('twig')) {
$response = new Response($this->container->get('twig')->render($template));
if ($this->templating) {
$response = $this->templating->renderResponse($template);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the interface of the component, that you used in the typehint does not have the renderResponse method

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch, fixed, thanks

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have done the opposite. Not relying on the interface from frameworkbundle and create the response by hand as done for Twig.


/**
* @deprecated since version 3.4, to be removed in 4.0 alongside with the ContainerAwareInterface type.
* @final since version 3.4
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can't it just be deprecated?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so: @deprecated doesn't trigger a deprecation when a method is overridden but the parent is not called. @final does.


public function testTemplating()
{
$templating = $this->getMockBuilder('Symfony\Bundle\FrameworkBundle\Templating\EngineInterface')->getMock();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could use ::class

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

} elseif ($this->container->has('twig')) {
$response = new Response($this->container->get('twig')->render($template));
if ($this->templating) {
$response = $this->templating->renderResponse($template);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have done the opposite. Not relying on the interface from frameworkbundle and create the response by hand as done for Twig.

$response = new Response($this->container->get('twig')->render($template));
if ($this->templating) {
$response = $this->templating->renderResponse($template);
} elseif ($this->twig) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's check Twig first :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That'd be bc breaking changes...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this one, but not the other one.

@nicolas-grekas
Copy link
Member Author

@fabpot comments addressed

Status: needs review

@fabpot
Copy link
Member

fabpot commented Oct 5, 2017

Thank you @nicolas-grekas.

@fabpot fabpot merged commit df9c874 into symfony:3.4 Oct 5, 2017
fabpot added a commit that referenced this pull request Oct 5, 2017
…ining uses of ContainerAwareTrait (nicolas-grekas)

This PR was merged into the 3.4 branch.

Discussion
----------

[Bridge\Doctrine][FrameworkBundle] Deprecate some remaining uses of ContainerAwareTrait

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | yes
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

With this PR, the last two remaining uses of ContainerAwareTrait will be `Symfony\Component\HttpKernel\Bundle\Bundle` and `Symfony\Bundle\FrameworkBundle\Controller\Controller`.
For Bundle, I think it's legitimate, for Controller, I think it's not, but that we should wait for 4.1 before considering its deprecation, alongside with `ContainerAwareCommand` (maybe).

Commits
-------

df9c874 [Bridge\Doctrine][FrameworkBundle] Deprecate some remaining uses of ContainerAwareTrait
@nicolas-grekas nicolas-grekas deleted the psr11 branch October 5, 2017 14:36
fabpot added a commit that referenced this pull request Oct 5, 2017
…of ContainerAwareInterface (nicolas-grekas)

This PR was merged into the 4.0-dev branch.

Discussion
----------

[Bridge\Doctrine][FrameworkBundle] Remove legacy uses of ContainerAwareInterface

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | yes
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

Related to #24409

Commits
-------

3b1b8cf [Bridge\Doctrine][FrameworkBundle] Remove legacy uses of ContainerAwareInterface
This was referenced Oct 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants