Skip to content

[Form] FormErrorIterator do not filter only with Constraint causes #28649

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

Closed

Conversation

gmponos
Copy link
Contributor

@gmponos gmponos commented Sep 30, 2018

Q A
Branch? master for features
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
License MIT
Doc PR symfony/symfony-docs

I made this PR based on this

In general I believe that the FormError object should be strict on the type of the Cause. It should either be a ConstraintViolation object an object that implements toString function or a simple string and this should be checked during the construction of the FormError. For me it's too vague what a cause argument is and what findByCodes does.. Althought this PR does not check anything on the construction of the FormError object this can be the first step.

I will add tests later if you agree with this PR. Let me know. 😄

@ro0NL
Copy link
Contributor

ro0NL commented Sep 30, 2018

i dont think FormError object should be strict on the type of the Cause.. but this change seems reasonable yes 👍

}

$cause = (string)$cause;
if(\in_array($cause, $codes, true)){
Copy link
Member

Choose a reason for hiding this comment

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

don't miss fabbot patch around this line

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done :)

@nicolas-grekas nicolas-grekas added this to the 4.2 milestone Oct 1, 2018
@gmponos
Copy link
Contributor Author

gmponos commented Oct 2, 2018

Do you guys believe that this change is a BC?

An edge case:
Someone was passing as a cause an object and he was filtering using findByCodes(). Object did have a __toString function. Before he would get 2 FormErrors that all contained ConstraintViolations now he gets 3 FormErrors and some contain various causes.

@gmponos gmponos force-pushed the filter_validation_errors_on_form branch from 3ac3ab1 to 545dc12 Compare October 2, 2018 18:02
@nicolas-grekas
Copy link
Member

(rebase needed)
@xabbuh @HeahDude maybe you'd like to review this PR?

@nicolas-grekas nicolas-grekas modified the milestones: 4.2, next Oct 20, 2018
… is string or object that has a __toString method
@gmponos gmponos force-pushed the filter_validation_errors_on_form branch from 545dc12 to e5275c6 Compare October 20, 2018 20:21
@xabbuh
Copy link
Member

xabbuh commented Oct 21, 2018

I think a better solution would be to introduce the concept of error codes in the FormError class too and filter based on that code instead.

@xabbuh
Copy link
Member

xabbuh commented Oct 21, 2018

We could also think about having a filter() method that accepts a callback to filter the list of errors.

@gmponos
Copy link
Contributor Author

gmponos commented Oct 21, 2018

We could also think about having a filter() method that accepts a callback to filter the list of errors.

I do like this idea even better.

I think a better solution would be to introduce the concept of error codes in the FormError class too and filter based on that code instead.

Can you elaborate a little bit here? Do you mean that FormError can have a Cause and a Code also?

@ro0NL
Copy link
Contributor

ro0NL commented Oct 21, 2018

We could also think about having a filter()

also see #19496 (comment). Im curious about the proposed API, as we avoid the callback to have convenient API today. This PR just provides more meaning to "code" in the form component (e.g. if the cause is scalar-ish; it's a code). That's valid to me.

It's effectively the same as

I think a better solution would be to introduce the concept of error codes in the FormError class too and filter based on that code instead.

Other filters fit foreach IMHO.

*/
public function testFindByCodesWhenAllCausesAreVariousObjectsOrSimpleStrings($code, $violationsCount)
{
if (!class_exists(ConstraintViolation::class)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

we should not require validator component to test the new feature (we aim for compatibility without it)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

FYI this test class on master contains one test case. I have duplicated this test case on the current PR. These lines are the copied code from the previous test case.

Your proposal is to remove them from both test cases?

Copy link
Contributor

Choose a reason for hiding this comment

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

FYI this test class on master contains one test case

then i suggest to refactor it a bit, and keep a single testFindByCodes() where the expectations are built dynamically (if validator exists yes/no)

}

$cause = (string) $cause;
if (\in_array($cause, $codes, true)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

id say in_array((string) $cause, ..

@fabpot
Copy link
Member

fabpot commented Jul 8, 2019

What's the status of this pull request? /cc @xabbuh

Copy link
Contributor

@HeahDude HeahDude left a comment

Choose a reason for hiding this comment

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

LGTM

@gmponos
Copy link
Contributor Author

gmponos commented Nov 23, 2019

I dont have the time to work on this.. whoever wants can take it...

@fabpot
Copy link
Member

fabpot commented Aug 11, 2020

Closing as nobody stepped up to finish this PR.

@fabpot fabpot closed this Aug 11, 2020
@nicolas-grekas nicolas-grekas modified the milestones: next, 5.2 Oct 5, 2020
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.

7 participants