Blazor Form Validation showing incorrect Display Name Annotation

[pelhamrj]

Describe the bug

When using data annotations on a model with the <EditForm> component, DateTime does not display the correct [Display] name set on the annotated model.

To Reproduce

Steps to reproduce the behavior:

1. Using this version of ASP.NET Core 3.0 Preview 6
2. Create an empty project and use the following code:

public class MyModel {
    [Required]
    [Display(Name = "Received Date")]
    public DateTime ReceivedDate { get; set; }
}

<EditForm Model="@MyModel" OnValidSubmit="@HandleValidSubmit">
    <div class="input-group mb-3">
        <div class="input-group-prepend">
            <span class="input-group-text" id="Date Received">Date Received</span>
         </div>
         <InputDate Class="form-control" Id="DateReceived" @bind-Value="@MyModel.ReceivedDate" />
          <div class="invalid-feedback d-block">
              <ValidationMessage For="@(() => MyModel.ReceivedDate)" />
          </div>
    </div>
</EditForm>

Expected behavior

The error message should display "The Received Date field must be a date."

Actual behavior

The error message displays: "The ReceivedDate field must be a date." (Notice the lack of space on the field name).

Workaround

You can manually set the ParsingErrorMessage attribute as shown here:

<InputDate ParsingErrorMessage="The Received Date field must be a valid date." Class="form-control" Id="DateReceived" @bind-Value="@MyModel.ReceivedDate" />

Screenshots

Additional context

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview6-012264
 Commit:    be3f0c1a03

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17763
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100-preview6-012264\

Host (useful for support):
  Version: 3.0.0-preview6-27804-01
  Commit:  fdf81c6faf

.NET Core SDKs installed:
  2.1.604 [C:\Program Files\dotnet\sdk]
  2.1.700-preview-009618 [C:\Program Files\dotnet\sdk]
  2.1.800-preview-009677 [C:\Program Files\dotnet\sdk]
  2.1.800-preview-009696 [C:\Program Files\dotnet\sdk]
  3.0.100-preview6-012264 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview6.19307.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview6-27804-01 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0-preview6-27804-01 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[mkArtakMSFT]

We've moved this issue to the Backlog milestone. This means that it is not going to happen for the coming release. We will reassess the backlog following the current release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.

[zHaytam]

Hello, since PR #19489 was closed because it doesn't align with the design goals, how would someone go about solving this?
Thank you

[SteveSandersonMS]

@zHaytam Since this would be a new feature with new APIs, it would be good to start by proposing possible designs.

Some possible ways you could approach it:

• The InputBase class could have a new protected virtual method for getting the field's display name (defaulting to the current value, FieldIdentifier.FieldName). Then developers who want to wire things up to DataAnnotations metadata could sublcass the Input* components and override the method to get a name from the DataAnnotations metadata.
• Or, the InputBase class could have a new optional parameter, DisplayName. People using any of the Input* components could pass a value like <InputNumber DisplayName="@(Localize["Phone Number"])" @bind-Value="..." />. This would work nicely with localization and optionally calling some helper to get the string from DataAnnotations metadata.
• Or, if you really want it to be automatic, it might involve defining some new concept of a metadata provider you can register in the EditContext, then the extend <DataAnnotationsValidator> to act as a metadata provider, and change the Input* components to ask the edit context to supply the field's display name. This is of course a much more complex solution.

[zHaytam]

Thank you for the reply.

1. IMHO, I think most people won't like to subclass all the Input* components just to get display names up & running, it seems like a lot of "boilerplate".
2. As you said, it is a much more complex solution and I don't have enough knowledge to do it unfortunately.

This leaves me with solution number 2, which seems to be a good one, especially since localization will be supported.

I do think we should provide the helper function that gets the string from DataAnnotations metadata, if yes, where would this helper function exist?

Thanks again!

[captainsafia]

I do think we should provide the helper function that gets the string from DataAnnotations metadata, if yes, where would this helper function exist?

We discussed this on Gitter but posting the response here for archival purposes. We want to avoid adding this helper function in the framework because:

• We don't really have a framework for exposing these types of util/helper APIs and they typically indicate scope creep on the part of the framework.
• Not having an opinion about what helper functions we expose with regard to this allows devs and framework authors to write their own set of helper utils to read the parameter string from anywhere (including the DataAnnotations metadata)