@@ -27,9 +27,14 @@ The Workflow of a Request
2727Every HTTP web interaction begins with a request and ends with a response.
2828Your job as a developer is to create PHP code that reads the request information
2929(e.g. the URL) and creates and returns a response (e.g. an HTML page or JSON string).
30+ This is a simplified overview of the request workflow in Symfony applications:
3031
31- .. image :: /_images/components/http_kernel/request-response-flow.png
32- :align: center
32+ #. The **user ** asks for a **resource ** in a **browser **;
33+ #. The **browser ** sends a **request ** to the **server **;
34+ #. **Symfony ** gives the **application ** a **Request ** object;
35+ #. The **application ** generates a **Response ** object using the data of the **Request ** object;
36+ #. The **server ** sends back the **response ** to the **browser **;
37+ #. The **browser ** displays the **resource ** to the **user **.
3338
3439Typically, some sort of framework or system is built to handle all the repetitive
3540tasks (e.g. routing, security, etc) so that a developer can easily build
@@ -62,8 +67,9 @@ the concrete implementation of :method:`HttpKernelInterface::handle() <Symfony\\
6267defines a workflow that starts with a :class: `Symfony\\ Component\\ HttpFoundation\\ Request `
6368and ends with a :class: `Symfony\\ Component\\ HttpFoundation\\ Response `.
6469
65- .. image :: /_images/components/http_kernel/01-workflow.png
66- :align: center
70+ .. raw :: html
71+
72+ <object data =" ../_images/components/http_kernel/http-workflow.svg" type =" image/svg+xml" object >
6773
6874The exact details of this workflow are the key to understanding how the kernel
6975(and the Symfony Framework or any other library that uses the kernel) works.
@@ -138,9 +144,6 @@ layer that denies access).
138144The first event that is dispatched inside :method: `HttpKernel::handle <Symfony\\ Component\\ HttpKernel\\ HttpKernel::handle> `
139145is ``kernel.request ``, which may have a variety of different listeners.
140146
141- .. image :: /_images/components/http_kernel/02-kernel-request.png
142- :align: center
143-
144147Listeners of this event can be quite varied. Some listeners - such as a security
145148listener - might have enough information to create a ``Response `` object immediately.
146149For example, if a security listener determined that a user doesn't have access,
@@ -150,9 +153,6 @@ to the login page or a 403 Access Denied response.
150153If a ``Response `` is returned at this stage, the process skips directly to
151154the :ref: `kernel.response <component-http-kernel-kernel-response >` event.
152155
153- .. image :: /_images/components/http_kernel/03-kernel-request-response.png
154- :align: center
155-
156156Other listeners simply initialize things or add more information to the request.
157157For example, a listener might determine and set the locale on the ``Request ``
158158object.
@@ -205,9 +205,6 @@ to your application. This is the job of the "controller resolver" - a class
205205that implements :class: `Symfony\\ Component\\ HttpKernel\\ Controller\\ ControllerResolverInterface `
206206and is one of the constructor arguments to ``HttpKernel ``.
207207
208- .. image :: /_images/components/http_kernel/04-resolve-controller.png
209- :align: center
210-
211208Your job is to create a class that implements the interface and fill in its
212209two methods: ``getController() `` and ``getArguments() ``. In fact, one default
213210implementation already exists, which you can use directly or learn from:
@@ -280,9 +277,6 @@ some part of the system that needs to be initialized after certain things
280277have been determined (e.g. the controller, routing information) but before
281278the controller is executed. For some examples, see the Symfony section below.
282279
283- .. image :: /_images/components/http_kernel/06-kernel-controller.png
284- :align: center
285-
286280Listeners to this event can also change the controller callable completely
287281by calling :method: `FilterControllerEvent::setController <Symfony\\ Component\\ HttpKernel\\ Event\\ FilterControllerEvent::setController> `
288282on the event object that's passed to listeners on this event.
@@ -314,9 +308,6 @@ should be passed to that controller. Exactly how this is done is completely
314308up to your design, though the built-in :class: `Symfony\\ Component\\ HttpKernel\\ Controller\\ ControllerResolver `
315309is a good example.
316310
317- .. image :: /_images/components/http_kernel/07-controller-arguments.png
318- :align: center
319-
320311At this point the kernel has a PHP callable (the controller) and an array
321312of arguments that should be passed when executing that callable.
322313
@@ -345,9 +336,6 @@ of arguments that should be passed when executing that callable.
345336
346337The next step is simple! ``HttpKernel::handle() `` executes the controller.
347338
348- .. image :: /_images/components/http_kernel/08-call-controller.png
349- :align: center
350-
351339The job of the controller is to build the response for the given resource.
352340This could be an HTML page, a JSON string or anything else. Unlike every
353341other part of the process so far, this step is implemented by the "end-developer",
@@ -357,9 +345,6 @@ Usually, the controller will return a ``Response`` object. If this is true,
357345then the work of the kernel is just about done! In this case, the next step
358346is the :ref: `kernel.response <component-http-kernel-kernel-response >` event.
359347
360- .. image :: /_images/components/http_kernel/09-controller-returns-response.png
361- :align: center
362-
363348But if the controller returns anything besides a ``Response ``, then the kernel
364349has a little bit more work to do - :ref: `kernel.view <component-http-kernel-kernel-view >`
365350(since the end goal is *always * to generate a ``Response `` object).
@@ -384,9 +369,6 @@ another event - ``kernel.view``. The job of a listener to this event is to
384369use the return value of the controller (e.g. an array of data or an object)
385370to create a ``Response ``.
386371
387- .. image :: /_images/components/http_kernel/10-kernel-view.png
388- :align: center
389-
390372This can be useful if you want to use a "view" layer: instead of returning
391373a ``Response `` from the controller, you return data that represents the page.
392374A listener to this event could then use this data to create a ``Response `` that
@@ -515,8 +497,9 @@ function is wrapped in a try-catch block. When any exception is thrown, the
515497``kernel.exception `` event is dispatched so that your system can somehow respond
516498to the exception.
517499
518- .. image :: /_images/components/http_kernel/11-kernel-exception.png
519- :align: center
500+ .. raw :: html
501+
502+ <object data =" ../_images/components/http_kernel/http-workflow-exception.svg" type =" image/svg+xml" object >
520503
521504Each listener to this event is passed a :class: `Symfony\\ Component\\ HttpKernel\\ Event\\ GetResponseForExceptionEvent `
522505object, which you can use to access the original exception via the
@@ -660,8 +643,9 @@ a page instead of a full page. You'll most commonly make sub-requests from
660643your controller (or perhaps from inside a template, that's being rendered by
661644your controller).
662645
663- .. image :: /_images/components/http_kernel/sub-request.png
664- :align: center
646+ .. raw :: html
647+
648+ <object data =" ../_images/components/http_kernel/http-workflow-subrequest.svg" type =" image/svg+xml" object >
665649
666650To execute a sub request, use ``HttpKernel::handle() ``, but change the second
667651argument as follows::
0 commit comments