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/KernelEvents.php

104 lines
3.0 KiB
PHP
Raw Normal View History

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
<?php
/*
* This file is part of the Symfony package.
*
2011-03-17 15:02:36 +00:00
* (c) Fabien Potencier <fabien@symfony.com>
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
*
* For the full copyright and license information, please view the LICENSE
* file that was distributed with this source code.
*/
namespace Symfony\Component\HttpKernel;
/**
2014-12-21 17:00:50 +00:00
* Contains all events thrown in the HttpKernel component.
*
2012-05-26 08:48:33 +01:00
* @author Bernhard Schussek <bschussek@gmail.com>
*/
final class KernelEvents
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
{
/**
2011-05-30 08:04:37 +01:00
* The REQUEST event occurs at the very beginning of request
2014-12-21 17:00:50 +00:00
* dispatching.
*
* This event allows you to create a response for a request before any
* other code in the framework is executed.
*
* @Event("Symfony\Component\HttpKernel\Event\RequestEvent")
*/
const REQUEST = 'kernel.request';
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
/**
2014-12-21 17:00:50 +00:00
* The EXCEPTION event occurs when an uncaught exception appears.
*
* This event allows you to create a response for a thrown exception or
* to modify the thrown exception.
*
* @Event("Symfony\Component\HttpKernel\Event\ExceptionEvent")
*/
const EXCEPTION = 'kernel.exception';
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
/**
2011-05-30 08:04:37 +01:00
* The CONTROLLER event occurs once a controller was found for
2014-12-21 17:00:50 +00:00
* handling a request.
*
* This event allows you to change the controller that will handle the
* request.
*
* @Event("Symfony\Component\HttpKernel\Event\ControllerEvent")
*/
const CONTROLLER = 'kernel.controller';
/**
* The CONTROLLER_ARGUMENTS event occurs once controller arguments have been resolved.
*
* This event allows you to change the arguments that will be passed to
* the controller.
*
* @Event("Symfony\Component\HttpKernel\Event\ControllerArgumentsEvent")
*/
const CONTROLLER_ARGUMENTS = 'kernel.controller_arguments';
/**
* The VIEW event occurs when the return value of a controller
* is not a Response instance.
*
* This event allows you to create a response for the return value of the
* controller.
*
* @Event("Symfony\Component\HttpKernel\Event\ViewEvent")
*/
const VIEW = 'kernel.view';
/**
2011-05-30 08:04:37 +01:00
* The RESPONSE event occurs once a response was created for
2014-12-21 17:00:50 +00:00
* replying to a request.
*
* This event allows you to modify or replace the response that will be
* replied.
*
* @Event("Symfony\Component\HttpKernel\Event\ResponseEvent")
*/
const RESPONSE = 'kernel.response';
2013-04-18 09:33:03 +01:00
/**
2014-04-17 07:05:16 +01:00
* The FINISH_REQUEST event occurs when a response was generated for a request.
2013-04-18 09:33:03 +01:00
*
* This event allows you to reset the global and environmental state of
* the application, when it was changed during the request.
2016-05-02 18:24:41 +01:00
*
* @Event("Symfony\Component\HttpKernel\Event\FinishRequestEvent")
2013-04-18 09:33:03 +01:00
*/
const FINISH_REQUEST = 'kernel.finish_request';
/**
* The TERMINATE event occurs once a response was sent.
*
* This event allows you to run expensive post-response jobs.
*
* @Event("Symfony\Component\HttpKernel\Event\TerminateEvent")
*/
const TERMINATE = 'kernel.terminate';
2011-05-30 08:04:37 +01:00
}