Table of Contents
Home
Backend Development
PHP Tutorial
Symfoy2 HttpKernel event-driven, symfoy2httpkernel_PHP tutorial
Backend Development
PHP Tutorial
Symfoy2 HttpKernel event-driven, symfoy2httpkernel_PHP tutorial
Symfoy2 HttpKernel event-driven, symfoy2httpkernel_PHP tutorial
kernel
Symfoy2 HttpKernel event-driven, symfoy2httpkernel
HttpKernel: event-driven Symfony2 The work of the framework layer and application layer is completed in the HttpKernel::handle() method. The internal implementation of HttpKernel::handle() is actually through scheduling This is accomplished by event (event listener in HttpKernel), which is equivalent to integrating all components into a complete application. Using HttpKernel is very simple, just create an EventDispatcher (event dispatcher) and controller resolver (Controller resolver), which can implement more event listeners to enrich application functions:
kernel.request Event
The purpose of implementing the kernel.request event is to add more information to the Request object, or to get the returned Response object (for example: obtained from the cache or the security layer denies access)
The kernel.request event is the first event dispatched by HttpKernel::handle(), then multiple listeners listening to the event will be executed.
There are many types of event listeners, and their behaviors are different. For example, when the security listener determines that the user does not have sufficient permissions, a RedirectResponse object will be generated. If the Response object is currently returned directly, the kernel will be executed directly. .response event:
The purpose of the event is either to directly create and return the Response object, or to add more information to the Request object.
<span>RouterListener是Symfony框架中实现</span>kernel.request<span>事件的最重要监听器，</span>RouterListener在路由层中执行，返回一个包含符合当前请求的路由信息的数组，例如路由匹配模式里面的_controller和请求的参数（｛name｝）。这些信息都会存放在Request里的attributes数组里面，目前只是会添加路由信息到Request对象中还没有做其它的动作，但是解析Controller的时候会被用到。
Copy after login
2) Resolve the Controller
Assuming that the Response object is not created and returned when the kernel.request event is implemented, the next step is to determine and parse the controller and the parameters required by the controller. The controller part is the last bastion of the application layer and is responsible for creating and returning Response objects containing a specific page. How to determine the requested controller depends entirely on the application. This work is completed by the controller resolver - a class that implements ControllerResolverInterface and is also a parameter of the HttpKernel constructor.First call the getController() method of the controller resolver and pass in the Request object to this method. The controller resolver determines and returns the controller based on the information contained in the Request.
The second method, getArguments() will be executed when the kernel.controller event is scheduled.
<span><em>解析Controller</em></span> <span><em>Symfony框架使用内置的ControllerResolver（实质上是使用了一个有额外的功能的子类），该解析器利用了RouterListener保存到Request对象的attributes属性里信息来确定controller。</em></span> <span><em> </em></span> <span><em>getController</em></span> <em>ControllerResolver </em><em>在Request对象的attributes数组中</em><em>查找 _controller 键（这些信息实际上是由RouterListener存放进Request对象中的）：</em> <em> </em> <em>a) 如果</em><em><span><span>_controller 键对应</span></span></em><em><span>AcmeDemoBundle:Default:index 这个格式的值，那么该值就包含了类名和方法名，可以被Symfony框架解析成为，例如：</span></em><em><span>Acme\DemoBundle\Controller\DefaultController::indexAction，这个转换是由Symfony框架的特定的</span></em><em>ControllerResolver的子类完成的。</em> <em> </em> <em>b) 你的controller类会被实例化，而且该controller类必须包含一个无参的构造函数。</em> <em> </em> <span><em>c) 如果你的controller还实现了ContainerAwareInterface，那么setContainer方法就会被调用，container就会被注入到controller中，</em></span><em><span>这个实现也是由Symfony框架的特定的</span></em><em>ControllerResolver的子类完成的。</em> <em> </em> <em><span>上面也有一些其他变化过程，例如你把你的controller配置成为service。</span></em> <em><span> </span></em> <em> </em>
Copy after login
3) The <code><code><code><span>kernel.controller</span>kernel.controllerEvent
The kernel.controller event is to initialize some information or change the controller object before the controller is executed.
After the called controller is determined, HttpKernel::handle() will dispatch the
4) Get controller parameters
The getAttributes() method returns a parameter array, which will be passed to the controller. We can also customize this method, or use the built-in Symfony framework.
ControllerResolver uses the radiation mechanism to obtain the parameter list of the called controller method. Iterate through the list and use the following steps to determine the one-to-one values in the parameter list: <code><code><span> </span></code></code>
Copy after login
<span><em>a) 使用参数作为键查找Request对象中的attributes数组，如果找到，那么相应的值会传入到controller的方法中，例如：controller方法的第一个参数是$name，那么在Request的attributes数组中包含$</em></span><em>attributes['name']的值，那么</em><span><em>$</em></span><em>attributes['name']就会被使用。</em>
Copy after login
<em> </em>
Copy after login
Copy after login
<em>b) 如果该该参数在Symfony配置routing的时候被指定，那么就会跳过对该参数的查找。</em>
Copy after login
<em> </em>
Copy after login
Copy after login
5) Call controller
controller会创建包含特定页面或者json的Response对象，这也是应用层的最后一个步骤。
<em> </em>
Symfony框架中没有缺省的监听器实现kernel.view事件，可是，有一个核心Bundle——SensioFrameworkExtraBundle里有个监听改事件的监听器。如果你的controller返回一个数组，并且在controller类的顶部有@Template的注解，那么该监听器就会渲染一个模板，把controller返回的数组传入到模板中，最后利用模板返回的内容创建一个Response对象，并返回该Response对象。
<em> </em>
除此之外，FOSRestBundle也实现了监听该事件的监听器，a listener on this event which aims to give you a robust view layer capable of using a single controller to return many different content-type responses (e.g. HTML, JSON, XML, etc).
<em> </em>
<em> </em>
7) kernel.response 事件
在发送Response对象到客户端前修改它。
kernel的目的是把Request对象转换成为Response对象。Response对象可能是在kernel.request事件中创建，可能是由controller返回，又或者是由监听kernel.view事件的监听器返回。
不管是在哪一个环节创建Response对象，最后kernel.response事件都会被触发。监听kernel.response事件的监听器都会以某种方式修改Response对象，例如：修改Response的header部分，修改cookie，或者甚至会修改Response对象返回的内容（注入javascript到
When the HttpKernel::handle method runs a subrequest, you need to modify the value of the second parameter:
A subrequest also creates a complete request-response cycle. The only difference is that some listeners may only run in the "main request" (security). The subclass of KernelEvent is passed to the listener, and the listener determines whether the current request is "main request" or "sub request" through KernelEvent::getRequestType().
For example, a listener will only be executed under the request of "main request":
