Document [SupplyParameterFromForm] attribute

[guardrex]

Per #29705 ...

Regarding [SupplyParameterFromForm], the reason we haven't documented it for previous releases is that it's a very new feature 🙂 Its use is somewhat similar to that of [SupplyParameterFromQuery], but it binds parameters to form request entries rather than query parameters. I would suggest content about [SupplyParameterFromForm] should be added to the "Forms and Input Components" document rather than the routing docs, where [SupplyParameterFromQuery] is documented.

Issues describing the design of this feature can be found here and here. Some usage examples can be found in our test components. If this isn't the right info (or not enough info) for you to get started preparing content, please let me know!

The sample app for the main single-form example is at ...

https://github.com/dotnet/aspnetcore/tree/main/src/Components/Samples/BlazorUnitedApp

Blog post ...

https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-preview-6/#form-model-binding-validation-with-server-side-rendering

Additional ...

• Rename Handler property on SupplyParameterFromForm to FormName aspnetcore#49819
• Provide a new form component to simplify form authoring aspnetcore#49653
• Support binding data from a GET based form aspnetcore#49546
• [Blazor] Ignore read only properties in form mapping aspnetcore#49545

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: c3128506-d228-35ca-e34a-183a881acdec
• Version Independent ID: c3128506-d228-35ca-e34a-183a881acdec
• Content: ASP.NET Core Blazor forms and input components
• Content Source: aspnetcore/blazor/forms-and-input-components.md
• Product: aspnet-core
• Technology: aspnetcore-blazor
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

@MackinnonBuck ... I just took a close look at this subject by reading Javier's issue and their discussion.

I think we'd put this work off until after the major Blazor Server/Blazor WebAssembly -- TO -- SSR/CSR changes are made across the docs ... or perhaps just wait until I reach the Forms and Validation article for the SSR/CSR updates and address this issue when I reach the topic.

There's even the possibility that we will version out the current Forms and Validation article for <8.0 and write a new >=8.0 forms article because it might be easier to maintain going forward that way.

UPDATE: I can't fully experiment until Pre7 lands per dotnet/aspnetcore#47804 with its PR dotnet/aspnetcore#49340. Also, the unopinionated (non-EditForm) form work went in for Pre7 on dotnet/aspnetcore#48760.

Note to self cross-links Mackinnon mentioned earlier:

• Design remarks
• Model binding work for Pre7
• Forms test assets

Blog posts:

• https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-preview-4/#handling-form-posts-with-blazor-ssr
• https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-preview-6/#form-model-binding-validation-with-server-side-rendering

[guardrex]

@MackinnonBuck ... If you have a few minutes, I have a ❓ on FormMappingScope.

I may have misinterpreted its use case. I thought that it was to prevent form name collisions ... for example due to a library supplying a form with the same form name as a form in the component that using the library's form.

I tried this .......

HelloFormFromLibrary.razor:

<EditForm method="post" Model="@this" OnSubmit="@Submit" FormName="Hello">
    <InputText @bind-Value="Name" />
    <button type="submit">Submit</button>
</EditForm>

@if (submitted)
{
    <p>Hello @Name from the library form!</p>
}

@code {
    bool submitted = false;

    [SupplyParameterFromForm(Handler = "Hello")]
    public string? Name { get; set; }

    private void Submit() => submitted = true;
}

... and then ...

NamedFormsWithScope.razor:

@page "/named-forms-with-scope"

<h1>Hello form from a library</h1>

<FormMappingScope Name="ParentContext">
    <HelloFormFromLibrary />
</FormMappingScope>

<h1>Hello form using the same form name</h1>

<EditForm method="post" Model="@this" OnSubmit="@Submit" FormName="Hello">
    <InputText @bind-Value="Name" />
    <button type="submit">Submit</button>
</EditForm>

@if (submitted)
{
    <p>Hello @Name from the app form!</p>
}

@code {
    bool submitted = false;

    [SupplyParameterFromForm(Handler = "Hello")]
    public string? Name { get; set; }

    private void Submit() => submitted = true;
}

... and it doesn't really behave the way I expected ...

• The library form works fine, and I see the hidden <input> prefixing the scope to the handler name.
• Using the 2nd form ... the one in the component ... on submit, it removes the first form's message and changes the first form's <input> for Name to match what is typed in the second form's <input> for Name.

Therefore, I think I must have a fundamental misunderstanding of the whole use case. What's the purpose of FormMappingScope and what kind of example would demo it? The test assets examples aren't clearly solving a problem because there's only one form involved ...

• https://github.com/dotnet/aspnetcore/blob/2949277e66731eddd62251941feed12ba440c9fb/src/Components/test/testassets/Components.TestServer/RazorComponents/Components/ComponentWithFormBoundParameter.razor
• https://github.com/dotnet/aspnetcore/blob/2949277e66731eddd62251941feed12ba440c9fb/src/Components/test/testassets/Components.TestServer/RazorComponents/Pages/Forms/NestedNamedFormBoundParameter.razor

[MackinnonBuck]

@guardrex I think your understanding of how the feature should work is correct. This seems like a bug to me but @javiercn would know for sure. Javier, could you give this a look when you get back? Thanks.

[guardrex]

Thx @MackinnonBuck.

In that case, I'll probably go ahead and merge the PR Wednesday with what I understand. We can fix up my draft remarks later.

Let me know, @javiercn, if you want me to open a PU issue on the 👽 strange form behavior 👽 with a repro project linked.