8000 [Form] Add option widget to ChoiceType by bamarni · Pull Request #17646 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[Form] Add option widget to ChoiceType #17646

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.

Sign up for GitHub

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 4 commits into from
Closed

[Form] Add option widget to ChoiceType #17646

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
3d61584
[Form] Add option widget to ChoiceType
bamarni Jun 21, 2015
ced878a
fix twig bridge tests - use strict comparison
bamarni Feb 2, 2016
1491bb7
add legacy tag to EntityTypeTest - edit upgrade/changelog
bamarni Feb 2, 2016
2a972f3
update tests
bamarni Feb 3, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
fix twig bridge tests - use strict comparison
  • Loading branch information
@bamarni
bamarni committed Feb 4, 2016
commit ced878aaebc5fd7e8f58174e09d410762d3c2dc6
4 changes: 2 additions & 2 deletions src/Symfony/Bridge/Twig/Resources/views/Form/form_div_layout.html.twig
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,9 +35,9 @@
{%- endblock textarea_widget -%}

{%- block choice_widget -%}
{% if 'hidden' == widget %}
{% if widget is defined and 'hidden' == widget %}
{{- block('hidden_widget') -}}
{% elseif 'text' == widget %}
{% elseif widget is defined and 'text' == widget %}
{{- block('form_widget_simple') -}}
Copy link
Contributor

Choose a reason for hiding this comment

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

hidden_widget and form_widget_simple never get a 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.

see https://github.com/symfony/form/blob/master/Extension/Core/Type/FormType.php#L89

{% elseif expanded %}
{{- block('choice_widget_expanded') -}}
Expand Down
15 changes: 8 additions & 7 deletions src/Symfony/Component/Form/Extension/Core/Type/ChoiceType.php
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,7 @@ public function buildForm(FormBuilderInterface $builder, array $options)
$choiceList = $this->createChoiceList($options);
$builder->setAttribute('choice_list', $choiceList);

if ($options['expanded'] && !in_array($options['widget'], array('text', 'hidden'))) {
if ($options['expanded'] && !in_array($options['widget'], array('text', 'hidden'), true)) {
$builder->setDataMapper($options['multiple']
Copy link
Contributor

Choose a reason for hiding this comment

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

Could be if ('expanded' === $options['widget'])

What is the point of having checkbox and radio value for widget option if you still have to deal with multiple option ?

widget might have few options like text, hidden, select and expanded

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For checkbox and radio, multiple option is ignored, I had made the same suggestion (see linked PR description) and @webmozart preferred to have more explicit names.

Sorry, something went wrong.

? new CheckboxListMapper($choiceList)
: new RadioListMapper($choiceList));
Expand Down Expand Up @@ -151,7 +151,7 @@ public function buildForm(FormBuilderInterface $builder, array $options)
$builder->addViewTransformer(new ChoicesToValuesTransformer($choiceList));

// for "text" / "hidden" widget, view data uses a delimiter
if (in_array($options['widget'], array('text', 'hidden'))) {
if (in_array($options['widget'], array('text', 'hidden'), true)) {
$builder->addViewTransformer(new ValuesToStringTransformer($options['delimiter'], $options['trim']));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This implementation is wrong IMO since transformers may be executed in the right order for transformation but not for reversing transformation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

not sure I get what you mean, Symfony will chain them in the correct order automatically depending on the direction (view to norm or norm to view).

} else {
Expand Down Expand Up @@ -195,7 +195,7 @@ public function buildView(FormView $view, FormInterface $form, array $options)
'choice_translation_domain' => $choiceTranslationDomain,
));

if (in_array($options['widget'], array('text', 'hidden'))) {
if (in_array($options['widget'], array('text', 'hidden'), true)) {
return;
}

Expand Down Expand Up @@ -237,7 +237,7 @@ public function buildView(FormView $view, FormInterface $form, array $options)
*/
public function finishView(FormView $view, FormInterface $form, array $options)
{
if (in_array($options['widget'], array('text', 'hidden'))) {
if (in_array($options['widget'], array('text', 'hidden'), true)) {
return;
}

Expand Down Expand Up @@ -318,8 +318,8 @@ public function configureOptions(OptionsResolver $resolver)
};

$multipleNormalizer = function (Options $options, $multiple) {
if (in_array($options['widget'], array('radio', 'checkbox'))) {
return 'checkbox' == $options['widget'];
if (in_array($options['widget'], array('radio', 'checkbox'), true)) {
return 'checkbox' === $options['widget'];
}

return $multiple;
Expand All @@ -332,7 +332,7 @@ public function configureOptions(OptionsResolver $resolver)
$expanded = false;
Copy link
Contributor

Choose a reason for hiding this comment

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

This line is not need if you cast return to bool :

return (bool) (in_array($options['widget'], array('radio', 'checkbox'), true) ?: $expanded);

anyway the cast would be done anywhere in this class as it's only a test variable. Then it has to remain internal and not to be removed in 4.0 with the actual implementation IMO.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What is so wrong about this normalizer for you to comment on it since days? :D
Handling everything in one line makes it less readable imo.

}

return in_array($options['widget'], array('radio', 'checkbox')) ?: $expanded;
return in_array($options['widget'], array('radio', 'checkbox'), true) ?: $expanded;
};

Copy link
Contributor

Choose a reason for hiding this comment

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

You could have only one normalizer :

$expandedNormalizer = function (Options $options, $expanded) {
    // trigger error
    return 'expanded' === $options['widget'];
}

Anyway it should be :

$expandedNomalizer = function (Options $options, $expanded) {
    if (null !== $expanded) {
        @trigger_error('The "expanded" option is deprecated since version 3.1 for internal use only. You should use "widget" option with "radio" or "checkbox" instead.', E_USER_DEPRECATED);
     }

    return in_array($options['widget'], array('radio', 'checkbox'));
};

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 discussed previously, the expanded option from your first snippet hasn't been accepted, and the second snippet doesn't support $expanded set to true

Copy link
Contributor

Choose a reason for hiding this comment

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

There is no need to handle expanded value when it is deprecated by this PR... this is actually the meaning of this normalizer.

you could write :

$expandedNomalizer = function (Options $options, $expanded) {
    if (null !== $expanded) {
        @trigger_error('The "expanded" option is deprecated since version 3.1 for internal use only. You should use "widget" option with "radio" or "checkbox" instead.', E_USER_DEPRECATED);
     }

    return 'select' === $options['widget'] ? false : (in_array($options['widget'], array('radio', 'checkbox')) ?: $expanded);
};

only if text and hidden were indeed been handled differently when expanded is true and if it was not deprecated. Or neither options seems to be implemented properly in this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is no need to handle expanded value when it is deprecated by this PR... this is actually the meaning of this normalizer.

The goal of this normalizer is to handle expanded value (to provide BC) while overriding it if needed (when widget is defined).

$resolver->setDefaults(array(
Expand Down Expand Up @@ -376,6 +376,7 @@ public function configureOptions(OptionsResolver $resolver)
$resolver->setAllowedTypes('choice_attr', array('null', 'array', 'callable', 'string', 'Symfony\Component\PropertyAccess\PropertyPath'));
$resolver->setAllowedTypes('preferred_choices', array('array', '\Traversable', 'callable', 'string', 'Symfony\Component\PropertyAccess\PropertyPath'));
$resolver->setAllowedTypes('group_by', array('null', 'array', '\Traversable', 'callable', 'string', 'Symfony\Component\PropertyAccess\PropertyPath'));
$resolver->setAllowedValues('widget', array(null, 'hidden', 'text', 'select', 'checkbox', 'radio'));
}

/**
Expand Down
0