Symfoy2 Httpkernel Event Driver

Httpkernel: Event-drivenSymfony2both the framework layer and the application layer work inHttpkernel::handle ()method is completed,Httpkernel::handle ()the internal implementation is actually through the dispatch event (Httpkernelevent listeners within the), which is equivalent to integrating all the components into a complete application. Using Httpkernelvery simple, just create a eventdispatcher(event dispatcher) and Controller Resolver(Controller parser) to enable more event listeners to enrich the application's functionality:1) kernel.requestEvent Implementation Kernel.requestThe purpose of the event is to add more information to the request object, or to get the returned response object (for example, to get from the cache or to deny access by the security layer)        Kernel.requestevent isHttpkernel::handle ()The first event that is dispatched, then multiple listeners listening to the event are executed. Monitor Kernel.requestevent listeners vary in their behavior, such as a Redirectresponse object when the security listener determines that the user does not have sufficient permissions, and if the response object is currently directly returned, it will be executed directly Kernel.response Event:Other listeners implement some initialization or add more information to the request object. For example, the routing listener obtains routing-related information from the request object, undergoes further processing, determines the controller that processes the request, and saves the corresponding information to the '        Attribute ', this information will be used by the controller parser, so you can implement the decoupling between listeners. In a sense, achieving kernel.requestThe purpose of the event is either to create and return the response object directly, or to add more information to the request object.  

Routerlistener is the most important listenerfor implementing Kernel.request events in the Symfony framework, Routerlistener executed in the routing layer, Returns an array containing the routing information that conforms to the current request, such as _controller in the route matching pattern and the requested parameter ({name}).         This information will be stored in the attributes array in the request and will only add the routing information to the request object, but it will be used when parsing the controller.

2) Resolve The Controller assumes the implementation of Kernel.requestevent without creating and returning response objects, the next step is to identify, parse, and resolve the parameters required by the controller and Controller. The controller section is the last bastion of the application layer and is responsible for creating and returning response objects that contain a specific page. How to determine the requested controller depends entirely on the application, which is done with the controller parser-a class that implements Controllerresolverinterface and a parameter to the Httpkernel constructor.  Two ways to implement Controllerresolverinterface Getcontroller and Getarguments:httpkernel::handle ()First call the controller resolver's Getcontroller () method and pass the request object to the method .Controller resolver determines and returns the controller based on the information contained in the request. The second method, Getarguments () executes when the Kernel.controller event is dispatched.

Parsing Controller The Symfony framework uses a built-in controllerresolver (essentially a subclass with extra functionality), The parser uses the information routerlistener saved to the Attributes property of the Request object to determine the controller.   Getcontroller Controllerresolver In the attributes array of the Request object Find the _controller key (this information is actually stored by Routerlistener in the Request object):   a) if _controller key corresponding AcmeDemoBundle:Default:index The value of this format, the value contains the class name and the method name, which can be parsed by the Symfony framework, for example: Acme\demobundle\controller\defaultcontroller::indexaction, this conversion is made by the Symfony framework of the specific The subclass of Controllerresolver is complete.   b) Your controller class will be instantiated, and the Controller class must contain a parameterless constructor.   c) If your controller also implements Containerawareinterface, then the Setcontainer method will be called and the container will be injected into the controller, This implementation is also specified by the Symfony framework The subclass of Controllerresolver is complete.   There are some other changes, such as configuring your controller as a service.         

3) the kernel.controller Event

The Kernel.controller event initializes some information or alters the Controller object before the controller is executed.

After the called controller is determined,Httpkernel::handle () dispatches the Kernel.controller event. After a certain part of the system is determined (for example: Controller, routing information, etc.) but before these parts are executed, the listener listening for the Kernel.controller event will run.

 

The

kernel.controller symfony Framework has several listeners for Kernel.controller events, most of which are processing analytical data. a listener in Sensioframeworkextrabundle Paramconverter allows us to pass an object as a parameter into the controller instead of a string or numeric parameter.

  4) Get parameters of controllerThe GetAttributes () method returns an array of arguments, which are passed to the controller, and we can customize the method or use the Symfony framework built-in.

At this point, kernel has obtained the parameters that the controller and controller need to run.  

Symfony Framework obtains parameters of controller

