Summary
We now have four classes serving related but overlapping concerns at the "page" level:
| Class |
Inherits |
Purpose |
| BaseWebFormsComponent |
ComponentBase |
Base for controls — styling, FindControl, ID mangling, theming |
| WebFormsPageBase |
ComponentBase |
Page code-behind shim — Request, Response, ViewState, PostBack, ClientScript |
| WebFormsPage |
NamingContainer → BaseWebFormsComponent |
Layout wrapper — NamingContainer scope + ThemeProvider + <head> rendering |
| WebFormsForm |
ComponentBase |
Form data capture via JS interop (added in #533) |
Consolidation Opportunities
1. WebFormsForm → WebFormsPage
In Web Forms, <form runat="server"> lived inside the Page. WebFormsPage already wraps page content with NamingContainer and theming — it could also wrap content in a <form> and handle form data capture automatically. This would eliminate the need for migrated pages to manually add <WebFormsForm OnSubmit="SetRequestFormData">.
2. WebFormsPageBase → WebFormsPage
These split the "page" concept into code-behind (abstract base) and rendering (concrete component). Merging them would give pages a single base class that provides both the shim APIs (Request, Response, ViewState) and the structural rendering (NamingContainer, theming, head). The tradeoff: pages that only need the code-behind shim would inherit rendering they don't use.
What should stay separate
BaseWebFormsComponent is fundamentally different — it's the base for ~40+ controls, not pages. No consolidation needed there.
Context
This was identified during the #533 WebFormsForm implementation. The current separation works correctly but requires manual wiring that Web Forms handled automatically.
Summary
We now have four classes serving related but overlapping concerns at the "page" level:
<head>renderingConsolidation Opportunities
1. WebFormsForm → WebFormsPage
In Web Forms,
<form runat="server">lived inside the Page.WebFormsPagealready wraps page content with NamingContainer and theming — it could also wrap content in a<form>and handle form data capture automatically. This would eliminate the need for migrated pages to manually add<WebFormsForm OnSubmit="SetRequestFormData">.2. WebFormsPageBase → WebFormsPage
These split the "page" concept into code-behind (abstract base) and rendering (concrete component). Merging them would give pages a single base class that provides both the shim APIs (Request, Response, ViewState) and the structural rendering (NamingContainer, theming, head). The tradeoff: pages that only need the code-behind shim would inherit rendering they don't use.
What should stay separate
BaseWebFormsComponent is fundamentally different — it's the base for ~40+ controls, not pages. No consolidation needed there.
Context
This was identified during the #533 WebFormsForm implementation. The current separation works correctly but requires manual wiring that Web Forms handled automatically.