This repository has been archived on 2023-08-20. You can view files and clone it, but cannot push or open issues or pull requests.
symfony/src/Symfony/Component/HttpKernel/HttpKernel.php

232 lines
7.6 KiB
PHP
Raw Normal View History

<?php
/*
* This file is part of the Symfony package.
*
* (c) Fabien Potencier <fabien@symfony.com>
*
* For the full copyright and license information, please view the LICENSE
* file that was distributed with this source code.
*/
namespace Symfony\Component\HttpKernel;
use Symfony\Component\HttpKernel\Controller\ControllerResolverInterface;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;
use Symfony\Component\HttpKernel\Event\FilterControllerEvent;
use Symfony\Component\HttpKernel\Event\FilterResponseEvent;
use Symfony\Component\HttpKernel\Event\GetResponseEvent;
use Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent;
use Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent;
use Symfony\Component\HttpKernel\Event\PostResponseEvent;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\EventDispatcher\EventDispatcherInterface;
/**
* HttpKernel notifies events to convert a Request object to a Response one.
*
* @author Fabien Potencier <fabien@symfony.com>
2011-07-20 09:14:31 +01:00
*
* @api
*/
class HttpKernel implements HttpKernelInterface, TerminableInterface
{
private $dispatcher;
private $resolver;
/**
* Constructor
*
2011-04-23 16:05:44 +01:00
* @param EventDispatcherInterface $dispatcher An EventDispatcherInterface instance
* @param ControllerResolverInterface $resolver A ControllerResolverInterface instance
2011-07-20 09:14:31 +01:00
*
* @api
*/
public function __construct(EventDispatcherInterface $dispatcher, ControllerResolverInterface $resolver)
{
$this->dispatcher = $dispatcher;
$this->resolver = $resolver;
}
/**
* Handles a Request to convert it to a Response.
*
* When $catch is true, the implementation must catch all exceptions
* and do its best to convert them to a Response instance.
*
* @param Request $request A Request instance
* @param integer $type The type of the request
* (one of HttpKernelInterface::MASTER_REQUEST or HttpKernelInterface::SUB_REQUEST)
* @param Boolean $catch Whether to catch exceptions or not
*
* @return Response A Response instance
*
* @throws \Exception When an Exception occurs during processing
2011-07-20 09:14:31 +01:00
*
* @api
*/
public function handle(Request $request, $type = HttpKernelInterface::MASTER_REQUEST, $catch = true)
{
try {
return $this->handleRaw($request, $type);
} catch (\Exception $e) {
if (false === $catch) {
throw $e;
}
return $this->handleException($e, $request, $type);
}
}
/**
2011-12-06 19:38:33 +00:00
* {@inheritdoc}
*
* @api
*/
public function terminate(Request $request, Response $response)
{
$this->dispatcher->dispatch(KernelEvents::TERMINATE, new PostResponseEvent($this, $request, $response));
}
/**
* Handles a request to convert it to a response.
*
* Exceptions are not caught.
*
* @param Request $request A Request instance
2011-04-23 16:05:44 +01:00
* @param integer $type The type of the request (one of HttpKernelInterface::MASTER_REQUEST or HttpKernelInterface::SUB_REQUEST)
*
* @return Response A Response instance
*
* @throws \LogicException If one of the listener does not behave as expected
* @throws NotFoundHttpException When controller cannot be found
*/
private function handleRaw(Request $request, $type = self::MASTER_REQUEST)
{
// request
$event = new GetResponseEvent($this, $request, $type);
$this->dispatcher->dispatch(KernelEvents::REQUEST, $event);
Replaced EventDispatcher by Doctrine's EventManager implementation Doctrine's EventManager implementation has several advantages over the EventDispatcher implementation of Symfony2. Therefore I suggest that we use their implementation. Advantages: * Event Listeners are objects, not callbacks. These objects have handler methods that have the same name as the event. This helps a lot when reading the code and makes the code for adding an event listener shorter. * You can create Event Subscribers, which are event listeners with an additional getSubscribedEvents() method. The benefit here is that the code that registers the subscriber doesn't need to know about its implementation. * All events are defined in static Events classes, so users of IDEs benefit of code completion * The communication between the dispatching class of an event and all listeners is done through a subclass of EventArgs. This subclass can be tailored to the type of event. A constructor, setters and getters can be implemented that verify the validity of the data set into the object. See examples below. * Because each event type corresponds to an EventArgs implementation, developers of event listeners can look up the available EventArgs methods and benefit of code completion. * EventArgs::stopPropagation() is more flexible and (IMO) clearer to use than notifyUntil(). Also, it is a concept that is also used in other event implementations Before: class EventListener { public function handle(EventInterface $event, $data) { ... } } $dispatcher->connect('core.request', array($listener, 'handle')); $dispatcher->notify('core.request', new Event(...)); After (with listeners): final class Events { const onCoreRequest = 'onCoreRequest'; } class EventListener { public function onCoreRequest(RequestEventArgs $eventArgs) { ... } } $evm->addEventListener(Events::onCoreRequest, $listener); $evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...)); After (with subscribers): class EventSubscriber { public function onCoreRequest(RequestEventArgs $eventArgs) { ... } public function getSubscribedEvents() { return Events::onCoreRequest; } } $evm->addEventSubscriber($subscriber); $evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...));
2011-03-05 14:30:34 +00:00
if ($event->hasResponse()) {
return $this->filterResponse($event->getResponse(), $request, $type);
}
// load controller
if (false === $controller = $this->resolver->getController($request)) {
2011-02-14 19:56:03 +00:00
throw new NotFoundHttpException(sprintf('Unable to find the controller for path "%s". Maybe you forgot to add the matching route in your routing configuration?', $request->getPathInfo()));
}
$event = new FilterControllerEvent($this, $controller, $request, $type);
$this->dispatcher->dispatch(KernelEvents::CONTROLLER, $event);
$controller = $event->getController();
// controller arguments
$arguments = $this->resolver->getArguments($request, $controller);
// call controller
$response = call_user_func_array($controller, $arguments);
// view
if (!$response instanceof Response) {
$event = new GetResponseForControllerResultEvent($this, $request, $type, $response);
$this->dispatcher->dispatch(KernelEvents::VIEW, $event);
Replaced EventDispatcher by Doctrine's EventManager implementation Doctrine's EventManager implementation has several advantages over the EventDispatcher implementation of Symfony2. Therefore I suggest that we use their implementation. Advantages: * Event Listeners are objects, not callbacks. These objects have handler methods that have the same name as the event. This helps a lot when reading the code and makes the code for adding an event listener shorter. * You can create Event Subscribers, which are event listeners with an additional getSubscribedEvents() method. The benefit here is that the code that registers the subscriber doesn't need to know about its implementation. * All events are defined in static Events classes, so users of IDEs benefit of code completion * The communication between the dispatching class of an event and all listeners is done through a subclass of EventArgs. This subclass can be tailored to the type of event. A constructor, setters and getters can be implemented that verify the validity of the data set into the object. See examples below. * Because each event type corresponds to an EventArgs implementation, developers of event listeners can look up the available EventArgs methods and benefit of code completion. * EventArgs::stopPropagation() is more flexible and (IMO) clearer to use than notifyUntil(). Also, it is a concept that is also used in other event implementations Before: class EventListener { public function handle(EventInterface $event, $data) { ... } } $dispatcher->connect('core.request', array($listener, 'handle')); $dispatcher->notify('core.request', new Event(...)); After (with listeners): final class Events { const onCoreRequest = 'onCoreRequest'; } class EventListener { public function onCoreRequest(RequestEventArgs $eventArgs) { ... } } $evm->addEventListener(Events::onCoreRequest, $listener); $evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...)); After (with subscribers): class EventSubscriber { public function onCoreRequest(RequestEventArgs $eventArgs) { ... } public function getSubscribedEvents() { return Events::onCoreRequest; } } $evm->addEventSubscriber($subscriber); $evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...));
2011-03-05 14:30:34 +00:00
if ($event->hasResponse()) {
$response = $event->getResponse();
Replaced EventDispatcher by Doctrine's EventManager implementation Doctrine's EventManager implementation has several advantages over the EventDispatcher implementation of Symfony2. Therefore I suggest that we use their implementation. Advantages: * Event Listeners are objects, not callbacks. These objects have handler methods that have the same name as the event. This helps a lot when reading the code and makes the code for adding an event listener shorter. * You can create Event Subscribers, which are event listeners with an additional getSubscribedEvents() method. The benefit here is that the code that registers the subscriber doesn't need to know about its implementation. * All events are defined in static Events classes, so users of IDEs benefit of code completion * The communication between the dispatching class of an event and all listeners is done through a subclass of EventArgs. This subclass can be tailored to the type of event. A constructor, setters and getters can be implemented that verify the validity of the data set into the object. See examples below. * Because each event type corresponds to an EventArgs implementation, developers of event listeners can look up the available EventArgs methods and benefit of code completion. * EventArgs::stopPropagation() is more flexible and (IMO) clearer to use than notifyUntil(). Also, it is a concept that is also used in other event implementations Before: class EventListener { public function handle(EventInterface $event, $data) { ... } } $dispatcher->connect('core.request', array($listener, 'handle')); $dispatcher->notify('core.request', new Event(...)); After (with listeners): final class Events { const onCoreRequest = 'onCoreRequest'; } class EventListener { public function onCoreRequest(RequestEventArgs $eventArgs) { ... } } $evm->addEventListener(Events::onCoreRequest, $listener); $evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...)); After (with subscribers): class EventSubscriber { public function onCoreRequest(RequestEventArgs $eventArgs) { ... } public function getSubscribedEvents() { return Events::onCoreRequest; } } $evm->addEventSubscriber($subscriber); $evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...));
2011-03-05 14:30:34 +00:00
}
if (!$response instanceof Response) {
$msg = sprintf('The controller must return a response (%s given).', $this->varToString($response));
// the user may have forgotten to return something
if (null === $response) {
$msg .= ' Did you forget to add a return statement somewhere in your controller?';
}
throw new \LogicException($msg);
}
}
Replaced EventDispatcher by Doctrine's EventManager implementation Doctrine's EventManager implementation has several advantages over the EventDispatcher implementation of Symfony2. Therefore I suggest that we use their implementation. Advantages: * Event Listeners are objects, not callbacks. These objects have handler methods that have the same name as the event. This helps a lot when reading the code and makes the code for adding an event listener shorter. * You can create Event Subscribers, which are event listeners with an additional getSubscribedEvents() method. The benefit here is that the code that registers the subscriber doesn't need to know about its implementation. * All events are defined in static Events classes, so users of IDEs benefit of code completion * The communication between the dispatching class of an event and all listeners is done through a subclass of EventArgs. This subclass can be tailored to the type of event. A constructor, setters and getters can be implemented that verify the validity of the data set into the object. See examples below. * Because each event type corresponds to an EventArgs implementation, developers of event listeners can look up the available EventArgs methods and benefit of code completion. * EventArgs::stopPropagation() is more flexible and (IMO) clearer to use than notifyUntil(). Also, it is a concept that is also used in other event implementations Before: class EventListener { public function handle(EventInterface $event, $data) { ... } } $dispatcher->connect('core.request', array($listener, 'handle')); $dispatcher->notify('core.request', new Event(...)); After (with listeners): final class Events { const onCoreRequest = 'onCoreRequest'; } class EventListener { public function onCoreRequest(RequestEventArgs $eventArgs) { ... } } $evm->addEventListener(Events::onCoreRequest, $listener); $evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...)); After (with subscribers): class EventSubscriber { public function onCoreRequest(RequestEventArgs $eventArgs) { ... } public function getSubscribedEvents() { return Events::onCoreRequest; } } $evm->addEventSubscriber($subscriber); $evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...));
2011-03-05 14:30:34 +00:00
return $this->filterResponse($response, $request, $type);
}
/**
* Filters a response object.
*
* @param Response $response A Response instance
2011-05-30 00:25:35 +01:00
* @param Request $request A error message in case the response is not a Response object
* @param integer $type The type of the request (one of HttpKernelInterface::MASTER_REQUEST or HttpKernelInterface::SUB_REQUEST)
*
* @return Response The filtered Response instance
*
* @throws \RuntimeException if the passed object is not a Response instance
*/
private function filterResponse(Response $response, Request $request, $type)
{
$event = new FilterResponseEvent($this, $request, $type, $response);
$this->dispatcher->dispatch(KernelEvents::RESPONSE, $event);
return $event->getResponse();
}
/**
* Handles and exception by trying to convert it to a Response.
*
* @param \Exception $e An \Exception instance
* @param Request $request A Request instance
* @param integer $type The type of the request
*
* @return Response A Response instance
*/
private function handleException(\Exception $e, $request, $type)
{
$event = new GetResponseForExceptionEvent($this, $request, $type, $e);
$this->dispatcher->dispatch(KernelEvents::EXCEPTION, $event);
if (!$event->hasResponse()) {
throw $e;
}
try {
return $this->filterResponse($event->getResponse(), $request, $type);
} catch (\Exception $e) {
return $event->getResponse();
}
}
private function varToString($var)
{
if (is_object($var)) {
return sprintf('Object(%s)', get_class($var));
}
if (is_array($var)) {
$a = array();
foreach ($var as $k => $v) {
$a[] = sprintf('%s => %s', $k, $this->varToString($v));
}
return sprintf("Array(%s)", implode(', ', $a));
}
if (is_resource($var)) {
return sprintf('Resource(%s)', get_resource_type($var));
}
if (null === $var) {
return 'null';
}
if (false === $var) {
return 'false';
}
if (true === $var) {
return 'true';
}
return (string) $var;
}
}