Kévin Dunglas : expert Symfony et e-commerce, Lille

June 17, 2016 by Kévin Dunglas

ADR pattern, autowiring, DunglasActionBundle: Symfony controllers redesigned

Here are the slides of the talk I gave yesterday at the Symfony meetup (sfPot) of Lille. I was presenting DunglasActionBundle, a refinement of the the Symfony controller system and talking about services autowiring and the ADR pattern.

May 19, 2016 by Kévin Dunglas

The first alpha of API Platform 2.0 is available!

The first alpha of API Platform 2.0 has been released!

Take a look to this presentation to discover changes and new features of this version:

These slides have been presented first in the sfPot conference of Paris (May 17, 2016).

May 10, 2016 by Kévin Dunglas

DunglasActionBundle 0.3.0 released!

DunglasActionBundle is an alternative controller system for the Symfony framework relying on autowiring and inspirited by the ADR pattern. Thanks to this bundle, controllers, commands and event listeners are automatically detected and registered as services. All their dependencies are also automatically registered. See the GitHub repository for an extensive documentation.

A lot of work have been done in during the last months to improve the reliability and the usability of the bundle. Today I’m proud to announce a new release of this bundle (0.3.0). It is available on GitHub and includes the following changes:

Actions and controllers (src/*Bundle/Action and src/*Bundle/Controller directories), commands ( src/*Bundle/Command) and event listeners ( src/*Bundle/EventListener) are auto-registered by default
The name of auto-registered services are now the Fully Qualified Name of the registred class
Directories containing classes to auto-register as services are now configurable
Directories of third-party bundles (vendor/) are not tracked by default anymore
It’s not necessary anymore to clear the cache manually when a new class is added or removed from a tracked directory
If the class of an automatically registred service implements the ContainerAwareInterface, the container is automatically injected into it
It’s now possible to automatically add custom tags to auto-registered services
The custom routing annotation loader has been removed thanks to a bug fix in Symfony core (this feature still works out of the box)
The “autodiscover” feature has been removed, paths must be configured explicitly (regex supported)
The bundle can now be configured using the XML format
PHP 5.5 support has been added
Lot of a bug fixes

Thanks to @Ener-Getick, @stof and @weaverryan for their contributions and good design advices.

If you like this bundle, please give it a star on GitHub!

January 21, 2016 by Kévin Dunglas

DunglasActionBundle: Symfony controllers, redesigned

Today is my birthday, but – unusually – I offer the gift: DunglasActionBundle – a replacement for the Symfony controller subsystem.

Since few months, a lot of discussions and experimentations are occurring in the Symfony world to find a better and moderner way to create controllers.

During the past summer, I’ve already switched the API Platform project from the traditional controller system to a variant of the ADR pattern.

Thanks to the support of autowiring I’ve introduced in the version 2.8 of the Dependency Injection Component, it’s now possible to create a generic (and I hope superior) replacement for the controller system of the full stack framework.

With this new system, no more inherited controller class, no more traits, only a plain old callable!

It is as convenient as the original but doesn’t suffer from its drawbacks:

Action classes are automatically registered as services by the bundle
Dependencies of action classes are explicitly injected in the constructor (no more ugly access to the service container)
Dependencies of action classes are automatically injected using the autowiring feature of the Dependency Injection Component
Only one action per class thanks to the __invoke() method (but you’re still free to create classes with more than 1 action if you want to)
100% compatible with common libraries and bundles including SensioFrameworkExtraBundle annotations

DunglasActionBundle allows to create reusable, framework agnostic (especially when used with the PSR-7 bridge) and easy to unit test actions.

Guess what, it plays very well with the new Symfony micro framework too!

Installation

As usual, use Composer to install this bundle:

composer require dunglas/action-bundle

1	composer require dunglas/action-bundle

Then add the bundle in your application kernel:

// app/AppKernel.php

public function registerBundles()
{
    return [
        // ...
        new Dunglas\ActionBundle\DunglasActionBundle(),
        // ...
    ];
}

// app/AppKernel.php

public function registerBundles()

{

return [

// ...

new Dunglas\ActionBundle\DunglasActionBundle(),

// ...

];

}

Optional: to use the @Route annotation add the following lines in app/config/routing.yml:

app_action:
    resource: '@AppBundle/Action/'
    type:     'action-annotation'

app_action:

resource: [email protected]/Action/'

type: 'action-annotation'

Usage

Create an invokable class in the Action\ namespace of your bundle:

// src/AppBundle/Action/MyAction.php

namespace AppBundle\Action;

use Symfony\Component\Routing\Annotation\Route;
use Symfony\Component\Routing\RouterInterface;
use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

class MyAction
{
    private $router;
    private $twig;

    /**
     * The action is automatically registered as a service and dependencies are autowired.
     * Typehint any service you need, it will be automatically injected.
     */
    public function __construct(RouterInterface $router, \Twig_Environment $twig)
    {
        $this->router = $router;
        $this->twig = $twig;
    }

    /**
     * @Route("/myaction", name="my_action")
     *
     * Using annotations is not mandatory, XML and YAML configuration files can be used instead.
     * If you want to decouple your actions from the framework, don't use annotations.
     */
    public function __invoke(Request $request)
    {
        if (!$request->isMethod('GET') {
            // Redirect in GET if the method is not POST
            return new RedirectResponse($this->router->generateUrl('my_action'), 301);
        }

        return new Response($this->twig->render('mytemplate.html.twig'));
    }
}

// src/AppBundle/Action/MyAction.php

namespace AppBundle\Action;

use Symfony\Component\Routing\Annotation\Route;

use Symfony\Component\Routing\RouterInterface;

use Symfony\Component\HttpFoundation\RedirectResponse;

use Symfony\Component\HttpFoundation\Request;

use Symfony\Component\HttpFoundation\Response;

class MyAction

{

private $router;

private $twig;

/**

* The action is automatically registered as a service and dependencies are autowired.

* Typehint any service you need, it will be automatically injected.

public function __construct(RouterInterface $router, \Twig_Environment $twig)

{

$this->router = $router;

$this->twig = $twig;

}

/**

* @Route("/myaction", name="my_action")

* Using annotations is not mandatory, XML and YAML configuration files can be used instead.

* If you want to decouple your actions from the framework, don't use annotations.

public function __invoke(Request $request)

{

if (!$request->isMethod('GET') {

// Redirect in GET if the method is not POST

return new RedirectResponse($this->router->generateUrl('my_action'), 301);

}

return new Response($this->twig->render('mytemplate.html.twig'));

}

There is not step 2! You’re already done.

All classes inside of the Action/ directory of your project bundles are automatically registered as services. By convention, those services follow this pattern: action.The\Fully\Qualified\Class\Name.

For instance, the class in the example is automatically registered with the name action.AppBundle\Action\MyAction.

Thanks to the autowiring feature of the Dependency Injection Component, you can just typehint dependencies you need in the constructor, they will be automatically injected.

Service definition can easily be customized by explicitly defining a service named according to the same convention:

# app/config/services.yml

services:
    # This is a custom service definition
    'action.AppBundle\Action\MyAction':
        class: 'AppBundle\Action\MyAction'
        arguments: [ '@router', '@twig' ]

# app/config/services.yml

services:

# This is a custom service definition

'action.AppBundle\Action\MyAction':

arguments: [ [email protected]', [email protected]' ]

This bundle also hooks into the Routing Component (if it is available): when the @Route annotation is used as in the example, the route is automatically registered: the bundle guesses the service to map with the path specified in the annotation.

Dive into the TestBundle to discover more examples such as using custom services with ease (no configuration at all) or classes containing several actions.

Using the Symfony Micro Framework

You might be interested to see how this bundle can be used together with the Symfony “Micro” framework.

Here we go:

// MyMicroKernel.php

use Symfony\Bundle\FrameworkBundle\Kernel\MicroKernelTrait;
use Symfony\Component\Config\Loader\LoaderInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\HttpKernel\Kernel;
use Symfony\Component\Routing\RouteCollectionBuilder;

final class MyMicroKernel extends Kernel
{
    use MicroKernelTrait;

    public function registerBundles()
    {
        return [
            new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
            new Dunglas\ActionBundle\DunglasActionBundle(),
            new AppBundle\AppBundle(),
        ];
    }

    protected function configureRoutes(RouteCollectionBuilder $routes)
    {
        // Specify explicitly the controller
        $routes->add('/', 'action.AppBundle\Action\MyAction', 'my_route');
        // Alternatively, use @Route annotations
        // $routes->import('@AppBundle/Action/', '/', 'action-annotation');
    }

    protected function configureContainer(ContainerBuilder $c, LoaderInterface $loader)
    {
        $c->loadFromExtension('framework', ['secret' => 'MySecretKey']);
    }
}

// MyMicroKernel.php

use Symfony\Bundle\FrameworkBundle\Kernel\MicroKernelTrait;

use Symfony\Component\Config\Loader\LoaderInterface;

use Symfony\Component\DependencyInjection\ContainerBuilder;

use Symfony\Component\HttpKernel\Kernel;

use Symfony\Component\Routing\RouteCollectionBuilder;

final class MyMicroKernel extends Kernel

{

use MicroKernelTrait;

public function registerBundles()

{

return [

new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),

new Dunglas\ActionBundle\DunglasActionBundle(),

new AppBundle\AppBundle(),

];

}

protected function configureRoutes(RouteCollectionBuilder $routes)

{

// Specify explicitly the controller

$routes->add('/', 'action.AppBundle\Action\MyAction', 'my_route');

// Alternatively, use @Route annotations

// $routes->import([email protected]/Action/', '/', 'action-annotation');

}

protected function configureContainer(ContainerBuilder $c, LoaderInterface $loader)

{

$c->loadFromExtension('framework', ['secret' => 'MySecretKey']);

}

Amazing isn’t it?

Want to see a more advanced example? Checkout our test micro kernel.

You like this bundle? Give it a star on GitHub!

December 2, 2015 by Kévin Dunglas

Making the Symfony PropertyAccess Component 84% faster in 2.8… and counting

Update 12/06/15: I’ve opened a PR making the PropertyAccess Component 84% faster than before. It implements strategies explained at the end of this post.

This PropertyAccess component allows to access to a property of an object (or a to a key of an array) regardless of the access strategy that must be used. It is smart enough to access directly to public properties and to use getters, setters, issers, adders, removers, magic methods and so on for private and protected ones. It is also allows to access a property trough an object graph using a straightforward notation: $propertyAccessor->getValue($rootObject, 'foo.bar.baz'); .

As you may know, some components of the Symfony framework including Form and the Serializer (see the ObjectNormalizer) rely heavily on it. The JSON-LD normalizer of the API Platform framework also use it intensively. In fact, more than 250+ open source projects rely on the PropertyAccess component (and it has been installed more than 1M times).

It’s a convenient and popular piece of software. But this convenience has a cost: the PropertyAccess component is slow: internally, it uses the PHP Reflection API to guesses what’s the strategy needed to read or write a property.

When using this component in a loop (ex: to normalize a collection of objects to an associative array using the ObjectNormalizer), its slowness become a significant problem.

Here is a benchmark for the PropertyAccess component:

<?php

require 'vendor/autoload.php';

class Foo
{
    private $baz;
    public $bar;

    public function getBaz()
    {
        return $this->baz;
    }

    public function setBaz($baz)
    {
        $this->baz = $baz;
    }
}

use Symfony\Component\PropertyAccess\PropertyAccess;

$accessor = PropertyAccess::createPropertyAccessor();

echo 'Property Access Benchmark'.PHP_EOL;

$start = microtime(true);

for ($i = 0; $i < 10000; ++$i) {
    $foo = new Foo();
    $accessor->setValue($foo, 'bar', 'Lorem');
    $accessor->setValue($foo, 'baz', 'Ipsum');
    $accessor->getValue($foo, 'bar');
    $accessor->getValue($foo, 'baz');
}

echo 'Time: '.(microtime(true) - $start).PHP_EOL;

<?php

require 'vendor/autoload.php';

class Foo

{

private $baz;

public $bar;

public function getBaz()

{

return $this->baz;

}

public function setBaz($baz)

{

$this->baz = $baz;

}

use Symfony\Component\PropertyAccess\PropertyAccess;

$accessor = PropertyAccess::createPropertyAccessor();

echo 'Property Access Benchmark'.PHP_EOL;

$start = microtime(true);

for ($i = 0; $i < 10000; ++$i) {

$foo = new Foo();

$accessor->setValue($foo, 'bar', 'Lorem');

$accessor->setValue($foo, 'baz', 'Ipsum');

$accessor->getValue($foo, 'bar');

$accessor->getValue($foo, 'baz');

}

echo 'Time: '.(microtime(true) - $start).PHP_EOL;

And here is the profile generated by the awesome Blackfire.io: with Symfony 2.7.6:

As you can see the logic to guess the access strategy is executed at each loop iteration. As the structure of a PHP class generally never changes at runtime, a possible optimisation path is to guess the strategy to use for the property of a given class during the first iteration then cache it in an array. This way, the cached access strategy can be reused without extra computations every other time during the current execution thread.

Let’s try that:

(Click on the image to read the full Pull Request description and the related code).

Thanks to this new caching strategy, the PropertyAccessor Component included in Symfony 2.7.7 (and more recent versions) is now 54% faster according to the same benchmark:

But the component can be even more optimized.

For instance, the constructor of the Symfony\Component\PropertyAccess\PropertyPath class uses a slow regular expression. This constructor is still called at each iteration in a loop. The result of the regular expression isn’t cached:

A similar cache mechanism should be used to avoid executing the same regular expression at each iteration. I’ve started to work on a patch doing that, but it still needs some work before being ready to be merged in Symfony. This patch improves the performance of the PropertyAccess of 20% more. Using both patches, the component is 70% faster than in 2.7.6.

There is another promising way to improve the performance of this component: for now the access strategy is always guessed the first time a property is accessed during an execution thread (e.g. when handling an HTTP request). Using a permanent cache system (such as APC or Redis trough the Doctrine Cache library) in complement of the in-memory array would allow to guess the strategy only one time, (e.g. during the first HTTP request), then reuse it for each next executions. Symfony 3.1 will have this feature.

By the way, a similar optimization has been done on the ObjectNormalizer. It needs to know the list of properties of an object to normalize it. This list wasn’t cached either. In Symfony 2.8, it’s done:

Thanks to this patch and to the optimization of the PropertyAccess component, the ObjectNormalizer is 40% faster in Symfony 2.8/3.0 than in Symfony 2.7.6!

November 24, 2015 by Kévin Dunglas

My slides about API Platform from AFUP’s Forum PHP 2015

My slides from this morning at Forum PHP Paris about API Platform:

Open the slides in full screen

November 13, 2015 by Kévin Dunglas

Introducing the phpdoc-to-typehint Converter: add scalar type hints and return type declarations to your projects

tl;dr Download phpdoc-to-typehint, it will automatically add scalar type hints and return type declarations to your PHP project using existing PHPDoc annotations.

PHP 7 will be released soon. Scalar type hints and return type declarations introduced in this new release are very interesting because they enforce the use of stricter types in PHP code. They are less error-prone and ease the maintenance. To quote the RFC: “These type declarations allow the PHP runtime to ensure that correctly-typed arguments are passed to functions, and make function signatures more informative.”

At Les-Tilleuls.coop, we are always looking how we can improve the quality of some of our long running sensitive projects. On the other hand we are a gang of lazy leftists drinking beers late at night. Updating all our code bases to add scalar type hints and return type declarations will be a pain.

Hopefully, we’ve already done a similar work by writing an exhaustive PHPDoc including @param and @return tags describing PHP functions. It allows IDEs and static analysis tools such as Scrutinizr to detect potential bugs early in the development process. Here was born my idea: a tool using existing PHPDoc tags to automatically add scalar type hint and return types.

This command line tool is called phpdoc-to-typehint. You can download it as PHAR file on GitHub.

To use it, just run the following command:

php phpdoc-to-typehint.phar <my-project-directory>

Before:

<?php

/*
 * @param int|null $a
 * @param string   $b
 *
 * @return float
 */
function bar($a, $b, bool $c, callable $d = null)
{
    return 0.0;
}

<?php

* @param int|null $a

* @param string $b

* @return float

function bar($a, $b, bool $c, callable $d = null)

{

return 0.0;

}

After:

<?php

/*
 * @param int|null $a
 * @param string   $b
 *
 * @return float
 */
function bar(int $a = null, string $b, bool $c, callable $d = null) : float
{
    return 0.0;
}

<?php

* @param int|null $a

* @param string $b

* @return float

function bar(int $a = null, string $b, bool $c, callable $d = null) : float

{

return 0.0;

}

This tool is very experimental and can break your code. Be sure to have a backup of it (but you’re using Git right?) and run your test suite after the conversion. Bug reports are very welcomed.

It supports:

functions
methods of classes and traits
method definitions in interfaces
PHPDoc inheritance

The tool tries to preserve the existing indentation of source code files but it can create some strange indentations, especially when it adds return types. Run PHP CS Fixer to make your code following PSR-1 and PSR-2 conventions.

We can go back to the pub.

October 29, 2015 by Kévin Dunglas

Symfony Live San Francisco: my slides about how to make high performance API powered webapps with Symfony

I was speaking about cloud computing, APIs and JavaScript Single Page Application at the Symfony Live San Francisco conference. Here are my slides:

Open the slides in full screen

October 26, 2015 by Kévin Dunglas

See you at these upcoming PHP conferences

I’ll speak about API Platform and Symfony at some PHP conferences until the end of 2015:

Symfony Live, San Francisco (October 29th)

Leveraging a cloud computing infrastructure to build high performance Symfony webapps

I’ll present how to tune Symfony webapps to be as efficient and as robust as possible thanks to cloud computing platforms.

I’ll detail how to design the webapp from the start to be very efficient on such platforms: we we’ll learn advantages of splitting the backend code (PHP/Symfony) from the frontend code (HTML/JS/CSS) communicating trough a REST API, how to build stateless apps (including auth) that play well with horizontal scalability, and what kind of services can help us to setup in hours a rock solid infrastructure without an army of sysadmins.

Then we will discover how to run a Sf webapp on Heroku + AWS without pain thanks to some tricks and a lot of useful Symfony bundles and PHP libraries.

In the end we will get a Symfony webapp with all assets stored on a CDN, running on Heroku with HHVM behind a reverse-proxy, in full HTTPS, able to survive under very high traffic.

Forum PHP, Paris (November 24th) – in French

API Platform : un framework dédié aux applications API-first

API Platform est un tout nouveau framework PHP qui permet de construire des applications performantes, évolutives et interopérables. Il est basé sur les nouveaux standards du web: JSON-LD, Hydra, Schema.org et JSON Web Token (JWT). Il est 100% compatible avec Symfony et ses milliers de bundles. Au cours de ce talk je présenterai les concepts sur lesquels il repose à savoir une API REST centrale consommée par différents types de clients tel que des applis web et mobiles (API-first), le pattern Action-Domain-Responder, un système d’évènements puissant et flexible et des composants “standalones”. Je m’attarderai ensuite à montrer comme les fonctionnalités de API Platform rendent la création d’applications web et mobiles modernes, performantes et intéropérables et à la portée de tous grâce à ses multiples fonctionnalités : – Générateur de modèle de données dérivé du vocabulaire Schema.org (PHPDoc complète, support de l’ORM Doctrine et de la validation Symfony) – Création automatique d’une API REST de niveau 3 (hypermédia) complètement fonctionnelle (CRUD, validation, listes, paginations, filtres, négociation de contenu…) et 100% extensible – Authentification stateless (cookie-less) – Intégration aisée avec de nombreux clients tel que AngularJS, Guzzle, et les applis mobiles – Behavior Driven Development et web acceptance testing avec la distribution adaptée à API Platform de Behat – Découverte et utilisation d’une interface d’administration générique via Hydra Console La présentation sera didactique et accessible aux développeurs PHP de tous niveaux. La construction d’une micro-application suivant cette architecture sera présentée pas à pas.

SymfonyCon, Paris (December 3rd) – with Fabien Gasser

Building high profile webapps with Symfony and API Platform

In a first part we will introduce semantic and linked data technologies supported by Symfony and API Platform: JSON-LD, Hydra and Schema.org, their contributions to interoperability and a web of data and how to use them, technologies until there the restricted domain of Java such as RDF, SPARQL, triple stores, ontology engines.

In a second part we will give a feedback on the strategy we employed to build a high traffic CMS platform using Symfony, API Platform and AngularJS as technical stack. We will see how an API-first strategy helped us to deliver fluently content on several channels (desktop, mobile apps, connected devices, partners…) and how that strategy helped us to make large teams working together on the same project. We will also see how to leverage Varnish and AWS to absorb gigantic traffic peaks, how pure-JS fit well with that architecture and effects on SEO

In a third part we will give you some tips in order to build an e-commerce platform based on that approach.

See you there!

October 19, 2015 by Kévin Dunglas

New in Symfony 2.8/3.0: services autowiring

Symfony 10 years

Symfony 3.0, the next major version of our preferred PHP framework, will be released in a few weeks. Basically, it shares the same code base as Symfony 2.8 but all deprecated features coming from older versions have been removed to simplify the framework and its maintenance:

Symfony 3 deprecation progress report. #symfony pic.twitter.com/Nz4pMZZwU4

— Symfony News (@symfony_en) October 6, 2015

Symfony 2.8 and 3.0 also come with a lot of new features including (but not limited to) the (awesome) Guard authentication system, LDAP support or a component to guess types of PHP properties. In this post we’ll discover another interesting feature proudly sponsored by Les-Tilleuls.coop I’ve added to the Dependency Injection Component: autowiring.

The #Symfony Dependency Injection Component now supports autowiring! https://t.co/6imXHSReGU #PHP

— Kévin Dunglas (@dunglas) October 3, 2015

Introduction

Autowiring allows to register services in the container with minimal configuration. It is practical in the field of rapid application development, when designing prototypes and in early stages of large projects. It makes it easy to bootstrap an app service graph and eases refactoring:

@dunglas right, that's an interesting aspect for cache invalidation as well: a change in the class itself should trigger a container build.

— Matthias Noback (@matthiasnoback) August 30, 2015

A demo containing all code snippets shown in this article is available in a dedicated GitHub repository.

Let’s see how it works. To do so we will build a fake API publishing statutes on a Twitter feed obfuscated with ROT13 (a special case of the Caesar cipher).

Start by creating a ROT13 transformer class:

<?php

// src/AppBundle/Rot13Transformer.php

namespace AppBundle;

class Rot13Transformer
{
    public function transform($value)
    {
        return str_rot13($value);
    }
}

<?php

// src/AppBundle/Rot13Transformer.php

namespace AppBundle;

class Rot13Transformer

{

public function transform($value)

{

return str_rot13($value);

}

And now a Twitter client using this transformer:

<?php

// src/AppBundle/TwitterClient.php

namespace AppBundle;

class TwitterClient
{
    private $rot13Transformer;

    public function __construct(Rot13Transformer $rot13Transformer)
    {
        $this->rot13Transformer = $rot13Transformer;
    }

    public function tweetInRot13($user, $key, $status)
    {
        $transformedStatus = $this->rot13Transformer->transform($status);

        // Connect to Twitter and send the encoded status
    }
}

<?php

// src/AppBundle/TwitterClient.php

namespace AppBundle;

class TwitterClient

{

private $rot13Transformer;

public function __construct(Rot13Transformer $rot13Transformer)

{

$this->rot13Transformer = $rot13Transformer;

}

public function tweetInRot13($user, $key, $status)

{

$transformedStatus = $this->rot13Transformer->transform($status);

// Connect to Twitter and send the encoded status

}

The Dependency Injection Component is now able to automatically register the dependencies of this TwitterClient class. The twitter_client service definition just need to be marked as autowired:

# config/services.yml

services:
    twitter_client:
        class:    AppBundle\TwitterClient
        autowire: true

# config/services.yml

services:

twitter_client:

autowire: true

The autowiring subsystem will parse the constructor of the TwitterClient class and detects its dependencies that way. Here it will find and fill the need for an instance of a Rot13Transformer.

If an existing service definition (and only one – see below) is of the needed type, it will inject it. Here it’s not the case, but the subsystem is smart enough to automatically register a private service for the Rot13Transformer class and set it as first argument of the twitter_client service. Again, it can work only if there is one class of the given type. If there are several classes of the same type, you must fallback to the explicit service definition or register a default implementation (I’ll present this feature in a few line).

As you can see, the autowiring feature drastically reduces the amount of configuration required to define a service. No more arguments section! It also makes it easy to change the dependencies of the TwitterClient class: just add or remove typehinted arguments in the constructor and you’re done. There is no need anymore to search and edit related service definitions.

Here is a typical controller using the twitter_client services:

<?php

// src/AppBundle/Controller/DefaultController.php

namespace AppBundle\Controller;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Method;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Exception\BadRequestHttpException;

class DefaultController extends Controller
{
    /**
     * @Route("/tweet")
     * @Method("POST")
     */
    public function tweetAction(Request $request)
    {
        $user = $request->request->get('user');
        $key = $request->request->get('key');
        $status = $request->request->get('status');

        if (!$user || !$key || !$status) {
            throw new BadRequestHttpException();
        }

        $this->get('twitter_client')->tweetInRot13($user, $key, $status);

        return new Response('OK');
    }
}

<?php

// src/AppBundle/Controller/DefaultController.php

namespace AppBundle\Controller;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Method;

use Symfony\Bundle\FrameworkBundle\Controller\Controller;

use Symfony\Component\HttpFoundation\Request;

use Symfony\Component\HttpFoundation\Response;

use Symfony\Component\HttpKernel\Exception\BadRequestHttpException;

class DefaultController extends Controller

{

/**

* @Route("/tweet")

* @Method("POST")

public function tweetAction(Request $request)

{

$user = $request->request->get('user');

$key = $request->request->get('key');

$status = $request->request->get('status');

if (!$user || !$key || !$status) {

throw new BadRequestHttpException();

}

$this->get('twitter_client')->tweetInRot13($user, $key, $status);

return new Response('OK');

}

You can give a try to the API with curl:

curl -d "user=kevin&key=ABCD&status=Salut" http://localhost:8000/tweet

It should return OK.

Working with interfaces

This is nice but when the application grows, it’s recommended to code against abstractions instead of implementations: it allows to easily replace some dependencies without modifying the class depending of them.

To follow this best practice, constructor arguments must be typehinted with interfaces and not concrete classes. It allows to replace easily the current implementation if necessary.

Let’s introduce a Rot13TransformerInterface:

<?php

// src/AppBundle/Rot13TransformerInterface.php

namespace AppBundle;

interface Rot13TransformerInterface
{
    public function transform($value);
}

<?php

// src/AppBundle/Rot13TransformerInterface.php

namespace AppBundle;

interface Rot13TransformerInterface

{

public function transform($value);

}

Then edit Rot13Transformer to make it implementing the new interface:

// ...

class Rot13Transformer implements Rot13TransformerInterface

// ...

// ...

class Rot13Transformer implements Rot13TransformerInterface

// ...

And update TwitterClient to depend of this new interface:

class TwitterClient
{
    // ...

    public function __construct(Rot13TransformerInterface $rot13Transformer)
    {
         // ...
    }

    // ...
}

class TwitterClient

{

// ...

public function __construct(Rot13TransformerInterface $rot13Transformer)

{

// ...

}

// ...

}

Finally the service definition must be updated because, obviously, the autowiring subsystem isn’t able to find itself the interface implementation to register:

# app/config/services.yml

services:
    rot13_transformer:
        class: AppBundle\Rot13Transformer

    twitter_client:
        class:    AppBundle\TwitterClient
        autowire: true

# app/config/services.yml

services:

rot13_transformer:

twitter_client:

autowire: true

The autowiring subsystem detects that the rot13_transformer service implements the Rot13TransformerInterface and injects it automatically. Even when using interfaces (and you should), building the service graph and refactoring the project is easier than with standard definitions.

Dealing with multiple implementations of the same type

Last but not least, the autowiring feature allows to specify the default implementation of a given type. Let’s introduce a new implementation of the Rot13TransformerInterface returning the result of the ROT13 transformation uppercased:

<?php

// src/AppBundle/UppercaseRot13Transformer.php

namespace AppBundle;

class UppercaseRot13Transformer implements Rot13TransformerInterface
{
    private $rot13transformer;

    public function __construct(Rot13TransformerInterface $rot13transformer)
    {
        $this->rot13transformer = $rot13transformer;
    }

    public function transform($value)
    {
        return strtoupper($this->rot13transformer->transform($value));
    }
}

<?php

// src/AppBundle/UppercaseRot13Transformer.php

namespace AppBundle;

class UppercaseRot13Transformer implements Rot13TransformerInterface

{

private $rot13transformer;

public function __construct(Rot13TransformerInterface $rot13transformer)

{

$this->rot13transformer = $rot13transformer;

}

public function transform($value)

{

return strtoupper($this->rot13transformer->transform($value));

}

This class is intended to decorate the standard ROT13 transformer (or any other implementation) and return it uppercased.

We can now refactor the controller to add another endpoint leveraging this new transformer:

<?php

// src/AppBundle/Controller/DefaultController.php

namespace AppBundle\Controller;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Method;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Exception\BadRequestHttpException;

class DefaultController extends Controller
{
    /**
     * @Route("/tweet")
     * @Method("POST")
     */
    public function tweetAction(Request $request)
    {
        return $this->tweet($request, 'twitter_client');
    }

    /**
     * @Route("/tweet-uppercase")
     * @Method("POST")
     */
    public function tweetUppercaseAction(Request $request)
    {
        return $this->tweet($request, 'uppercase_twitter_client');
    }

    private function tweet(Request $request, $service)
    {
        $user = $request->request->get('user');
        $key = $request->request->get('key');
        $status = $request->request->get('status');

        if (!$user || !$key || !$status) {
            throw new BadRequestHttpException();
        }

        $this->get($service)->tweetInRot13($user, $key, $status);

        return new Response('OK');
    }
}

<?php

// src/AppBundle/Controller/DefaultController.php

namespace AppBundle\Controller;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Method;

use Symfony\Bundle\FrameworkBundle\Controller\Controller;

use Symfony\Component\HttpFoundation\Request;

use Symfony\Component\HttpFoundation\Response;

use Symfony\Component\HttpKernel\Exception\BadRequestHttpException;

class DefaultController extends Controller

{

/**

* @Route("/tweet")

* @Method("POST")

public function tweetAction(Request $request)

{

return $this->tweet($request, 'twitter_client');

}

/**

* @Route("/tweet-uppercase")

* @Method("POST")

public function tweetUppercaseAction(Request $request)

{

return $this->tweet($request, 'uppercase_twitter_client');

}

private function tweet(Request $request, $service)

{

$user = $request->request->get('user');

$key = $request->request->get('key');

$status = $request->request->get('status');

if (!$user || !$key || !$status) {

throw new BadRequestHttpException();

}

$this->get($service)->tweetInRot13($user, $key, $status);

return new Response('OK');

}

The last step is to update service definitions to register this new implementation and a Twitter client using it:

# app/config/services.yml

services:
    rot13_transformer:
        class: AppBundle\Rot13Transformer
        autowiring_types: AppBundle\Rot13TransformerInterface

    twitter_client:
        class:    AppBundle\TwitterClient
        autowire: true

    uppercase_rot13_transformer:
        class: AppBundle\UppercaseRot13Transformer
        autowire: true

    uppercase_twitter_client:
        class: AppBundle\TwitterClient
        arguments: [ @uppercase_rot13_transformer ]

# app/config/services.yml

services:

rot13_transformer:

autowiring_types: AppBundle\Rot13TransformerInterface

twitter_client:

autowire: true

uppercase_rot13_transformer:

autowire: true

uppercase_twitter_client:

arguments: [ @uppercase_rot13_transformer ]

It deserves some explanations. We now have 2 services implementing the Rot13TransformerInterface. The autowiring subsystem cannot guess the which one to use, this leads to errors like:

  [Symfony\Component\DependencyInjection\Exception\RuntimeException]                                           
  Unable to autowire argument of type "AppBundle\Rot13TransformerInterface" for the service "twitter_client".

1 2	[Symfony\Component\DependencyInjection\Exception\RuntimeException] Unable to autowire argument of type "AppBundle\Rot13TransformerInterface" for the service "twitter_client".

Fortunately, the autowiring_types key is here to specify which implementation to use by default. This key can take a list of types if necessary (using a YAML array).

Thanks to this setting, the rot13_transformer service is automatically injected as argument of the uppercase_rot13_transformer and twitter_client services. For the uppercase_twitter_client, we use a standard service definition to inject the specific uppercase_rot13_transformer service.

You now know everything you need to use the new autowiring feature! As this feature is directly available in the Dependency Injection Component, you can leverage it in any project using it, including Drupal 8, API Platform or BackBee once the component have been upgraded to 2.8+.

As for other RAD features such as the FrameworkBundle controller or annotations, keep in mind to not use autowiring in public bundles nor in large projects with complex maintenance needs.

Partager :

Partager :

Partager :

Installation

Usage

Using the Symfony Micro Framework

Partager :

Partager :

Partager :

Partager :

Partager :

Leveraging a cloud computing infrastructure to build high performance Symfony webapps

Forum PHP, Paris (November 24th) – in French

API Platform : un framework dédié aux applications API-first

SymfonyCon, Paris (December 3rd) – with Fabien Gasser

Building high profile webapps with Symfony and API Platform

Partager :

Introduction

Working with interfaces

Dealing with multiple implementations of the same type

Partager :