[Validation] Form labels with the DisplayName and Label components

[oroztocil]

Scenario contact: @ilonatommy

Scenario

The DisplayName and Label components render a property's display name from its [Display] or [DisplayName] attribute, so field wording lives on the model instead of being repeated in markup. Label renders a <label> element and associates it with its input, either by wrapping the input or by matching for to the input's generated id. This validates both components on simple and nested models, and with localized display names.

Note that Label and DisplayName are new components, distinct from the older InputBase.DisplayName parameter.

Minimum build

.NET 11 Preview 7 or later.

Configurations to cover

• Blazor Web App
  • Static SSR
  • Interactive Server
  • Interactive WebAssembly
  • Interactive Auto
• Standalone WebAssembly
• Hybrid (MAUI)

Also exercise

• Published output
• An existing .NET 10 app upgraded to .NET 11
• Trimming or ahead-of-time compilation
• More than one server instance, or a proxy in front
• Hot Reload
• An IDE as well as the command line
• Container

Setup

For the localization part you need resource files for two cultures, one of which is not your machine's own, and a way to switch culture at runtime.

What to build

Two models:

• A flat one, such as a product, where some properties carry [Display(Name = "...")], others carry [DisplayName("...")], and one carries neither.
• One with a nested object, such as an order containing a delivery address, so some fields belong to a child branch.

Over them:

• An edit form using Label in both patterns: wrapping the input for some fields, and standalone with for/id for others. Include fields from the nested branch.
• A table whose column headers use DisplayName.
• Validation on a few fields.

Then point the [Display] attributes at resource files, translate them, and make the culture switchable.

Things to try

• The same property rendered by DisplayName in a table header and by Label in the form.
• Clicking labels in both patterns and watching where focus lands.
• The property with no display attribute.
• Nested-branch fields, including a property name that also exists on the root.
• Submitting invalid values and reading how fields are named in the messages.
• Switching culture and reloading.
• Localized names supplied with [Display(ResourceType = typeof(MyResources), Name = "...")].
• Setting an id on an input yourself and seeing what its Label does.

Expected behavior

DisplayName and Label both render the name from the property's metadata, so a table header and a form label for the same property always agree. A property with no attribute falls back to its property name. Label associates with its input in both patterns. Nested fields are addressed independently of same-named root fields. Localized names follow the active culture.

Must hold

• A property with [Display(Name = "...")] renders that name in both DisplayName and Label.
• A property with [DisplayName("...")] renders that name.
• A property with neither attribute renders its property name.
• Standalone Label renders a for equal to its input's id, and clicking it focuses that input.
• Wrapping Label renders the input inside the <label>, and clicking the label text focuses it.
• A nested field and a same-named root field render different id values, each label pointing at its own input.
• Under the second culture, both components render the translated names.

Expected differences between configurations

• Inputs rendered on the server, which means static SSR and Interactive Server, also render a name attribute so the form can post. Inputs rendered in the browser, which means Interactive WebAssembly and Standalone WebAssembly, may not. The id that ties a label to its input is present in every configuration.
• Culture switching may need to be implemented differently for the individual configurations. Note that culture switching is not the scenario tested here, just a setup.

Documentation to use

• New DisplayName component and support for [Display] and [DisplayName] attributes
• Label component
• DisplayName API reference
• Label API reference
• DisplayAttribute
• ASP.NET Core Blazor globalization and localization

What to report

Report results using the format described in the validation testing manual. Include link to a repository with the test app.

[Yuvan111]

Test report

• Build tested: 11.0.100-preview.7.26381.103
• Configurations tested: Interactivity render modes (Auto, Server, WASM & SSR) and Standalone WASM
• Also exercised: None
• OS, browser, IDE: macOS, Chrome & Safari
• Sample app: https://github.com/Yuvan111/FormLabelDisplayTesting
• Outcome: works with one issue

Checks

Check	Result	Evidence
A property with [Display(Name = "...")] renders that name in both DisplayName and Label	pass	DIsplay & DisplayAttribute
A property with [DisplayName("...")] renders that name	pass	DIsplay & DisplayAttribute
A property with neither attribute renders its property name	pass	DIsplay & DisplayAttribute
Standalone Label renders a for equal to its input's id, and clicking it focuses that input	pass	Label click focuses
Wrapping Label renders the input inside the , and clicking the label text focuses it	pass	Label click focuses
A nested field and a same-named root field render different id values, each label pointing at its own input	pass	Nested field html
Under the second culture, both components render the translated names	pass	localize testing

Problems

1. Scenario problem Validation message display the property name value instead Display attribute value.

   • What happened: When I set validation fields for the InputNumber component with standalone Label component, the validation message shows the property name instead of the displayName attribute.

   • what you expected instead: Validation message should be shown with Display attribute value (Unit Price not an UnitPrice)

   • the steps to reproduce:

        1. Run the Github sample.
        2. Navigate to Scenario testing page.
        3. Click on unit price input.
        4. Delete the entire value and focus out.
        5. Now check the validation message.
     

   • Evidence:

   In Auto / Server / WASM:

   

   In SSR:

   

[ilonatommy]

@Yuvan111, we had the reported issue fixed in rc1 by #68688. Could, you please test the previously failing scenario once rc1 packs are published and update this issue with the results?