8000 [Validator] Target aware class constraints by lemoinem · Pull Request #16978 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[Validator] Target aware class constraints #16978

New issue 8000

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

lemoinem
Copy link
Contributor
Q A
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets N/A
License MIT
Doc PR symfony/symfony-docs#6002

This PR is the first part of #16969

It basically creates a new TargetAwareConstraintInterface and a trait for its implementation.

The idea is that a constraint implementing this interface would need to be aware of its target (it makes sense only for Class Constraints). For class constraints, the target is the class the constraint was declared on.

It provides also support for YamlFileLoader, XmlFileLoader and AnnotationLoader (only for Class Constraints) with appropriate tests.

AppVeyor failing tests are related to the HttpFoundation Component.
HHVM failing tests are related to the Process Component.
In both case, it's unrelated to this PR.

*/
public function getTargets()
{
return Constraint::CLASS_CONSTRAINT;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just wondering: Why don't you think it could be useful for property constraints ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see target awareness like a scope widening feature.

So called class constraints are lexically applied to the class but usually have the validated instance as their scope (i.e. The constraint is checking that the current instance respects such and such invariant). A TA class constraint is using the class as its scope (i.e. The constraint is checking that the current instance does not break such and such invariant among all the other instances of the class).

Following the same reasoning, property constraints have the validated property as their scope (i.e. The constraint is checking that the current property respects such and such invariant). Widening the scope of such constraint to the current instance is already possible using a class constraint (with a custom path).

@lemoinem lemoinem force-pushed the features/class-constraint-target branch from f7ba807 to d63d8d5 Compare December 12, 2015 00:24
@lemoinem
Copy link
Contributor Author

As @ogizanagi mentionned in #16981 (comment)

StaticMethodLoader could be modified as to support TA constraints seamlessly too. However the current behavior of StaticMethodLoader is to do the bare minimum and to let the implementation of the loader method do all the heavy lifting work.

I didn't see fit to alter the semantic of this loader. If you think it would be a better way to do it. I will do so with the appropriate tests. That would mean the deprecation of the next PR would be limited to custom constraint loaders.

@lemoinem lemoinem force-pushed the features/class-constraint-target branch from d63d8d5 to 697833b Compare February 2, 2016 21:55
@lemoinem
Copy link
Contributor Author
lemoinem commented Feb 2, 2016

I rebased both PR. The PHP 5.6 Travis build fails because of failling tests in Framework, as far as I can tell it's unrelated to this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
0