10000 [Form] Introduced proxy methods to allow easier handling of form errors by zebba · Pull Request #29521 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[Form] Introduced proxy methods to allow easier handling of form errors #29521

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
wants to merge 7 commits into from

Conversation

zebba
Copy link
@zebba zebba commented Dec 8, 2018
Q A
Branch? master
Bug fix? no
New feature? yes
BC breaks? yes
Deprecations? no - but the option is there
Tests pass? yes
Fixed tickets #25738
License MIT
Doc PR symfony/symfony-docs#... in progress

In order to create a better experience for new developers the introduction of two proxy methods seem to be a good idea when handling with forms. As stated in the issue it isn't always obvious as to why $form->isValid() will return false and $form->getErrors() will leave you with nothing since you didn't think about the parameters to control the list of errors.
Now, I've added two methods: getAllErrors() which is a shortcut for $form->getErrors(true) and getOnlyGlobalErrors() an alias for the $form->getErrors() call.

#symfonyconhackday2018

@xabbuh xabbuh added this to the next milestone Dec 8, 2018
* instances that where added to the top
* level of this form
*/
public function getOnlyGlobalErrors();
Copy link
Contributor

Choose a reason for hiding this comment

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

The name sounds confusing for a form which is not the root.

Copy link
Author

Choose a reason for hiding this comment

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

I was trying to stick with the naming in the current documentation:

// a FormErrorIterator instance, but only errors attached to this
// form level (e.g. global errors)

But getRootErrors() works for me too if this is a naming we can agree on? The suggested getOwnErrors() didn't appeal to me.

* instances that where added to the form
* and the child forms
*/
public function getAllErrors();
Copy link
Contributor

Choose a reason for hiding this comment

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

We cannot change the interface until Symfony 5.0 for BC.

Copy link
Author

Choose a reason for hiding this comment

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

I actually totally forgot about that part and agree. I've changed the description.

@xabbuh
Copy link
Member
xabbuh commented Dec 8, 2018

#SymfonyConHackDay2018

@vudaltsov
Copy link
Contributor

I have a different proposal for naming:

  1. Leave getErrors() as is, but deprecate passing arguments to it;
  2. Add getAllErrors(bool $flatten = true): FormErrorIterator for receiving errors deeply.

I think that when you see getErrors() and getAllErrors() in autocomplete, you get an idea of what you really need.

@vudaltsov
Copy link
Contributor
vudaltsov commented Dec 12, 2018

Another idea I like is @noahduncan 's proposal to add Iterator suffix.
What if we deprecate getErrors($deep = false, $flatten = true) in favor of createErrorsIterator(bool $deep = true, bool $flatten = true): FormErrorIterator?

The word create will urge to be more attentive to method's arguments. And by setting $deep to true by default we will solve the issue.

@vudaltsov vudaltsov mentioned this pull request Dec 14, 2018
Buttons don't have child forms
@fabpot
Copy link
Member
fabpot commented Mar 31, 2019

I can see that this PR was started during SymfonyLive Hackaton. @zebba Are you still interested in working on it?

@zebba
Copy link
Author
zebba commented Apr 21, 2019

I can see that this PR was started during SymfonyLive Hackaton. @zebba Are you still interested in working on it?

Yes, I am up for it.

@fabpot
Copy link
Member
fabpot commented Feb 4, 2020

Closing as this PR has been stale for a long time. Feel free to reopen whenever you find time to finish it.

@fabpot fabpot closed this Feb 4, 2020
@nicolas-grekas nicolas-grekas modified the milestones: next, 5.1 May 4, 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
0