Commit Graph

7 Commits

Author SHA1 Message Date
Bernhard Schussek
f1393d7b1f 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 15:30:34 +01:00
Fabien Potencier
353177d1d6 replaced Response::createRedirect by a new RedirectResponse class 2011-02-21 18:10:53 +01:00
Fabien Potencier
d94acd85f9 remove response as a service
The Response is not available in the DIC anymore.

When you need to create a response, create an instance of
Symfony\Component\HttpFoundation\Response instead.

As a side effect, the Controller::createResponse() and Controller::redirect()
methods have been removed and can easily be replaced as follows:

  return $this->createResponse('content', 200, array('foo' => 'bar'));
  return new Response('content', 200, array('foo' => 'bar'));

  return $this->redirect($url);
  return Response::createRedirect($url);
2011-02-21 17:36:04 +01:00
Johannes Schmitt
19bbafc441 [Security] Refactored security context, moved getUser() implementation to templating 2011-02-12 21:53:04 +01:00
Lukas Kahwe Smith
dd71501f54 some fixes by just "blindly" trying to make phpStorm code analysis happier 2011-02-04 19:30:28 +01:00
Johannes M. Schmitt
2b697423b4 [Security] bug fix in FormAuthenticationEntryPoint 2011-02-02 11:31:28 +01:00
Johannes M. Schmitt
cf64d2cfe7 namespace changes
Symfony\Component\Security -> Symfony\Component\Security\Core
Symfony\Component\Security\Acl remains unchanged
Symfony\Component\HttpKernel\Security -> Symfony\Component\Security\Http
2011-01-26 22:23:20 +01:00