8000 [Form] EnumType: Use the enums `value` as default label (instead of `name`) · Issue #44596 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content
8000

[Form] EnumType: Use the enums value as default label (instead of name) #44596

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

Closed
ThomasLandauer opened this issue Dec 13, 2021 · 7 comments
Closed
Labels

Comments

@ThomasLandauer
Copy link
Contributor

Description

Right now, EnumType uses the enum's name as default <label> for the <input>, see https://github.com/symfony/symfony/blob/6.1/src/Symfony/Component/Form/Extension/Core/Type/EnumType.php#L34

But since PHP only allows a very limited set of characters for enum names (ASCII, no blanks, etc.), it might be better to use the enum's value by default?

This would be a BC break. If that's not worth it, then maybe a boolean option, e.g. value_as_label?

I know it can be overridden with choice_label (even though that's not documented - see symfony/symfony-docs#16179 (comment)), but since I think this will be a common need in the future, it might be better to offer an easier way.

Example

No response

@carsonbot carsonbot added the Form label Dec 13, 2021
@derrabus
Copy link
Member

it might be better to use the enum's value by default?

Absolutely not. The value is for machines, the name for humans. And since we support plain unit enums, we might not even have a value.

Using the name as label is a reasonable default.

This would be a BC break. If that's not worth it

It isn't.

I know it can be overridden with choice_label

This is the way to go, imho. The closure that you would have to use here is really trivial.

even though that's not documented

Do you want to provide a PR to fix the docs?

@ThomasLandauer
Copy link
Contributor Author

The value is for machines, the name for humans.

I agree with all you're saying, except this. Take this example:

enum Agree
{
    case Agree = 'I agree';
    case DontAgree = "I don't agree";
}

Sure you can refactor this to yes/no or true/false, or whatever. But there is just no way to use the nicely formatted "I agree" as name.

Do you want to provide a PR to fix the docs?

Sure, see symfony/symfony-docs#16179

@derrabus
Copy link
Member

But there is just no way to use the nicely formatted "I agree" as name.

And the purpose of the value is not to provide nice human-readable values either. It is meant for serialization purposes as documented in https://www.php.net/manual/en/language.enumerations.backed.php.

Sure, you can store your label here, but it's just not a good practise. And I refuse to make a bad practise the default behavior and I am very reluctant to add boolean flags to switch to a bad practise. Again, the closure you need to use the value as label is trivial. Let's just document the choice_label option properly. That should be enough imho.

@ThomasLandauer
Copy link
Contributor Author
ThomasLandauer commented Dec 13, 2021

OK, so let's close this. But what would you say is a good practice then? Having some short string as value and a dedicated method for the label?:

enum Dressing: string
{
    case LemonVinaigrette = 'LM';
    case ThousandIslands = 'TI';

    public function label(): string
    {
        return match($this) {
            LemonVinaigrette => 'Lemon Vinaigrette',
            ThousandIslands => 'Thousand Islands',
        };
    }
}

@derrab
8000
us
Copy link
Member

Yes. If the enum should be aware of labels, this is probably your best option. 👍

@ThomasLandauer
Copy link
Contributor Author

OK, I see what you mean. But I certainly wouldn't call it a bad practice if somebody does it the other way:

enum Dressing: string
{
    case LemonVinaigrette = 'Lemon Vinaigrette';
    case ThousandIslands = 'Thousand Islands';
}

Takes a few bytes more storage space, but (depending on the number of records) that might be irrelevant.

@nicolas-grekas
Copy link
Member

Linking back to #43095 for reference.

@derrabus derrabus closed this as not planned Won't fix, can't repro, duplicate, stale Jun 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants
0