merged branch drak/session_flashmessages (PR #3267)

Commits
-------

5ae76f1 [HttpFoundation] Update documentation.
910b5c7 [HttpFoudation] CS, more tests and some optimization.
b0466e8 [HttpFoundation] Refactored BC Session class methods.
84c2e3c [HttpFoundation] Allow flash messages to have multiple messages per type.

Discussion
----------

[2.1][HttpFoundation] Multiple session flash messages

Bug fix: no
Feature addition: yes
Backwards compatibility break: yes, but this already happened in #2583.  BC `Session` methods remain unbroken.
Symfony2 tests pass: yes
Fixes the following tickets: #1863
References the following tickets: #2714, #2753, #2510, #2543, #2853
Todo: -

This PR alters flash messages so that it is possible to store more than one message per flash type using the `add()` method or by passing an array of messages to `set()`.

__NOTES ABOUT BC__

This PR maintains BC behaviour with the `Session` class in that the old Symfony 2.0 methods will continue to work as before.

---------------------------------------------------------------------------

by drak at 2012-02-13T06:28:33Z

I think this is ready for review @fabpot @lsmith77

---------------------------------------------------------------------------

by lsmith77 at 2012-02-14T19:30:39Z

the FlashBag vs. AutoExpireFlashBag behavior and setup difference should probably also be explained in the upgrading log

---------------------------------------------------------------------------

by drak at 2012-02-15T04:43:14Z

@lsmith77 Those differences are explained already in the changelog

 * Added `FlashBag`. Flashes expire when retrieved by `get()` or `all()`.
   This makes the implementation ESI compatible.
 * Added `AutoExpireFlashBag` (default) to replicate Symfony 2.0.x auto expire behaviour of messages auto expiring
   after one page page load.  Messages must be retrived by `get()` or `all()`.

---------------------------------------------------------------------------

by Crell at 2012-02-19T17:35:34Z

Drak asked me to weigh in here with use cases.  Drupal currently has a similar session-stored-messaging system in place that I'd like to be able to replace with Flash messages.  We frequently have multiple messages within a single request, however, so this change is critical to our being able to do so.

For instance, when saving an article in Drupal there is, by default, a "yay, you saved an article!" type message that gets displayed.  If you also have the site configured to send email when a post is updated, you may see a "email notifications sent" message (depending on your access level).  If you have a Solr server setup for search, and you're in debug mode, there will also be a "record ID X added to Solr, it should update in 2 minutes" message.  And if there's a bug somewhere, you'll also get, as an error message rather than notice message, a "Oops, E_NOTICE on line 54" message.

Form validation is another case.  If you have multiple errors in a single form, we prefer to list all of them.  So if you screw up 4 times on a form, you may get 4 different error messages showing what you screwed up so you can fix it in one go instead of several.

Now sure, one could emulate that by building a multi-message layer on top of single-layer messages, but, really, why?  "One is a special case of many", and there are many many cases where you'll want to post multiple messages.  Like, most of Drupal. :-)

---------------------------------------------------------------------------

by lsmith77 at 2012-03-06T20:55:51Z

@fabpot is there any information you still need before merging this? do you want more discussion in which case you might want to take this to the mailing list ..

---------------------------------------------------------------------------

by drak at 2012-03-08T18:54:13Z

Another plus for this PR is that it requires no extra lines of code in templates etc to display the flashes, see https://github.com/symfony/symfony/pull/3267/files#diff-1

---------------------------------------------------------------------------

by drak at 2012-03-15T06:38:21Z

Rebased against current `master`, should be mergeable again..

---------------------------------------------------------------------------

by evillemez at 2012-03-17T03:08:41Z

+1 to this, I have an extended version of HttpFoundation just for this... would love to get rid of it.
[HttpFoundation] fixed a test
tweaked UPGRADE file
merged branch schmittjoh/processFailedException (PR #3633)

Commits
-------

57de69f added an exception for failed processes

Discussion
----------

added an exception for failed processes

---------------------------------------------------------------------------

by Seldaek at 2012-03-19T07:27:56Z

So this is just there to use if you want to throw an exception when a process call failed in your application? It doesn't seem enabled by default, which I think is good anyway.

---------------------------------------------------------------------------

by stof at 2012-03-19T07:44:43Z

@Seldaek yeah, I guess this is a way to make it easier to reuse what he implemented for Assetic first.

---------------------------------------------------------------------------

by fabpot at 2012-03-23T15:08:26Z

How and when do you use such an exception?

---------------------------------------------------------------------------

by schmittjoh at 2012-03-23T17:22:16Z

It's intended for your own code to give you a nice and meaningful error message without having to repeat the same code whereever you are dealing with a Process:

```php
if (0 !== $proc->run()) {
    throw new ProcessFailedException($proc);
}
[HttpFoundation] made the host lowercase as per RFC 952/2181
fixed previous commit
HttpFoundation\HeaderBag Little improvement.
typo fix in upgrading guide
merged branch lsmith77/patch-1 (PR #3695)

Commits
-------

72bf93f typo fix in upgrading guide

Discussion
----------

typo fix in upgrading guide

cc @drak
merged branch marcw/patch-security-refresh-user (PR #3402)

Commits
-------

10947cb [DoctrineBridge][Security] Fixes bug that prevents repository's refreshUser from being called

Discussion
----------

[Security][DoctrineBridge] Fixes bug that prevents repository's refreshUser from being called

---------------------------------------------------------------------------

by marcw at 2012-02-21T08:46:09Z

Updated. What do you guys think about this patch ?

---------------------------------------------------------------------------

by henrikbjorn at 2012-02-21T08:57:47Z

Isnt this a bit dangerous, the custom repository implementing refreshUser should always be called first right? You wouldnt specify the $property property if your class has custom implementations would you?

---------------------------------------------------------------------------

by marcw at 2012-02-21T09:05:08Z

@henrikbjorn At this time, the refreshUser method is never called from the custom repository, even if you don't specify the "property" property. This patch fixes this.

---------------------------------------------------------------------------

by marcw at 2012-02-21T09:44:06Z

Updated & Squashed.

---------------------------------------------------------------------------

by stof at 2012-02-21T10:03:33Z

@marcw please move the retrieval of the id in the ``else`` block, like in my comment as it is useless to do this logic for the case where the userProviderInterface is implemented (and it will answer to @vicb by making it impossible to write it with elseif)

---------------------------------------------------------------------------

by marcw at 2012-02-21T10:19:06Z

I'm not sure about this, but Isn't the check of the id essential here to ensure that the entity is a persisted one ?

---------------------------------------------------------------------------

by stof at 2012-02-21T10:21:55Z

@marcw if the interface is used, it means that the user wants to do the work himself. So you should really let him do the way he wants. If he does not use the id to refresh the user, he could choose not to include it in the serialized data.
Retrieving the id is needed for the ``find()`` call because we pass the id as argument and so we fail when the serialized data don't contain it

---------------------------------------------------------------------------

by marcw at 2012-02-21T10:33:30Z

@stof Roger that. I'll do the fix.

---------------------------------------------------------------------------

by marcw at 2012-02-21T10:41:58Z

Updated & Squashed, again.

---------------------------------------------------------------------------

by stof at 2012-02-21T11:00:44Z

btw, to answer to your previous question, the exception when retrieving the id does not check if the object is persisted (you need to reach teh DB for this, which is what find() does) but that the id is part of the serialized data to give a better error reporting.

---------------------------------------------------------------------------

by fabpot at 2012-03-07T19:39:33Z

ready to be merged now?

---------------------------------------------------------------------------

by henrikbjorn at 2012-03-08T07:21:37Z

would say so.

---------------------------------------------------------------------------

by dlsniper at 2012-03-25T11:58:34Z

Hi, can this be merged now or not?
merged branch gatsu/patch-1 (PR #3689)

Commits
-------

b718960 HttpFoundation\HeaderBag Little improvement.

Discussion
----------

[HttpFoundation\HeaderBag] Removed unnecessary anonymous function

---------------------------------------------------------------------------

by vicb at 2012-03-24T16:07:00Z

Related issue: #3294
merged branch cedriclombardot/feat-propel-explain (PR #3616)

Commits
-------

9ef5e95 Add connection name in the propel data collector

Discussion
----------

Add connection name in the propel data collector

Bug fix: no
Feature addition: yes, This will allow to explain a propel query on a specific connection
Backwards compatibility break: no
Symfony2 tests pass: yes

- Require PR propelorm/Propel#315
- Related to PR propelorm/PropelBundle#129

cc @willdurand

---------------------------------------------------------------------------

by willdurand at 2012-03-16T18:17:26Z

@fabpot please, let me merge Propel related PRs before that one, thanks!

---------------------------------------------------------------------------

by willdurand at 2012-03-26T08:38:36Z

@fabpot good to go from my point of view
merged branch drak/session_gc (PR #3659)

Commits
-------

cdba4cf [FrameworkBundle] Change XSD to allow string replacements on session args.
52f7955 [FrameworkBundle] Remove default from gc_* session configuration keys.
749593d [FrameworkBundle] Allow configuration of session garbage collection for session 'keep-alive'.

Discussion
----------

[2.1][FrameworkBundle] Allow configuration of session garbage collection

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2171
Todo: -

---------------------------------------------------------------------------

by drak at 2012-03-21T21:56:20Z

@fabpot - this PR is ready for merge.  It basically allows configuration of some session ini values that are necessary in controlling the session behaviour.

---------------------------------------------------------------------------

by dlsniper at 2012-03-21T22:57:18Z

@drak shouldn't all the options here: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/Session/Storage/NativeSessionStorage.php#L266 be available for configuration, or am I just reading the source wrong and they already are?

In this case should I make a separate PR to cover the rest or could you do it in this one?

---------------------------------------------------------------------------

by fabpot at 2012-03-23T14:56:22Z

@drak: the discussion is the ticket is very interesting and I think it should be part of a cookbook in the documentation. Can you take care of that before I merge this PR? Thanks.

---------------------------------------------------------------------------

by drak at 2012-03-25T15:32:59Z

@fabpot - yes - it's on the todo list.  Will update this PR when done.

---------------------------------------------------------------------------

by drak at 2012-03-26T19:45:13Z

@fabpot - this is ready for merging, the documentation is done (the PR is in but I'll tweak it, but no need to wait to merge this PR).  I will also add something extra to cookbook (I wrote docs for the component).