DataGrid: Allow using enum with Display attributes for filter #7621

[TheCrazyWolf]

Description

Fix: #7621
Fix: #5766
Using name of enum in filter of DataGrid by Display attribute, for example:

public enum EducationFinance
{
    [Display(Name = "Бюджет")]
    Free = 0,
    [Display(Name = "Внебюджет")]
    Paid = 1
} 

if attribute non exists, will be returns default value of enum

Added

How Has This Been Tested?

Compiled and test in my project

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• The PR is submitted to the correct branch (dev).
• My code follows the code style of this project.
• I've added relevant tests.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.98%. Comparing base (28bc599) to head (6058f0e).
Report is 578 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #8581      +/-   ##
==========================================
+ Coverage   89.82%   90.98%   +1.15%     
==========================================
  Files         412      410       -2     
  Lines       11878    12546     +668     
  Branches     2364     2451      +87     
==========================================
+ Hits        10670    11415     +745     
+ Misses        681      578     -103     
- Partials      527      553      +26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[danielchalmers]

It should probably fallback so you don't need both attributes on the enum, like for example:

    /// <summary>
    /// Returns the best display name for the given type.
    /// </summary>
    /// <param name="shortName">Try to find the shorter version of the name</param>
    public static string GetDisplayName(this Type type, bool shortName = false) =>
        (shortName ? type?.GetCustomAttribute<DisplayAttribute>()?.ShortName : null) ??
            type?.GetCustomAttribute<DisplayAttribute>()?.Name ??
            type?.GetCustomAttribute<DisplayNameAttribute>()?.DisplayName ??
            type?.GetCustomAttribute<DescriptionAttribute>()?.Description ??
            type?.Name;

But Isn't there a source generator for this or something? @ScarletKuro

[ScarletKuro]

But Isn't there a source generator for this or something? @ScarletKuro

The source generator is only working with the DisplayNameAttribute attribute, it's not available for user code, and it won't help you if you pass an enum in the runtime which is the case here.

I do not understand why Adornment was annotated with DisplayAttribute when we talk about the Enums in DataGrid that are supplied in the model?
For unit testing the author should create own enum type and test it, and not pick any of the existing ones.
This PR also didn't fix the code quality errors.

I'm also not sure if this is fixing localization issues, what if you want multi-languages for the enum?
Theoretically it would require a method that first reads the value of the attribute, then checks via localizer that such key exist in the localization and returns a translation, if doesn't exist then fallback to the attribute value. Aka something similar what does the aspnetcore with Data Annotation attributes for the validation localization.

I will let @tjscience and maybe @mikes-gh (if he is interested) to review this instead.

[ScarletKuro]

Hi.

I appreciate you keep this branch up to date. But as you can see your code is failing to build:

1. EnumFormTraining.cs has a wrong encoding.
2. You modified Adornment for some reason.

[ScarletKuro]

@meenzen, wouldn't it be better to do something like injecting the InternalMudLocalizer into the DataGrid and then just do:

-<MudSelectItem T="Enum" Value="@((Enum)item)">@item</MudSelectItem>
+<MudSelectItem T="Enum" Value="@Localizer[item]</MudSelectItem>

It would be more universal. There is one problem that enumeration names can clash like this:

public enum Enum1
{
    Test1
}

public enum Enum2
{
    Test1
}

But maybe we could use a bit of reflection and do something like @Localizer[enumTypeName_enumMemberName], aka Enum1_Test1. This still creates a potential issue that the enums might be more or less the same but live in different namespaces and require different localization. Chances are low, though.

Is there a possibility to add support for DisplayAttribute in the localizer? What are your thoughts on that?

[ScarletKuro]

@henon @meenzen I reworked it completely, again.

The main improvement is that it’s now part of InternalMudLocalizer.
In the previous code in DataGrid, you had to inject both InternalMudLocalizer and IEnumLocalizer which bothered me a lot.
Now it also uses the same concept, ILocalizationEnumInterceptor, as the original localizer, in case you want to override the logic for how the enum is localized.
Earlier, the enum localizer looked like an abomination, but now it actually fits into the localization ecosystem.
A lot better tests.
And you can use it in two ways:

[Display(Name = "Enum value is localized")]
ValueWithDisplay,

[Display(Name = LanguageResource.MudDataGrid_IsEmpty)]
ValueWithDisplayLanguageResource,

The first one is a hard-coded string, second if it finds the key in the LanguageResource then it will use that instead.

[meenzen]

I really like this now!

[meenzen]

Should we add some simple docs?

[ScarletKuro]

Should we add some simple docs?

we can do it after