You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
array(1) {
["each"]=>
string(29) "street must be of type string"
}
However, I would have expected
array(1) {
["each"]=>
array(3) {
[0]=>
array(2) {
['street']=>
string(22) "street must be present"
['other'] =>
string(28) "other must be of type string"
}
[1]=>
array(1) {
['street']=>
string(24) "street must not be empty"
}
[2]=>
array(1) {
['street']=>
string(29) "street must be of type string"
}
}
}
It is a little alarming that no exception is present for the first erroneous 'other' field.
Is there a different rule for this?
The text was updated successfully, but these errors were encountered:
Unfortunatelly, this and other composite messages are completely broken in 2.x, and there isn't much we can do without further changing the core NestedValidationException.
However, for each specifically, this is a deal braker since it makes it unusable, so I made a hotfix and it should be available on 2.3.
Check out this test to see how the behavior changed.
For 3.0, most messages for composite validators should be reporting using a . notation or some other tree expression equivalent. I haven't settled on it yet, but every message should be available somewhere. It might be a getAllMessages or something, but it will be there.
When you validate the elements of an array (or iterable) using each, the messages get "overwritten" when you get the exception message.
The above var_dump results in
However, I would have expected
It is a little alarming that no exception is present for the first erroneous 'other' field.
Is there a different rule for this?
The text was updated successfully, but these errors were encountered: