Skip to content

Updated the application to Symfony 3.3.0 #562

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

Closed
wants to merge 16 commits into from
Closed

Updated the application to Symfony 3.3.0 #562

wants to merge 16 commits into from

Conversation

javiereguiluz
Copy link
Member

This finishes #483 and uses the all the new 3.3 features for DI services.

@javiereguiluz
Copy link
Member Author

Commands still extend from ContainerAwareCommand and get services with $container->get() What can we do about that? Thanks!

@weaverryan
Copy link
Member

@javiereguiluz I'm a bit undecided about commands (what to officially recommend). In the docs, I've left the $this->getContainer()->get() in the commands, and just mentioned that you can use DI normally now that these are services. So, the answer would be, if you want, you can absolutely add a __construct() method to these commands and use normal DI.

AppBundle\Controller\:
resource: '../../src/AppBundle/Controller'
public: true
tags: ['controller.service_arguments']
Copy link
Member

Choose a reason for hiding this comment

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

IMO this is not needed if our controllers extend from Controller so it's already auto-tagged.

Copy link
Member

Choose a reason for hiding this comment

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

You're right... but it's nice to be consistent with the official project skeleton

@yceruto
Copy link
Member

yceruto commented May 22, 2017

We could use AbstractController instead?

resource: '../../src/AppBundle/*'
# you can exclude directories or files
# but if a service is unused, it's removed anyway
exclude: '../../src/AppBundle/{Entity,Repository}'
Copy link
Member

Choose a reason for hiding this comment

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

you should also exclude Controller here IMO. It is a waste of resources to include them all here to overwrite them all just below

$locales: '%app_locales%'
$defaultLocale: '%locale%'

Twig_Extensions_Extension_Intl:
public: false
Copy link
Member

Choose a reason for hiding this comment

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

public: false is useless due to the default

$locales: '%app_locales%'
$defaultLocale: '%locale%'

Twig_Extensions_Extension_Intl:
public: false
class: Twig_Extensions_Extension_Intl
tags:
Copy link
Member

Choose a reason for hiding this comment

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

the tag is useless to, as you have autoconfigure: true in the defaults of the files

@@ -42,7 +42,6 @@ framework:
engines: ['twig']
default_locale: "%locale%"
trusted_hosts: ~
trusted_proxies: ~
session:
handler_id: session.handler.native_file
save_path: "%kernel.root_dir%/../var/sessions/%kernel.environment%"
Copy link
Member

@yceruto yceruto May 22, 2017

Choose a reason for hiding this comment

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

'%kernel.project_dir%/var/sessions/%kernel.environment%' ?

@@ -42,7 +42,6 @@ framework:
engines: ['twig']
default_locale: "%locale%"
Copy link
Member

Choose a reason for hiding this comment

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

Single quote in yamls?

@@ -86,7 +87,7 @@ public function newAction(Request $request)
// However, we explicitly add it to improve code readability.
// See https://symfony.com/doc/current/best_practices/forms.html#handling-form-submits
if ($form->isSubmitted() && $form->isValid()) {
$post->setSlug($this->get('slugger')->slugify($post->getTitle()));
$post->setSlug($slugger->slugify($post->getTitle()));

$entityManager = $this->getDoctrine()->getManager();
Copy link
Member

@yceruto yceruto May 22, 2017

Choose a reason for hiding this comment

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

Also we could inject em for each action if needed https://github.com/symfony/symfony-docs/pull/7933/files#diff-e530d0758aab398d19d2ed98bf9d6715R107 or maybe better if it's used frequently inject it into __constructor?

Copy link
Member

Choose a reason for hiding this comment

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

Or why not extend from AbstractController and keep this as it?

Copy link
Member

Choose a reason for hiding this comment

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

FYI - the recommended practice for getting the EM is being discussed here: symfony/symfony-docs#7933 (comment)

@javiereguiluz
Copy link
Member Author

I've updated commands to use DI too. Please let me know other places where we can use the new features. Thanks!

$entityManager = $this->getDoctrine()->getManager();
$entityManager->persist($post);
$entityManager->flush();
$em->persist($post);
Copy link
Member

Choose a reason for hiding this comment

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

$em missing injection?

private $entityManager;
private $mailer;

Choose a reason for hiding this comment

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

missing $emailSender property

@@ -134,19 +135,16 @@ public function showAction(Post $post)
* @Route("/{id}/edit", requirements={"id": "\d+"}, name="admin_post_edit")
* @Method({"GET", "POST"})
*/
public function editAction(Post $post, Request $request)
public function editAction(Request $request, EntityManagerInterface $em, Post $post, Slugger $slugger)

Choose a reason for hiding this comment

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

So we order arguments this way: Request>$em>entities>other dependencies?

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 don't know. To me Request and the Doctrine thing look better at the beginning. But this is just an opinion.

Choose a reason for hiding this comment

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

I see Doctrine as a regular dependency so I would put it at the end.
Anyway we can decide this later in symfony/symfony-docs#7933 (comment), let's keep it as is for now :)

@javiereguiluz
Copy link
Member Author

Ready for the final review before merge. Thanks!

@@ -47,6 +47,7 @@ public function load(ObjectManager $manager)

$post->setTitle($title);
$post->setSummary($this->getRandomPostSummary());
// TODO: fix this 'slugger' call

Choose a reason for hiding this comment

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

Planed for another pr ?

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! Maybe I'm too naive, but I'm trying to do this and it doesn't work:

class PostFixtures extends AbstractFixture implements DependentFixtureInterface, ContainerAwareInterface
{
    use ContainerAwareTrait;
    use FixturesTrait;

    private $slugger;

    public function __construct(Slugger $slugger)
    {
        $this->slugger = $slugger;
    }

    // ...
}

Copy link
Member

Choose a reason for hiding this comment

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

Well, fixtures are instantiated by Doctrine, so you cannot do autowiring there

Copy link
Member Author

Choose a reason for hiding this comment

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

Yet another exception for where autowiring works. I don't like it.

Copy link
Member

Choose a reason for hiding this comment

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

Autowiring works for services. Fixture classes have nothing to do with the DI container

@weaverryan
Copy link
Member

About fixtures, the fixtures bundle should probably be updated to allow for fixtures to be a tagged service. The fact that you can't use autowiring for them is due to this shortcoming, which is with the bundle imo

$defaultLocale: '%locale%'

Twig_Extensions_Extension_Intl:
class: Twig_Extensions_Extension_Intl
Copy link
Member

Choose a reason for hiding this comment

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

If you upgrade to version 1.5.0 of Twig extensions, you can now use Twig\Extensions\IntlExtension (and so you won't need the class key

Copy link
Member Author

Choose a reason for hiding this comment

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

So nice! Thanks.

{
$entityManager = $this->getDoctrine()->getManager();
$posts = $entityManager->getRepository(Post::class)->findBy(['author' => $this->getUser()], ['publishedAt' => 'DESC']);
$posts = $em->getRepository(Post::class)->findBy(['author' => $user], ['publishedAt' => 'DESC']);
Copy link
Member

Choose a reason for hiding this comment

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

Personally, I still prefer $this->getUser(). In fact, in the docs, I've really been trying to continue to use all of the Controller shortcuts, except for $this->get() and $this->container->get(). So even type-hinting EntityManagerInterface instead of $this->getDoctrine()->getManager() is debatable.... as we've been discussing here: symfony/symfony-docs#7933 (comment).

Copy link
Member

Choose a reason for hiding this comment

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

Also I prefer $this->getDoctrine()->getRepository() shortcut if $em is not needed :)

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 reverted EntityManagerInterface and UserInterface autowiring.

@@ -70,10 +72,10 @@ public function indexAction()
* to constraint the HTTP methods each controller responds to (by default
* it responds to all methods).
*/
public function newAction(Request $request)
public function newAction(Request $request, EntityManagerInterface $em, UserInterface $user = null, Slugger $slugger)
Copy link
Member

Choose a reason for hiding this comment

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

Here's a good reason why I don't prefer the UserInterface type-hint :). If anything, in the future, I'd prefer something like Security $security and then $security->getUser(). But I don't like the UserInterface type-hint at all. It's also not something that can be done in __construct() of services, adding to inconsistency.

@@ -65,7 +68,7 @@ public function indexAction($page, $_format)
* value given in the route.
* See https://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/converters.html
*/
public function postShowAction(Post $post)
public function postShowAction(Post $post, UserInterface $user = null)
Copy link
Member

Choose a reason for hiding this comment

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

Remove this too

{
return [
'comment.created' => 'onCommentCreated',
];
Copy link
Member

Choose a reason for hiding this comment

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

Do you want to use Events::COMMENT_CREATED?

{
$this->formatConverter = new MomentFormatConverter();
$this->formatConverter = $converter;
Copy link
Member

Choose a reason for hiding this comment

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

Hey, this is a cool benefit of the new system :). There is no longer any extra work to do things correctly :)

@@ -36,5 +36,7 @@ script:
- ./bin/console lint:yaml @CodeExplorerBundle
# this checks that the Twig template files contain no syntax errors
- ./bin/console lint:twig app/Resources @CodeExplorerBundle
# this checks that the XLIFF translations contain no syntax errors
- ./bin/console lint:xliff app/Resources
Copy link
Contributor

Choose a reason for hiding this comment

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

What about more specific app/Resources/translations? We have translations only in that folder

$defaultLocale: '%locale%'


Twig\Extensions\IntlExtension: ~
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it necessary? Where is it used?

Copy link
Member Author

Choose a reason for hiding this comment

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

If I remove this service definition, I see this error:

localizeddate-filter

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, what about adding a small note to this service definition where say it's used by localizeddate filter in Twig templates?

private $entityManager;
private $mailer;
private $emailSender;
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd add @param string annotation since $emailSender does not have type hint and can't be resolved by IDE.

Copy link
Member Author

Choose a reason for hiding this comment

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

You are right ... but at the same time, the type-hint is useful for objects or arrays of objects. In this case, even if the IDE knows this is a string ... there's nothing to complete or help us, right?

composer.json Outdated
@@ -29,8 +29,8 @@
"symfony/monolog-bundle" : "^3.0",
"symfony/polyfill-apcu" : "^1.0",
"symfony/swiftmailer-bundle" : "^2.3",
"symfony/symfony" : "^3.2",
"twig/extensions" : "^1.3",
"symfony/symfony" : "3.3.0-RC1",
Copy link
Contributor

Choose a reason for hiding this comment

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

Now we can use stable 3.3.0

@javiereguiluz javiereguiluz changed the title Updated the application to Symfony 3.3.0 RC1 Updated the application to Symfony 3.3.0 May 30, 2017
@javiereguiluz
Copy link
Member Author

javiereguiluz commented May 30, 2017

After upgrading to 3.3.0 final, I see these deprecations:

symfony-3-3-deprecations

I've reported the issue on symfony/symfony#22951

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants