summaryrefslogtreecommitdiffstats
path: root/Http/Logout/LogoutSuccessHandlerInterface.php
Commit message (Collapse)AuthorAgeFilesLines
* Fix some annotatesbronze1man2013-09-191-0/+1
|
* fixed CSFabien Potencier2012-07-091-1/+1
|
* updated license blocksEriksen Costa2012-03-311-3/+3
|
* [DoctrineBridge] fixed some CSFabien Potencier2011-12-131-0/+1
|
* removed unused use statementsFabien Potencier2011-10-291-1/+0
|
* fixed CSFabien Potencier2011-06-081-1/+1
|
* added missing license headersFabien Potencier2011-05-311-0/+9
|
* [Security] removed un-needed event parameter from many interfacesJohannes Schmitt2011-03-181-2/+1
|
* Switched from Doctrine's EventManager implementation to the EventManager ↵Bernhard Schussek2011-03-131-3/+3
| | | | clone in Symfony2 (now called EventDispatcher again)
* Renamed EventArgs classes and adapted remaining code to EventManagerBernhard Schussek2011-03-071-3/+3
| | | | | | | The only missing part is ContainerAwareEventManager::addEventSubscriberService(), because I'm not sure how to find out the class name of a service in the DIC. Also, inline documentation of this code needs to be finished once it is accepted.
* Replaced EventDispatcher by Doctrine's EventManager implementationBernhard Schussek2011-03-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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(...));
* [Security] adds logout success handlerJohannes Schmitt2011-02-141-0/+29