ControllerResolver使用放射机制获得被调用的controller的方法的参数列表。遍历该列表，使用下面的步骤来确定参数列表中一一对应的值：

 

a) use the parameter as the key to find the attributes array in the Request object, and if found, the corresponding value is passed into the controller's method, for example: the first parameter of the Controller method is $name, Then the value of $ attributes[' name ' is included in the attributes array of request, then $ attributes[' name ' will be used.

 

b) If the parameter is specified when the Symfony configuration is routing, then the lookup of the parameter is skipped.

 

5) Call Controller

This step, the controller will be executed.         The controller creates a response object that contains a specific page or JSON, which is the last step of the application layer. If the controller returns a response object, then the next Kernel.response event will be triggered, and the Kernel.view event will be triggered.

The controller must have a return value, and if NULL is returned, the program will error

6) Kernel.view Event

The controller return value is not triggered when the response object is not.

If the controller returns a response object, the Kernel.view event is triggered, and the purpose of the Kernel.view event is to create a response object for the value returned by the controller. It is also good to listen for the Kernel.view event, and if the controller returns an HTML page or JSON string, we can wrap the HTML page or JSON string into the response object by listening to the Kernel.view event, then the Symfony frame remains         can run correctly. However, if no listener does not set the response object to the event, then the program will error. Either the controller orOne of the view listeners must always return a Response.  

implementing Kernel.view Events in the Symfony framework

There is no default listener in the Symfony framework to implement the Kernel.view event, but there is a listener in the core bundle--sensioframeworkextrabundle that listens to the change event. If your controller returns an array and has @template annotations at the top of the controller class, the listener renders a template that passes the array returned by the controller to the template, Finally, a response object is created with the content returned by the template, and the response object is returned. In addition, Fosrestbundle also implements the listener that listens to the event, a listener on this event which the aims to give you a robust view layer cap Able of using a single controller to return many different content-type responses (e.g. HTML, JSON, XML, etc).

    7) kernel.response event Modify the Response object before sending it to the client.        The purpose of kernel is to convert the request object into a response object. The response object may be created in the Kernel.request event, either by the controller or by the listener listening for the Kernel.view event. The last Kernel.response event is triggered regardless of the link in which the response object is created. Listeners listening to the Kernel.response event modify the response object in some way, such as modifying the header portion of the response, modifying the cookie, or even modifying the content returned by the response object (injecting JavaScript into </body> pre-label, etc.)after the Kernel.response event is complete,Httpkernel::handle ()returns the final response object, calling the Response::send () box client to send headers headers and response entities.  

the symfony Framework implements the Kernel.response event symfony framework with several listeners listening for kernel.response events, much more available through the developer community. For example, in the Dev development environment Webdebugtoolbarlistener injects JavaScript code to the bottom of the page, and the Debug toolbar is displayed. There is another listener that contextlistener the current user's information to the session and reloads the user information directly in the session at the next request.

   

8) Kernel.terminate event

listeners listening to this event are usually dealing with some time-consuming background programs. The last event of the Httpkernel process is the Kernel.terminate event, and the event is triggered at Httpkernel::handle ()method, and the content of the response has been sent to the user. As shown above, the Terminate method is called after the response is sent to the client, the Kernel.terminate event is triggered within the Terminate method, and the listener listening for the event runs, all of which are executed after sending the response information to the client. (such as sending mail)

Monitor the Kernel.terminate event in the symfony

.

Symfony Framework a complete workflowWhen using the Httpkernel component, we do not need to implement any listener additions to the kernel event, nor do we need to implement the Controller resolver. The HTTP component's own listener and controller resolver will work correctly: Child RequestIn addition to the "main request" in the Httpkernel::handle, you can also put the so-called "sub request" into the httpkernel::handle. The child request looks similar to the other requests, but the general request is to render a complete page, and the child request renders a portion of the page.        Usually we create a sub-request (or create it inside a template) in the controller. When the Httpkernel::handle method runs a sub-request, it needs to modify the value of the second parameter: The child request also creates a complete request-the response period. The only difference is that some listeners may only run in "Main request" (security).        The Kernelevent subclass 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 execute at the request of "main request":

Symfoy2 Httpkernel Event Driver