Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Form] Fixed empty data on expanded ChoiceType and FileType#25948

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@HeahDude
Copy link
Contributor

QA
Branch?2.7
Bug fix?yes
New feature?no
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets#25896
LicenseMIT
Doc PR~

Alternative of#25924.

I don't think we have to do this by adding overhead in master and getting it properly fixed in 2 years.

This is bug I've introduced while fixing another bug#17822. Which then has been replicated in#20418 and#24993.

I propose instead to clean up the code for all LTS, since this is a wrong behaviour that has never been documented, and most of all unreliable.
Theempty_data can by anything in the view format as long as the reverse view transformation supports it. Even an object derived from the data class could be invokable.

I think we should remain consistent withhttps://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/Form.php#L615.

@HeahDudeHeahDude changed the title[Form] Fixed empty data on expanded ChoiceType[Form] Fixed empty data on expanded ChoiceType and FileTypeJan 28, 2018
@HeahDudeHeahDudeforce-pushed thefix/choice_type-empty_data_closure branch fromc136751 to7327a9fCompareJanuary 28, 2018 11:58
@HeahDudeHeahDudeforce-pushed thefix/choice_type-empty_data_closure branch from7327a9f to9722c06CompareJanuary 28, 2018 11:59
@nicolas-grekasnicolas-grekas added this to the2.7 milestoneJan 31, 2018
if (false === FormUtil::isEmpty($emptyData) &&array() !==$emptyData) {
$data =is_callable($emptyData) ?call_user_func($emptyData,$form,$data) :$emptyData;
}
$data =$emptyDatainstanceof \Closure ?$emptyData($form,$data) :$emptyData;

Choose a reason for hiding this comment

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

isinstanceof \Closure legit instead ofis_callable (same below?)

Copy link
ContributorAuthor

@HeahDudeHeahDudeJan 31, 2018
edited
Loading

Choose a reason for hiding this comment

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

This is totally legit and what must be, this is the point of this bug fix. Only a\Closure should be considered here, nothing else.

The view data can be:

  • an object (whose class must be the same as defined by thedata_class option)
  • an array
  • a scalar

The three of them can be callable:

  • the object can be invokable
  • the array can be a class or an object with a method name
  • the string a function name (which triggered the related issue)

Deprecating a broken behavior on master does not make any sense to me,
I really think we need to merge this PR as a bug fix, because theprevious one was wrong.

@nicolas-grekas
Copy link
Member

@HeahDude can you please have a look at#25925? It changes the same lines.

@HeahDude
Copy link
ContributorAuthor

@nicolas-grekas yes thanks, I already did.#25925 is a duplicate of#25924 where I left a comment.

if (false === FormUtil::isEmpty($emptyData) &&array() !==$emptyData) {
$data =is_callable($emptyData) ?call_user_func($emptyData,$form,$data) :$emptyData;
}
$data =$emptyDatainstanceof \Closure ?$emptyData($form,$data) :$emptyData;
Copy link
ContributorAuthor

@HeahDudeHeahDudeJan 31, 2018
edited
Loading

Choose a reason for hiding this comment

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

This is totally legit and what must be, this is the point of this bug fix. Only a\Closure should be considered here, nothing else.

The view data can be:

  • an object (whose class must be the same as defined by thedata_class option)
  • an array
  • a scalar

The three of them can be callable:

  • the object can be invokable
  • the array can be a class or an object with a method name
  • the string a function name (which triggered the related issue)

Deprecating a broken behavior on master does not make any sense to me,
I really think we need to merge this PR as a bug fix, because theprevious one was wrong.

$emptyData =$form->getConfig()->getEmptyData();

$data =is_callable($emptyData) ?call_user_func($emptyData,$form,$data) :$emptyData;
$data =$emptyDatainstanceof \Closure ?$emptyData($form,$data) :$emptyData;
Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Note that thisbug fix was wrong as well by replicating the first.


$data =is_callable($emptyData) ?call_user_func($emptyData,$form,$data) :$emptyData;
$event->setData($data);
$event->setData(null);
Copy link
ContributorAuthor

@HeahDudeHeahDudeJan 31, 2018
edited
Loading

Choose a reason for hiding this comment

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

And that this is a BC break introduced in#24993 which does not count as the one which adds a method to theRequestHandlerInterface introduced in that same PR, considering theintended behavior.

@fabpot
Copy link
Member

Thank you@HeahDude.

@fabpotfabpot merged commit9722c06 intosymfony:2.7Feb 1, 2018
fabpot added a commit that referenced this pull requestFeb 1, 2018
…e (HeahDude)This PR was merged into the 2.7 branch.Discussion----------[Form] Fixed empty data on expanded ChoiceType and FileType| Q             | A| ------------- | ---| Branch?       | 2.7| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#25896| License       | MIT| Doc PR        | ~Alternative of#25924.I don't think we have to do this by adding overhead in master and getting it properly fixed in 2 years.This is bug I've introduced while fixing another bug#17822. Which then has been replicated in#20418 and#24993.I propose instead to clean up the code for all LTS, since this is a wrong behaviour that has never been documented, and most of all unreliable.The `empty_data` can by anything in the view format as long as the reverse view transformation supports it. Even an object derived from the data class could be invokable.I think we should remain consistent withhttps://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/Form.php#L615.Commits-------9722c06 [Form] Fixed empty data on expanded ChoiceType and FileType
@HeahDudeHeahDude deleted the fix/choice_type-empty_data_closure branchFebruary 1, 2018 07:37
@peter-gribanov
Copy link
Contributor

peter-gribanov commentedFeb 1, 2018
edited
Loading

I'm in shock 😳
First youtell me that this change breaks BC, and then you break it yourself.
I made asimilar change, but it's safer and you rejected it.

@HeahDude
Copy link
ContributorAuthor

@peter-gribanov Sorry for the confusion, and thank you very much for reporting the issue and trying to fix it.
The fact is that this PR fixes bugs and a BC break introduced in 2.7 before. It is not safer to keep all our LTS versions broken with an unintended behavior. Deprecating it in master is not the right fix, it would correct it in 2 years from now.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@fabpotfabpotfabpot approved these changes

@nicolas-grekasnicolas-grekasnicolas-grekas approved these changes

Assignees

No one assigned

Projects

None yet

Milestone

2.7

Development

Successfully merging this pull request may close these issues.

5 participants

@HeahDude@nicolas-grekas@fabpot@peter-gribanov@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp