[Form] New form BooleanType class

[emulienfou]

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC?	no
Symfony version	Next for branches 3.x and 4.x

I think it would be great/easier to have a form BooleanType, instead of using the ChoiceType with yes/no values!

What do you think?

I found this useful Gist: https://gist.github.com/fsevestre/abfefe0b66e5f5b24c60

[fsevestre]

Hi, thanks for finding the Gist useful :)
For your information, I published a library: https://github.com/fsevestre/BooleanFormType

About the request, I don't think it should be added into core because the current implementation is limited to API only and is not intended to be displayed on a browser.

For me, FOSRestBundle (issue : FriendsOfSymfony/FOSRestBundle#1224 / PR : FriendsOfSymfony/FOSRestBundle#1312) is the best place to have this form type (my library is a temporary solution until the PR on FOSRestBundle is finished)

But, to quote webmozart (FriendsOfSymfony/FOSRestBundle#1312 (comment)):

The problem about null/false is that the Form component was never designed to be used in API requests. That's what usually a serializer is for. The Form component is designed against the CGI protocol, where each value is a string or not set.
I understand however that the Form component offers functionality that serializers are missing. The problem is that we can't change the Form component to pass false as false (instead of null) without breaking BC

[ostrolucky]

I think what OP suggests is to have just new form type which is just preconfigured choicetype with yes/no choices. Such form type is really common in projects. We use following and it works fine, even in non-API context.

class YesNoRadioType extends AbstractType
{
    const CHOICES = ['YES' => true, 'NO' => false];

    public function getParent()
    {
        return ChoiceType::class;
    }

    public function configureOptions(OptionsResolver $resolver)
    {
        $resolver->setDefaults([
            'expanded' => true,
            'choices' => self::CHOICES,
        ]);
    }
}

[Aerendir]

Yes, I agree with @ostrolucky and find useful the @emulienfou’s proposal.

[xabbuh]

Does anyone of you want to work on a PR implementing this type?

[alamirault]

Would it be better if BooleanType parent is ChoiceType ?

[xabbuh]

In the solution proposed in #27185 (comment) the parent type is ChoiceType.

[ostrolucky]

Btw my opinion on the matter is this issue cannot be satisfied in generic, non-opinionated way. Some people will want it to be checkbox instead of radios, some dropdown, other people something else than yes/no labels. Having own type for this is few lines of codes and guarantees it's the way user wants. Trying to customize such booleanType that would be shipped officially doesn't save much. So in the end letting user create whatever choicetype child as is the case now might be better.

[xabbuh]

@ostrolucky I don't think that really is an issue. This can be customised through the options inherited from the ChoiceType.

[ostrolucky]

So can ChoiceType. User isn't saving much.

[yceruto]

I've the same opinion as @ostrolucky about this proposal, this custom type is very simple to be created by anyone.

Also extending it from ChoiceType will require validating the multiple option and maybe others that don't apply.

[fabpot]

Let's close then.