Skip to content

[Serializer] Normalize constraint violation parameters #29130

New issue

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

Merged
merged 1 commit into from
Mar 17, 2019
Merged

[Serializer] Normalize constraint violation parameters #29130

merged 1 commit into from
Mar 17, 2019

Conversation

ogizanagi
Copy link
Contributor

@ogizanagi ogizanagi commented Nov 7, 2018

Q A
Branch? master
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? yes
Tests pass? yes
Fixed tickets N/A
License MIT
Doc PR N/A?

Adding violation constraints' parameters to the normalized data, as these are valuable for an API client.

I used parameters for now, as it's the name used in ConstraintViolationInterface::getParameters(), but what about placeholders or context?

@nicolas-grekas nicolas-grekas added this to the next milestone Nov 8, 2018
@ogizanagi
Copy link
Contributor Author

Note: adding this by default might break CI testing API endpoint responses, but I don't see much more reasons not to do so. So, better keep adding by default, or add a context option for this?

@xabbuh
Copy link
Member

xabbuh commented Nov 8, 2018

it may be better to make this behaviour opt-in

@dunglas
Copy link
Member

dunglas commented Nov 8, 2018

We don't guarantee that the output of the normalizers will never change. Especially, we don't guarantee that will not add fields. I'm in favor of adding it by default, but only if at least one parameter exists.

@@ -49,6 +49,7 @@ public function normalize($object, $format = null, array $context = array())
$violationEntry = array(
'propertyPath' => $propertyPath,
'title' => $violation->getMessage(),
'parameters' => $violation->getParameters(),
Copy link
Member

@dunglas dunglas Nov 8, 2018

Choose a reason for hiding this comment

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

We should only add this key if at least one parameter exists:

if ($parameters = $violation->getParameters()) {
    $violationEntry['parameters'] = $parameters;
}

Copy link
Contributor Author

@ogizanagi ogizanagi Nov 9, 2018

Choose a reason for hiding this comment

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

May I ask what is the motivation behind this?
From my experience, this would just introduce additional complexity/confusion on the client side in the way would be consumed the data structure, only to save a few bytes.

Copy link
Member

@dunglas dunglas left a comment

Choose a reason for hiding this comment

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

Let's merge it as is. Can you rebase please?

@ogizanagi
Copy link
Contributor Author

Now rebased :)

@lyrixx
Copy link
Member

lyrixx commented Mar 16, 2019

this one is OK too. let's merge it. /cc @dunglas (easy pick)

@fabpot
Copy link
Member

fabpot commented Mar 17, 2019

Thank you @ogizanagi.

@fabpot fabpot merged commit 32c90eb into symfony:master Mar 17, 2019
fabpot added a commit that referenced this pull request Mar 17, 2019
… (ogizanagi)

This PR was merged into the 4.3-dev branch.

Discussion
----------

[Serializer] Normalize constraint violation parameters

| Q             | A
| ------------- | ---
| Branch?       | master <!-- see below -->
| Bug fix?      | no
| New feature?  | yes <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | yes <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A   <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | N/A?

Adding violation constraints' parameters to the normalized data, as these are valuable for an API client.

I used `parameters` for now, as it's the name used in `ConstraintViolationInterface::getParameters()`, but what about `placeholders` or `context`?

Commits
-------

32c90eb [Serializer] Normalize constraint violation parameters
@ogizanagi ogizanagi deleted the constraint_violation_normalizer_parameters branch March 17, 2019 21:19
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.3 Apr 30, 2019
@fabpot fabpot mentioned this pull request May 9, 2019
fabpot added a commit that referenced this pull request Jun 4, 2019
…eters (ogizanagi)

This PR was merged into the 4.4 branch.

Discussion
----------

[Validator] Add compared value path to violation parameters

| Q             | A
| ------------- | ---
| Branch?       | 4.4 <!-- see below -->
| Bug fix?      | no
| New feature?  | yes <!-- please update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A   <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | N/A

While it's not really useful to use as a placeholder in the violation message template (compared to hard-coding it into the message. Nor it is really user-friendly),
it becomes handy in conjunction with #29130 for any mapping logic on client-side.

Commits
-------

2da226a [Validator] Add compared value path to violation parameters
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.

8 participants