Skip to content
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

[Form] Fix ChoiceType options #6393

Closed

Conversation

HeahDude
Copy link
Contributor

Q A
Doc fix? yes
New docs? no
Applies to all
Fixed tickets #6144

'choices_as_values' => true,
'data' => true, // pre selected choice
'empty_data' => '1', // default submitted value
));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should we detail that when multiple it should be:

'data' => array(true),
'empty_data' => array('1'),

??

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ref symfony/symfony#18817.

This clearly needs to explained.

Copy link
Member

Choose a reason for hiding this comment

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

Man, this note basically doesn't make any sense to me :). I don't think it's your fault - I just find this choice stuff really hard. What exactly is the problem that we're trying to warn the user about? The only issue I can understand is that empty_data (if you want to set that) would need to equal 1 to simulate true (I think, because apparently these values will render as 0, 1, 2 because they can't be cast into strings?).

I'm normally under the impression that the user will rarely care about the HTML value attribute that is rendered/submitted - as long as if I select "Yes", I end up with true in my code.

@HeahDude HeahDude force-pushed the fix-choice_type-options-allowed_types branch 4 times, most recently from 6da211f to b49bb5a Compare March 26, 2016 01:23
fabpot added a commit to symfony/symfony that referenced this pull request Mar 30, 2016
This PR was merged into the 2.7 branch.

Discussion
----------

[Form] remove useless copy in ChoiceType

| Q             | A
| ------------- | ---
| Branch?       | 2.7+
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | n/a
| License       | MIT
| Doc PR        | symfony/symfony-docs#6393

`ChoiceListFactoryInterface` expected `$groupBy` to be a callable or null, not an array ([ref](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/ChoiceList/Factory/ChoiceListFactoryInterface.php#L111)).

The factory defaults `groupBy` to `ChoiceListInterface::getStructuredValues()` ([ref](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/ChoiceList/Factory/DefaultChoiceListFactory.php#L122)).

Hence, the copy of the choices array and the recursive flip are useless and may be slowing down performances imho (especially with `EntityType`).

Commits
-------

562f5e4 [Form] remove useless code in ChoiceType
symfony-splitter pushed a commit to symfony/form that referenced this pull request Mar 30, 2016
This PR was merged into the 2.7 branch.

Discussion
----------

[Form] remove useless copy in ChoiceType

| Q             | A
| ------------- | ---
| Branch?       | 2.7+
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | n/a
| License       | MIT
| Doc PR        | symfony/symfony-docs#6393

`ChoiceListFactoryInterface` expected `$groupBy` to be a callable or null, not an array ([ref](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/ChoiceList/Factory/ChoiceListFactoryInterface.php#L111)).

The factory defaults `groupBy` to `ChoiceListInterface::getStructuredValues()` ([ref](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Form/ChoiceList/Factory/DefaultChoiceListFactory.php#L122)).

Hence, the copy of the choices array and the recursive flip are useless and may be slowing down performances imho (especially with `EntityType`).

Commits
-------

562f5e4 [Form] remove useless code in ChoiceType
@HeahDude
Copy link
Contributor Author

This one needs reviews :)

@@ -83,40 +94,68 @@ code, while the **key** is what will be shown to the user.
and will be removed in 3.0. To read about the old API, read an older version of
the docs.

.. note::

Pre selected choices will depend on the **data** passed to field and the values of
Copy link
Contributor

@alexislefebvre alexislefebvre May 10, 2016

Choose a reason for hiding this comment

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

@HeahDude Should it be Preselected?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Je ne sais pas :) I would natively say "pré-selectionné" with a dash.

Copy link
Member

Choose a reason for hiding this comment

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

In case of doubt, our official reference is the "American English Oxford Dictionary": preselected is correct.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you very much @javiereguiluz! Reference added in my favorites :)

@HeahDude HeahDude force-pushed the fix-choice_type-options-allowed_types branch from b49bb5a to 5430cec Compare June 25, 2016 17:20
@HeahDude
Copy link
Contributor Author

Comments addressed.

Status: Needs Review

@@ -46,6 +46,8 @@ This will "prefer" the "now" and "tomorrow" choices only:
Finally, if your values are objects, you can also specify a property path string
on the object that will return true or false.

See the `choice_label`_ for details about using a property path or a callable.
Copy link
Member

Choose a reason for hiding this comment

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

This reference doesn't work.


Also, the :class:``Symfony\\Component\\Form\\ChoiceList\\Factory\\ChoiceListFactoryInterface`` will cache the choice list
so the same :class:``Symfony\\Component\\Form\\ChoiceList\\Loader\\ChoiceLoaderInterface`` can be used in different fields with more performance
(reducing N queries to 1).
Copy link
Member

Choose a reason for hiding this comment

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

minor: a few of these lines got real long :)

@HeahDude
Copy link
Contributor Author

@weaverryan thanks for the review!

Status: Needs Work

Pre selected choices will depend on the **data** passed to the field and
the values of the ``choices`` option. However submitted choices will depend
on the **string** matching the **choice**. In the example above, the default
values are incrementing integers because ``null`` cannot be casted to string.
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

@yceruto yceruto Jan 4, 2017

Choose a reason for hiding this comment

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

In fact, I think it's a bug ;) we can show "", "1", "0" values for array(null, true, false) choices and be more consistent.

Trying to fix that in symfony/symfony#21160

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As said in your PR you should close it, this is why this needs a better doc :)

'No' => false,
),
'choices_as_values' => true,
'data' => true, // pre selected choice
Copy link
Member

Choose a reason for hiding this comment

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

This should be a bad practice. The reader could interpret that is a way to set default value and it isn't. As you know, if an object is bound to the form, the data option overrides this default value.

I suggest you to use $this->createFormBuilder(array('isAttending' => true)) from a controller for this sample. WDYT?

Copy link
Contributor Author

@HeahDude HeahDude Jan 4, 2017

Choose a reason for hiding this comment

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

@yceruto I understand your comment but this is not about a bad practice here, it's about making a clear difference as I'm not sure #6265 is enough though.

@weaverryan
Copy link
Member

Ping @HeahDude! Could you go through my review and finish this? Thx!

codedmonkey added a commit to codedmonkey/symfony-docs that referenced this pull request Feb 22, 2018
@javiereguiluz javiereguiluz modified the milestones: 2.7, 2.8 May 28, 2018
@xabbuh xabbuh modified the milestones: 2.8, 3.4 Nov 28, 2018
fabpot added a commit to symfony/symfony that referenced this pull request Mar 17, 2019
This PR was merged into the 3.4 branch.

Discussion
----------

[Form] Fixed some phpdocs

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | ~
| License       | MIT
| Doc PR        | symfony/symfony-docs#6393

ref symfony/symfony-docs#6144, symfony/symfony-docs#6297, #14050

Commits
-------

b9162e8 [Form] Fixed some phpdocs
@javiereguiluz
Copy link
Member

It's sad but this pull request is no longer mergeable. Things have changed too much and there are too many conflicts. We can open a new pull request in the future and get some inspiration from this one. I'm sorry for having let this pull request stale and thanks anyway for the contribution.

OskarStark added a commit that referenced this pull request Feb 18, 2020
This PR was squashed before being merged into the 3.4 branch.

Discussion
----------

[Form] minor fixes in ChoiceType options

Revival of #6393

Commits
-------

4ee4102 [Form] minor fixes in ChoiceType options
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