8000 [Form]: Display message next to indivdual radio buttons · Issue #36484 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content
8000

[Form]: Display message next to indivdual radio buttons #36484

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

Jump to bottom
Closed
ThomasLandauer opened this issue Apr 17, 2020 · 4 comments
Closed

[Form]: Display message next to indivdual radio buttons #36484

ThomasLandauer opened this issue Apr 17, 2020 · 4 comments
Labels
Feature Form

Comments

@ThomasLandauer
Copy link
Contributor

Description
I'm looking for a way to display a message next to the label of individual radio buttons (RadioType, i.e. ChoiceType expanded). I think this is the only type of widgets for which Symfony doesn't yet offer a nice way to customize their rendering.

Here's my idea:
Since there are 100 ways of how/where to exactly display that "message" (info, data, whatever), a one-size-fits-all approach probably won't work. So the users will have to adapt their form theme in any case. The question is: How to pass the data to the form template?

Status quo:
If you loop over the field's choices in Twig, you can pass an arbitrary field name:

{% for radio in form.gender %}
    {{ form_widget(radio, {'foo':'bar'}) }} {# But how can we add this to just *some* choices? #}
{% endfor %}

...and then take care of this foo field in your form theme.

Proposed solution:
Allow adding custom data to the choices array in the FormType. How could this be done? Right now, choices is an array in the form [label=>value]. Suggestion:

'choices' => [
    ['label' => 'Female', 'value' => 'f', 'custom/help/payload' => 'whatever'],
    [...],
],

This would give the user a clean way to pass information to the form theme. The actual rendering is left to the theme.
@HeahDude
Copy link
Contributor

Hello @ThomasLandauer, you can already achieve this by implementing the finishView method of form types, either in the type adding the choice field, or for all choice types with a custom type extension.
In your case, from the parent type you can then access the $view['gender']->vars['choices'] which is an array of ChoiceView and also define your own vars there like:

$view['gender']['radio_name']['foo'] = 'bar';

to modify their corresponding FormView.

@ThomasLandauer
Copy link
Contributor < 8000 span data-view-component="true" class="Label ml-1">Author

@HeahDude cool, thanks!! :-)

I got it to work with this inside finishView():

$view['gender'][0]->vars['foo'] = 'bar';

or more verbose:

$view->children['gender']->children[0]->vars['foo'] = 'bar';

Your exact code didn't work for me: $view['gender']->vars['choices'] is indeed an array of ChoiceView, but when I try to add something

$view['gender']->vars['choices'][0]['foo']

... I'm getting

Cannot use object of type Symfony\Component\Form\ChoiceList\View\ChoiceView as array

... which is reasonable - see https://github.com/symfony/symfony/blob/4.4/src/Symfony/Component/Form/ChoiceList/View/ChoiceView.php

And your line $view['gender']['radio_name']['foo'] = 'bar'; didn't work either - what am I supposed to use as radio_name?

Just asking to make sure I didn't miss anything.

Anyway, I'm leaving this issue open, as I see this more as a workaround than a clean solution: Since the choices are addressed by index, it might break when they get reordered.

What about explaining this in the docs? finishView() is only mentioned at https://symfony.com/doc/current/form/create_form_type_extension.html and https://symfony.com/doc/current/form/create_custom_field_type.html which is not quite what people would look for in this regard.

Radio buttons are a special case to me, since they're the only widget where you can't just add something in the template, since you cannot address them individually. So what about adding a dedicated page to https://symfony.com/doc/current/forms.html#learn-more ?

@HeahDude
Copy link
Contributor

Thanks for the feedback :).

$view->children['gender']->children[0]->vars['foo'] = 'bar';
And your line $view['gender']['radio_name']['foo'] = 'bar'; didn't work either - what am I supposed to use as radio_name?

Anyway, I'm leaving this issue open, as I see this more as a workaround than a clean solution: Since the choices are addressed by index, it might break when they get reordered.

Both are resolved the same, by letting original choices keys be the name by default or incremented value as fallback. To get control you can use the choice_name option.

In your case $view->children['gender']->children[0]->vars['foo'] = 'bar'; could be written:

$view->children['gender'][0]->vars['foo'] = 'bar';

since the FormView has an array access on children property (same as Form).

So I don't see for now what could be improved, IMO the choice_name option should be enough to cover predictability here.

What about explaining this in the docs? finishView() I

Yes I agree on this point :), feel free to submit something, though I think it should be done (briefly) in the main Form guide, with a link to the custom field article you mentioned which is going to be updated a little already (ref symfony/symfony-docs#13488 and symfony/symfony-docs#13490). Maybe you can see something that would fit well on top of that?

I would close here nevertheless, unless you have an example in mind of what could be achieved.
But IMHO, current mechanisms are powerful enough and it may not worth the complexity to try to do something more for the use case you came with.

@ThomasLandauer
Copy link
Contributor Author

So I don't see for now what could be improved, IMO the choice_name option should be enough to cover predictability here.

You're talking about this https://symfony.com/doc/current/reference/forms/types/choice.html#advanced-example-with-objects , right? I wasn't aware of this, so I'm closing the issue.

Docs: I just can't work with this GitHub preview, so I'm gonna wait till your PR's are merged :-)

@HeahDude HeahDude mentioned this issue Apr 18, 2020
Closed
@ThomasLandauer ThomasLandauer mentioned this issue Apr 18, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature Form
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ThomasLandauer @xabbuh @HeahDude
0