Chapters

26 Chapters | 2:53:08 |

01

Events, Events & Events!

5:10
02

Hooking into Symfony with an Event Subscriber

5:54
03

index.php to HttpKernel::handle()

6:50
04

RequestEvent & RouterListener

6:26
05

Routing Secrets & Request Attributes

7:47
06

The Controller Resolver

7:03
07

Who Creates the Controller & Gives it the Container?

8:04
08

How does the Controller Access the Container?

4:14
09

The Argument Resolver

8:13
10

Argument Value Resolvers

5:32
11

How Service Autowiring Works in a Controller Method

7:36
12

Calling the Controller & View Event

5:20
13

kernel.response Event & Request Format

6:36
14

Finishing the Request

6:03
15

Exception Handling

9:29
16

The Critical kernel.exception Event Listeners

7:07
17

FlattenException & Error Status Codes

6:10
18

Serializer Error Renderer: JSON/XML Errors

5:40
19

How the HTML Error Page is Rendered

7:34
20

The Magic `_controller` Attribute

6:36
21

Custom Global Controller Arguments

5:37
22

How Entity Controller Arguments Work

4:54
23

Sub Requests

7:54
24

Sub Requests & Request Data

5:40
25

Manually Making a Sub Request

6:34
26

Sub Request Attributes

9:05

> Symfony 5 > Symfony 5 Deep Dive! The HttpKernel Request-Response Flow

Buy Access to Course

05.

Routing Secrets & Request Attributes

|

Autoplay

Previous Chapter

Next Chapter

Login or register to check out the script

4 Comments

Sort By

Login or Register to join the conversation

Nadine 6 years ago

Hi, i've some questions about the dispatching part. I see that the dispatch function has to return data, but there is not return statement in the onKernelRequest function in the routerlistener file. How does that data coming back?

Also at 6:00 you're showing that the request object is changed, but how did that happened?

I can't make the connection that the modifications by the event dispatched are returned.

|

weaverryan SFCASTS Nadine 6 years ago edited

Hey Nadine !

Excellent question :). You're right that listener functions to an event (like onKernelRequest()) do not return anything. If they did, it would be totally ignored. Instead, if a listener needs to "communicate" something back to the original code that dispatched the event (in this case, `HttpKernel::handleRaw()</code), that's done by modifying some object. Specifically, this is usually done by modifying the event object itself. For example, here is the code from HttpKernel that dispatches the event:


// HttpKernel::handleRaw()
$event = new RequestEvent($this, $request, $type);
$this->dispatcher->dispatch($event, KernelEvents::REQUEST);

The RequestEvent is passed to all listeners to this event... and listeners can modify that object by using any setter methods it may have. For example (RouterListener doesn't do this, but it's still a valid example), the RequestEvent has a setResponse() method. A listener can call that to set a Response on the event (i.e. it modifies the event). Then, the code in HttpKernel checks to see if someone has set a Response and uses it if one has - that's the next lines after dispatching:


// did someone modify the event and set a response?
if ($event->hasResponse()) {
    return $this->filterResponse($event->getResponse(), $request, $type);
}

So, there is no direct communication between who dispatches the event and the listeners. But listeners can communicate by modifying the Event object.

RouterListener does something very similar. It doesn't modify the Event itself, but it does modify the Request. Here's the code form HttpKernel next to the RouterListener code to see how this looks:


// HttpKernel::handleRaw()

// the Request object is passed to RequestEvent and is accessible via $event->getRequest() in listeners
$event = new RequestEvent($this, $request, $type);
$this->dispatcher->dispatch($event, KernelEvents::REQUEST);

// RouterListener::onKernelRequest()

// .. after executing the routing, it modifies the Request object
$request->attributes->add($parameters);



So, quite literally, one of the most important results of the dispatching this event is that one listener (RouterListener) modifies/mutates the Request object. HttpKernel then goes on to use that new data on the Request to do other stuff.

Let me know if that makes sense!

Cheers!

|

Nadine weaverryan 6 years ago

Thanks for your answer!

So the Event object is first passed to the listener with the highest priority. After excuthing the first listener function it goes to the next listener with the modified object from the first listener.

And the Event object is send as reference, so it doesn't have to be returned with a return statement.

Am I right?

|

