For information, Scrutinizer errors are not due to my commits.

I can't see what is wrong with Travis check on PHP 5.4. Is it possible to have the detail of the failure?

When I click here: https://travis-ci.org/symfony/symfony/jobs/5879397, I simply have an endless "loading" message.

the travis interface seems broken currently (I see a JS error in the console). You should report it in their issue tracker. And waiting for a fix, you could try to get the logs through their CLI or their API.

@stof Thanks. In fact I get an error with Firefox 19.0.2 but not in Chrome. I opened a ticket on travis-web tracker: https://github.com/travis-ci/travis-web/issues/171

The failure concern this test, but I didn't touch it.
There was 1 failure:

1. Symfony\Component\Process\Tests\SigchildDisabledProcessTest::testRestart
   Failed asserting that true is false.

@bschussek What do you think about this addition?

The current implementation here is a bit flawed. It combines both local errors (indexed by integers) and nested errors (indexed by field names, which can be integers too) in one single data structure, which cannot work.

I think this functionality should be merged into getErrors() by introducing a new parameter $deep that is false by default. getErrors() should then return some sort of array-compatible (for BC) object (FormErrorList, FormErrorIterator, not sure yet) that supports recursive iteration (\RecursiveIterator). Also, this object should implement __toString(), which should return the same output as getErrorsAsString() (which then could be deprecated).

I can't really give any advice yet on further details. This needs to be thought through and it is definitely not trivial.

If I can give my opinion on the expected format, this should look like
$errors[field_name] = ['label' => 'field_label', 'errors' => ['error_msg_1', 'error_msg_2'] ];

@bschussek That seems like a nice idea to me. However, it seems to me FormError class currently does not contain any information about the form field name the error is related to. So some additional data about the field name/key should be added to FormError too, I think.

About the array compatibility, would implementing ArrayAccess interface do the trick?

@TomiS FormError instances are attached to a Form instance. So getting the field name is possible as you need to Form to get the errors.

Ok, I spent yesterday playing with this thing and first tried to implement something similar to what @bschussek had in mind. Here's a diff of what I ended up with. There are a couple of problems with this approach, though. 1) The code becomes quite complex if we really want array compatibility and if it should be fully array serializable (to get json too). 2) I ended up repeating the tree structure already introduced by Form class and I feel this adds unnecessary complexity too. 3) Getting a nice looking json output out of the very complex class structure is tedious (at least before PHP 5.4 and its JsonSerializable inteface)

So... I also ended up trying something much more simple. Basically what I did was repeating the same implementation introduced in this PR but just in the getErrors() method. You can see that implementation in here. I tried to serialize the output of this with JMSSerializer to json and the result was "just what the api developer needs", imo :) The benefit of this approach is that it's very simple as it utilizes the tree structure provided by Form class itself. What comes to indexes of local and nested errors, I really can't see the problem. Is there really a risk for index collision because I truly can't see it. (but on the other hand, I didn't write the component like some of us, so what do I know ;)

ps. Good point @stof. And it's also kind of related to what I say here about duplicating tree structure.

replaced by #9099