核心功能

注解

Read more about the HttpFoundation component.

参见

Read more about the HttpKernel component, Dependency Injection and Bundles.

function handle(Request $request, $type = self::MASTER_REQUEST, $catch = true)

小技巧

The default implementation uses the RouterListener to define the _controller Request attribute (see kernel.request Event).

Matching Controller Method Arguments from Request Attributes

For each method argument, Symfony tries to get the value of a Request attribute with the same name. If it is not defined, the argument default value is used if defined:

// Symfony will look for an 'id' attribute (mandatory)
// and an 'admin' one (optional)
public function showAction($id, $admin = true)
{
    // ...
}

isMasterRequest()¶

The isMasterRequest() method allows listeners to check the type of the request. For instance, if a listener must only be active for master requests, add the following code at the beginning of your listener method:

use SymfonyComponentHttpKernelHttpKernelInterface;

if (!$event->isMasterRequest()) {
    // return immediately
    return;
}

kernel.request Event¶

Event Class: GetResponseEvent

The goal of this event is to either return a Response object immediately or setup variables so that a Controller can be called after the event. Any listener can return a Response object via the setResponse() method on the event. In this case, all other listeners won’t be called.

This event is used by the FrameworkBundle to populate the _controller Request attribute, via the RouterListener. RequestListener uses a RouterInterface object to match the Request and determine the Controller name (stored in the _controller Request attribute).

kernel.controller Event¶

Event Class: FilterControllerEvent

This event is not used by the FrameworkBundle, but can be an entry point used to modify the controller that should be executed:

use SymfonyComponentHttpKernelEventFilterControllerEvent;

public function onKernelController(FilterControllerEvent $event)
{
    $controller = $event->getController();
    // ...

    // the controller can be changed to any PHP callable
    $event->setController($controller);
}

kernel.view Event¶

Event Class: GetResponseForControllerResultEvent

This event is not used by the FrameworkBundle, but it can be used to implement a view sub-system. This event is called only if the Controller does not return a Response object. The purpose of the event is to allow some other return value to be converted into a Response.

The value returned by the Controller is accessible via the getControllerResult method:

use SymfonyComponentHttpKernelEventGetResponseForControllerResultEvent;
use SymfonyComponentHttpFoundationResponse;

public function onKernelView(GetResponseForControllerResultEvent $event)
{
    $val = $event->getControllerResult();
    $response = new Response();

    // ... some how customize the Response from the return value

    $event->setResponse($response);
}

kernel.response Event¶

Event Class: FilterResponseEvent

The purpose of this event is to allow other systems to modify or replace the Response object after its creation:

public function onKernelResponse(FilterResponseEvent $event)
{
    $response = $event->getResponse();

    // ... modify the response object
}

The FrameworkBundle registers several listeners:

• ProfilerListener
• Collects data for the current request.
• WebDebugToolbarListener
• Injects the Web Debug Toolbar.
• ResponseListener
• Fixes the Response Content-Type based on the request format.
• EsiListener
• Adds a Surrogate-Control HTTP header when the Response needs to be parsed for ESI tags.

kernel.finish_request Event¶

Event Class: FinishRequestEvent

The purpose of this event is to handle tasks that should be performed after the request has been handled but that do not need to modify the response. Event listeners for the kernel.finish_request event are called in both successful and exception cases.

kernel.terminate Event¶

Event Class: PostResponseEvent

The purpose of this event is to perform “heavier” tasks after the response was already served to the client.

kernel.exception Event¶

Event Class: GetResponseForExceptionEvent

The FrameworkBundle registers an ExceptionListener that forwards the Request to a given Controller (the value of the exception_listener.controller parameter – must be in the class::method notation).

A listener on this event can create and set a Response object, create and set a new Exception object, or do nothing:

use SymfonyComponentHttpKernelEventGetResponseForExceptionEvent;
use SymfonyComponentHttpFoundationResponse;

public function onKernelException(GetResponseForExceptionEvent $event)
{
    $exception = $event->getException();
    $response = new Response();
    // setup the Response object based on the caught exception
    $event->setResponse($response);

    // you can alternatively set a new Exception
    // $exception = new Exception('Some special exception');
    // $event->setException($exception);
}

return new Response(
    'Error',
    Response::HTTP_NOT_FOUND, // ignored
    array('X-Status-Code' => Response::HTTP_OK)
);

使用调试工具条¶

In the development environment, the web debug toolbar is available at the bottom of all pages. It displays a good summary of the profiling data that gives you instant access to a lot of useful information when something does not work as expected.

If the summary provided by the Web Debug Toolbar is not enough, click on the token link (a string made of 13 random characters) to access the Web Profiler.

使用分析工具做代码分析¶

The Web Profiler is a visualization tool for profiling data that you can use in development to debug your code and enhance performance; but it can also be used to explore problems that occur in production. It exposes all information collected by the profiler in a web interface.

访问代码分析数据¶

You don’t need to use the default visualizer to access the profiling information. But how can you retrieve profiling information for a specific request after the fact? When the profiler stores data about a Request, it also associates a token with it; this token is available in the X-Debug-Token HTTP header of the Response:

$profile = $container->get('profiler')->loadProfileFromResponse($response);

$profile = $container->get('profiler')->loadProfile($token);

Use the find() method to access tokens based on some criteria:

// get the latest 10 tokens
$tokens = $container->get('profiler')->find('', '', 10, '', '');

// get the latest 10 tokens for all URL containing /admin/
$tokens = $container->get('profiler')->find('', '/admin/', 10, '', '');

// get the latest 10 tokens for local requests
$tokens = $container->get('profiler')->find('127.0.0.1', '', 10, '', '');

// get the latest 10 tokens for requests that happened between 2 and 4 days ago
$tokens = $container->get('profiler')
    ->find('', '', 10, '4 days ago', '2 days ago');

If you want to manipulate profiling data on a different machine than the one where the information were generated, use the export() and import() methods:

// on the production machine
$profile = $container->get('profiler')->loadProfile($token);
$data = $profiler->export($profile);

// on the development machine
$profiler->import($data);

配置¶

The default Symfony configuration comes with sensible settings for the profiler, the web debug toolbar, and the web profiler. Here is for instance the configuration for the development environment:

When only_exceptions is set to true, the profiler only collects data when an exception is thrown by the application.

When intercept_redirects is set to true, the web profiler intercepts the redirects and gives you the opportunity to look at the collected data before following the redirect.

If you enable the web profiler, you also need to mount the profiler routes:

As the profiler adds some overhead, you might want to enable it only under certain circumstances in the production environment. The only_exceptions settings limits profiling to exceptions, but what if you want to get information when the client IP comes from a specific address, or for a limited portion of the website? You can use a Profiler Matcher, learn more about that in “How to Use Matchers to Enable the Profiler Conditionally”.