Sprint 3: Add DetailsView and PasswordRecovery components

[csharpfritz]

Sprint 3: DetailsView + PasswordRecovery

Brings the library to 50/53 components (94%) — effectively feature-complete for practical Web Forms migration.

New Components

DetailsView (Data Controls)

• Single-record display in vertical table layout (one row per field)
• AutoGenerateRows via reflection, explicit field definitions
• Three modes: ReadOnly, Edit, Insert with mode switching
• Single-record paging with numeric page links
• Full CRUD events: ItemCommand, ModeChanging/Changed, PageIndexChanging/Changed, ItemDeleting/Deleted, ItemUpdating/Updated, ItemInserting/Inserted
• DetailsViewMode enum (ReadOnly=0, Edit=1, Insert=2)
• Inherits DataBoundComponent<ItemType> matching GridView pattern

PasswordRecovery (Login Controls)

• 3-step password reset: UserName → Question → Success
• Table-based HTML matching ChangePassword/CreateUserWizard patterns
• All configurable labels, titles, instructions per step
• Events: VerifyingUser, UserLookupError, VerifyingAnswer, AnswerLookupError, SendingMail, SendMailError
• Templates: UserNameTemplate, QuestionTemplate, SuccessTemplate
• Reuses existing LoginControls style sub-components + new SuccessTextStyle

Testing

• 71 new bUnit tests (42 DetailsView + 29 PasswordRecovery)
• 797 total tests passing, 0 failures
• Integration tests: 2 smoke tests + 5 interaction tests for sample pages

Documentation

• docs/DataControls/DetailsView.md — full component docs with migration guide
• docs/LoginControls/PasswordRecovery.md — full component docs with migration guide
• docs/Migration/DeferredControls.md — migration notes for Chart, Substitution, Xml (permanently deferred with Blazor alternatives)
• mkdocs.yml updated, README.md updated

Samples

• DetailsView sample: auto-generated rows, paging, edit mode
• PasswordRecovery sample: 3-step flow with event handlers
• NavMenu.razor and ComponentList.razor updated

Gate Review

Both components reviewed and APPROVED by Forge (Lead/Web Forms Reviewer).

In general, to fix a "useless assignment to local variable" warning, either (a) remove the variable and associated assignment if the value truly is not needed, or (b) if the value was intended to be used, update the code so that it is consumed (for example, for conditional logic or styling). Here, the calculation of isAlternating has no effect on the rendered output, so the safest behavior-preserving fix is to remove the unused variable declaration/assignment and keep the rest of the loop intact.

Specifically for src/BlazorWebFormsComponents/DetailsView.razor, within the @foreach (var field in fieldList) loop (around line 36–44), remove the line var isAlternating = rowIndex % 2 == 1;. If alternating-row behavior is desired in the future, it can be reintroduced by actually using this expression (for example, to set a CSS class), but that would change current behavior and goes beyond a minimal, non-functional fix. No new imports, methods, or definitions are needed; we only delete the unused variable.

To fix the problem, we should replace the manual in-loop filtering (if (!prop.CanRead) continue;) with an explicit LINQ filter on the properties sequence. Instead of iterating over all properties and skipping unreadable ones, we iterate only over readable properties using .Where(p => p.CanRead).

Concretely, in src/BlazorWebFormsComponents/DetailsView.razor.cs, within GenerateAutoFields(), update the foreach (var prop in properties) loop to iterate over properties.Where(prop => prop.CanRead) and remove the if (!prop.CanRead) continue; check. No new imports or helpers are required because System.Linq is already imported. This change preserves behaviour: we still add a DetailsViewAutoField for every readable property and ignore unreadable ones.