* 3.4:
[3.4] Remove useless docblocks
[3.3] More docblock fixes
[2.7] More docblock fixes
[TwigBridge] Fix BC break due required twig environment
Random fixes
Docblock fixes
[DI] Fix cannot bind env var
Fix some signatures in PHP-DSLs
[HttpKernel] Enhance deprecation message
bumped Symfony version to 3.4.0
updated VERSION for 3.4.0-BETA3
updated CHANGELOG for 3.4.0-BETA3
[SecurityBundle] Fix the datacollector to properly support decision.object being null
* 3.3:
Random fixes
Docblock fixes
[HttpKernel] Enhance deprecation message
[SecurityBundle] Fix the datacollector to properly support decision.object being null
* 3.1:
Disable CLI color for Windows 10 greater than 10.0.10586
Exception details break the layout
[HttpKernel] Remove wrong docblock
[HttpKernel] Fix HttpCache validation HTTP method
[FrameworkBundle] Fix default lifetime of cache pools
Move space from the before 'if' to the after 'if'
[TwigBundle] Add a check for choice's attributes emptiness before calling block('attributes')
* 2.7:
Disable CLI color for Windows 10 greater than 10.0.10586
Exception details break the layout
[HttpKernel] Remove wrong docblock
[HttpKernel] Fix HttpCache validation HTTP method
Move space from the before 'if' to the after 'if'
[TwigBundle] Add a check for choice's attributes emptiness before calling block('attributes')
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(...));