MolloKhan SFCASTS Nadine 6 years ago

Yep, you're right. In PHP all objects are passed by reference by default, that's why listeners do not have to returning anything, they just have to work with the event object

Cheers!

1 |

This tutorial also works well for Symfony 6!

Symfony 5

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": ">=8.2",
        "ext-iconv": "*",
        "antishov/doctrine-extensions-bundle": "^1.4", // v1.4.3
        "aws/aws-sdk-php": "^3.87", // 3.133.20
        "composer/package-versions-deprecated": "^1.11", // 1.11.99
        "doctrine/annotations": "^1.0", // 1.12.1
        "doctrine/doctrine-bundle": "^2.0", // 2.2.3
        "doctrine/doctrine-migrations-bundle": "^1.3|^2.0", // 2.2.2
        "doctrine/orm": "^2.5.11", // 2.8.2
        "easycorp/easy-log-handler": "^1.0", // v1.0.9
        "http-interop/http-factory-guzzle": "^1.0", // 1.0.0
        "knplabs/knp-markdown-bundle": "^1.7", // 1.9.0
        "knplabs/knp-paginator-bundle": "^5.0", // v5.4.2
        "knplabs/knp-snappy-bundle": "^1.6", // v1.7.1
        "knplabs/knp-time-bundle": "^1.8", // v1.16.0
        "league/flysystem-aws-s3-v3": "^1.0", // 1.0.24
        "league/flysystem-cached-adapter": "^1.0", // 1.0.9
        "league/html-to-markdown": "^4.8", // 4.9.1
        "liip/imagine-bundle": "^2.1", // 2.5.0
        "oneup/flysystem-bundle": "^3.0", // 3.7.0
        "php-http/guzzle6-adapter": "^2.0", // v2.0.2
        "phpdocumentor/reflection-docblock": "^5.2", // 5.2.2
        "sensio/framework-extra-bundle": "^5.1", // v5.6.1
        "symfony/asset": "5.0.*", // v5.0.11
        "symfony/console": "5.0.*", // v5.0.11
        "symfony/dotenv": "5.0.*", // v5.0.11
        "symfony/flex": "^1.9", // v1.21.6
        "symfony/form": "5.0.*", // v5.0.11
        "symfony/framework-bundle": "5.0.*", // v5.0.11
        "symfony/mailer": "5.0.*", // v5.0.11
        "symfony/messenger": "5.0.*", // v5.0.11
        "symfony/monolog-bundle": "^3.5", // v3.6.0
        "symfony/property-access": "5.0.*|| 5.1.*", // v5.1.11
        "symfony/property-info": "5.0.*|| 5.1.*", // v5.1.10
        "symfony/routing": "5.1.*", // v5.1.11
        "symfony/security-bundle": "5.0.*", // v5.0.11
        "symfony/sendgrid-mailer": "5.0.*", // v5.0.11
        "symfony/serializer": "5.0.*|| 5.1.*", // v5.1.10
        "symfony/twig-bundle": "5.0.*", // v5.0.11
        "symfony/validator": "5.0.*", // v5.0.11
        "symfony/webpack-encore-bundle": "^1.4", // v1.11.1
        "symfony/yaml": "5.0.*", // v5.0.11
        "twig/cssinliner-extra": "^2.12", // v2.14.3
        "twig/extensions": "^1.5", // v1.5.4
        "twig/extra-bundle": "^2.12|^3.0", // v3.3.0
        "twig/inky-extra": "^2.12", // v2.14.3
        "twig/twig": "^2.12|^3.0" // v2.14.4
    },
    "require-dev": {
        "doctrine/doctrine-fixtures-bundle": "^3.0", // 3.4.0
        "fakerphp/faker": "^1.13", // v1.13.0
        "symfony/browser-kit": "5.0.*", // v5.0.11
        "symfony/debug-bundle": "5.0.*", // v5.0.11
        "symfony/maker-bundle": "^1.0", // v1.29.1
        "symfony/phpunit-bridge": "5.0.*", // v5.0.11
        "symfony/stopwatch": "^5.1", // v5.1.11
        "symfony/var-dumper": "5.0.*", // v5.0.11
        "symfony/web-profiler-bundle": "^5.0" // v5.0.11
    }
}

Previous Chapter

Next Chapter