Commit Graph

21 Commits

Author SHA1 Message Date
Fabien Potencier
fc372bc217 [HttpKernel] changed core.view event to use notifyUntil() instead of filter() -- as soon as a listener returns a Response, we are done 2011-02-21 18:24:55 +01:00
Fabien Potencier
12f99dd066 fixed typo 2011-02-14 20:56:03 +01:00
Fabrice Bernhard
20e31cd3f2 [HttpKernel] Added some details for two commonly encountered errors in Kernel.php and HttpKernel.php
I used https://github.com/fabpot/symfony/blob/master/src/Symfony/Component/Form/PropertyPath.php#L324 as a model for the wording
2011-02-14 20:51:55 +01:00
Fabien Potencier
c05fb03c7d [HttpKernel] changed the core.view event to only be notified when the controller does not return a Response 2011-02-03 19:39:28 +01:00
Fabien Potencier
5f11e49d0b [HttpKernel] made exceptions more robust (avoid too deep nested arrays PHP errors) 2011-01-29 15:31:46 +01:00
Fabien Potencier
8b62df7247 changed the EventDispatcher and Event interfaces
The three notification methods do not return the Event instance anymore.

notify() does not return anything
notifyUntil() returns the returned value of the event that has processed the event
filter() returns the filtered value

Upgrading your listeners:
Listeners for notify() and filter() events: nothing to change
Listeners for notifyUntil() events:

Before:

    $event->setReturnValue('foo');
    return true;

After:

    $event->setProcessed();
    return 'foo';

If you notify events, the processing also need to be changed:

For filter() notifications: the filtered value is now available as
the returned value of the filter() method.

For notifyUntil() notifications:

Before:

    $event = $dispatcher->notifyUntil($event);
    if ($event->isProcessed()) {
        $ret = $event->getReturnValue();

        // do something with $ret
    }

After:

    $ret = $dispatcher->notifyUntil($event);
    if ($event->isProcessed()) {
        // do something with $ret
    }
2011-01-26 08:41:59 +01:00
Fabien Potencier
0e66e388ec added two interfaces: EventInterface and EventDispatcherInterface 2011-01-25 14:23:32 +01:00
Fabien Potencier
183c8c6f6c fixed CS 2011-01-23 07:37:01 +01:00
Jordi Boggiano
74272e02da [HttpKernel] Added path to controller not found exception 2011-01-23 07:35:41 +01:00
Johannes M. Schmitt
1d5b6ed908 adds scope to the DI container 2011-01-22 15:20:50 +01:00
Dominique Bongiraud
64fb94c725 normalized license messages in PHP files 2011-01-18 08:07:46 +01:00
Fabien Potencier
b3149a235b [HttpKernel] fixed request management in HttpKernel 2010-12-10 09:30:32 +01:00
Fabien Potencier
bff58d14d7 [HttpKernel] fixed request management in HttpKernel 2010-12-10 09:24:14 +01:00
Fabien Potencier
da26584735 [HttpKernel] fixed request management in HttpKernel 2010-12-10 09:21:31 +01:00
Kris Wallsmith
5da423be20 [HttpKernel] Added getRequest() to HttpKernelInterface. 2010-12-10 08:43:05 +01:00
Jeremy Mikola
2ff474fc3a [HttpKernel][FrameworkBundle] Rename BaseHttpKernel to HttpKernel
The original HttpKernel class can be deleted, as it's request-stashing will be moved to the Kernel class.  FrameworkBundle's list of compiled classes must also be modified to respect this change.
2010-12-09 09:38:13 +01:00
Fabien Potencier
7b02766373 fixed session management
Some explanations on how it works now:

 * The Session is an optional dependency of the Request. If you create the
   Request yourself (which is mandatory now in the front controller) and if
   you don't inject a Session yourself (which is recommended if you want the
   session to be configured via dependency injection), the Symfony2 Kernel
   will associate the Session configured in the Container with the Request
   automatically.

 * When duplicating a request, the session is shared between the parent and
   the child (that's because duplicated requests are sub-requests of the main
   one most of the time.) Notice that when you use ::create(), the behavior is
   the same as for the constructor; no session is attached to the Request.

 * Symfony2 tries hard to not create a session cookie when it is not needed
   but a Session object is always available (the cookie is only created when
   "something" is stored in the session.)

 * Symfony2 only starts a session when:

   * A session already exists in the request ($_COOKIE[session_name()] is
     defined -- this is done by RequestListener);

   * There is something written in the session object (the cookie will be sent
     to the Client).

 * Notice that reading from the session does not start the session anymore (as
   we don't need to start a new session to get the default values, and because
   if a session exists, it has already been started by RequestListener.)
2010-11-09 22:34:48 +01:00
Fabien Potencier
a471f65759 [HttpKernel] tweaked HttpKernelInterface 2010-11-06 15:13:23 +01:00
Kris Wallsmith
f79e23ffb5 Removed all those spaces after @author that were bothering me so… 2010-10-18 16:55:41 +02:00
Fabien Potencier
7e66933876 fixed inconsistency when calling the Http Kernel instance from an event 2010-10-15 11:02:35 +02:00
Fabien Potencier
bf82cf42dd renamed Symfony\Components to Symfony\Component 2010-08-20 23:09:55 +02:00