Hey guys, if you see my issue#11413 I was thinking that I could use this ExecutionContextInterface::setNode method in order to set the correct property_path for my constraint, but I didn't know what to specify for the $metadata argument. If this PR gets merged, would this be a valid workaround?

@redstar504 See my answer to your ticket. UsingsetNode() directly is never recommended because it is marked as internal and may be changed anytime (breaking your code).

We're still having issues if we use the 2.4 validation API. Errors are being set on the form rather than fields. Works fine with 2.5-bc and 2.5.

@tompedals Could you provide a fork of symfony-standard which reproduces your issue?

@webmozart I'll give it a try. It may well have just been cached. The main issue I was having is now resolved anyway as we can use the 2.5 API rather than 2.4. Thanks for looking into it.

Btw, there is another Interface problem.ExecutionContext::markObjectAsInitialized is not part of the interface, but it is called on the interface byhttps://github.com/webmozart/symfony/blob/issue11046/src/Symfony/Component/Validator/Validator/RecursiveContextualValidator.php#L845

AndValidatorInterface::startContext() does not have a parameter, but the implementationRecursiveValidator::startContext($root = null) has.

This one is quite critical as without the fix, people cannot upgrade from 2.4 to 2.5 (2.4 being obsolete now.)

@webmozart@Tobion Can you find time to finish this one so that we can merge it soon?

Looks good 👍 except the phpdoc I mentioned above. The other problems I figured out are unrelated and can be separate tickets.

@Tobion Thanks, I addressed your comments now.startContext($root = null) shouldn't be a problem, as the parameter is only used internally in RecursiveValidator invalidate() andvalidateProperty(). We could of course introduce a separate, private method, but I'd rather not introduce another method call just for cosmetic purposes.

If I get another go, I can merge the PR. /cc@stof

But startContext is a public method. So nothing hinders developers to actually use the parameter. So it's not only cosmetic. And changing the behavior of the parameter at some point could be considered BC break even though it's only intended for internal purposes.

Sure, developers can use the parameter, but then their code is bound to the implementation, not the interface - which is their choice. If we want to change anything about that parameter, we need to do so in a BC fashion, but I don't think this is very likely.

I dislike this because it does not respect the interface and is only possible in loosly checked languages like PHP. In stricter languages like Java this is not possible. To me this is a hack without any usefulness. And static code analysis will probably not like this either. I'm +0

I think the solution is pragmatic. But if others agree with you, I'm not opposed to adding another private method either.

Another reason against it is that the parameter is not documented. And documentation is not only for users but also for understanding code, i.e. contributors.

Feel free to open a PR to the branch. :)

👍

I still see errors attached to a wrong filed with dev-master #7af2563 that errors are attached to the wrong field with 2.5 and 2.5-bc api. 2.4 api works fine.

@webmozart Are you aware of further issues regarding this or shall I try to reproduce it in a SE?

@peterrehm 2.5 hasn't been merged into master since then.

@xabbuh Good catch, my bad. Just checked it against 2.5.x-master and could not reproduce my test cases. Seems to be fixed. Thanks!

@peterrehm I've just merged 2.5 into master.

@fabpot Thanks.