Tag: Dependency Injection

Symfony 3.3 landed this week.

My most used addition so far has been the new Dependency Injection features.

Even though I’m not a huge fan of autowiring, I do very much like the new autoconfigure.

This is a cool new feature that allows the removal of tags from your service definitions.

Note that I use my services like this:

# app/config/config.yml

imports:
    - { resource: parameters.yml }
    - { resource: security.yml }
    - { resource: services/console_command.yml }
    - { resource: services/command_handler.yml }
    - { resource: services/event_listener.yml }
    - { resource: services/event_subscriber.yml }
    - { resource: services/factory.yml }
    - { resource: services/queue.yml }
    - { resource: services/repository.yml }

# Other typical Symfony config.yml stuff continues here

The important thing here is that stuff is split up.

What this means is that I could adopt the new approach in phases.

I started with the event_subscriber service list, simply because that was the next thing I needed to work on.

If you don’t have a decent set of tests covering your services – and breaking said services would render you jobless – then please add tests before doing this.

Here’s my services/event_subscriber.yml configuration before the change:

services:

    a6.event.subscriber.registration_mailing:
        class: AppBundle\Event\Subscriber\RegistrationMailingSubscriber
        arguments:
            - "@twig"
            - "@mailer"
            - "%support_email_address%"
            - "%fos_user_from_email_name%"
        tags:
            - { name: kernel.event_subscriber }

    a6.event.subscriber.visitor_support_request:
        class: AppBundle\Event\Subscriber\VisitorSupportRequestSubscriber
        arguments:
            - "@logger"
            - "@a6.mailer"
            - "@doctrine.orm.default_entity_manager"
        tags:
            - { name: kernel.event_subscriber }

    a6.event.subscriber.member_support_request:
        class: AppBundle\Event\Subscriber\MemberSupportRequestSubscriber
        arguments:
            - "@logger"
            - "@a6.mailer"
            - "@doctrine.orm.default_entity_manager"
        tags:
            - { name: kernel.event_subscriber }

And after:

services:
    _defaults:
        ####
        # all will be tagged:
        #         tags:
        #              - { name: kernel.event_subscriber }
        ####
        autoconfigure: true


    a6.event.subscriber.registration_mailing:
        class: AppBundle\Event\Subscriber\RegistrationMailingSubscriber
        arguments:
            - "@twig"
            - "@mailer"
            - "%support_email_address%"
            - "%fos_user_from_email_name%"

    a6.event.subscriber.visitor_support_request:
        class: AppBundle\Event\Subscriber\VisitorSupportRequestSubscriber
        arguments:
            - "@logger"
            - "@a6.mailer"
            - "@doctrine.orm.default_entity_manager"

    a6.event.subscriber.member_support_request:
        class: AppBundle\Event\Subscriber\MemberSupportRequestSubscriber
        arguments:
            - "@logger"
            - "@a6.mailer"
            - "@doctrine.orm.default_entity_manager"

That big comment wasn’t added for the sake of this post either. That is for real.

I like Symfony *because* it is explicit.

Other people, I know, prefer what I consider a more magical approach. I like magic in real life. In code, I appreciate magic, but I need to know what’s going on underneath before I feel comfortable using it.

If all my services were in one giant services.yml file, I would not use this approach. That’s my personal opinion anyway.

By the way, probably the most concise guide I have found on this topic has been “How to refactor to new Dependency Injection features in Symfony 3.3” by Tomáš Votruba.

Question Time

I would really appreciate it if you could hit reply, or leave a comment on the blog post to this one:

In a video tutorial series, do you care about seeing the Setup phase?

E.g. if the course was about using Symfony with Redis, how important is seeing Redis being setup and configured to you?

This would greatly help my video topics on a forthcoming course.

Thank you!

Video Update

This week there were 3 new videos added to the site.

https://codereviewvideos.com/course/let-s-build-a-wallpaper-website-in-symfony-3/video/wallpaper-setup-command-part-3-doing-it-with-style

Now that we have created a Symfony console command to find and import our wallpapers we are going to use Symfony’s console style guide to make it look nice.

https://codereviewvideos.com/course/let-s-build-a-wallpaper-website-in-symfony-3/video/doctrine-fixtures-part-1-setup-and-category-entity-creation

Lets add Doctrine Fixtures Bundle to our project to provide a starting point for our Wallpaper and Category data. This is both useful, and easy to do.

https://codereviewvideos.com/course/let-s-build-a-wallpaper-website-in-symfony-3/video/doctrine-fixtures-part-2-relating-wallpapers-with-categories

With our Wallpaper and Category entities in place we can go ahead and create some starting data for each. Beware a few gotchas which we cover in this video.

As ever, thank you very much for being a part of CodeReviewVideos.com, and have a great weekend.

Chris