ITSV for Web: The Mirror of the ITS WinForms Controls

Two Worlds, One Philosophy

I.T.S. has long used a WinForms control suite built around one practical idea: describe the screen instead of rebuilding its infrastructure. Configuration rows define grids, filters, action panels, report launchers, and relationships. Standard controls interpret those rows, connect themselves, and react to the user.

ITSV translates that philosophy to the web. It is not a literal copy of desktop widgets. A browser has a different lifecycle, security boundary, state model, and interaction cost. The web suite preserves the contract-driven development model while using the mechanisms available in classic ASP.NET Web Forms.

WinForms capability	ITSV web counterpart
Metadata-driven grid	ITSV with ITSVPanel
Bound filters and editors	ITSCntrlPnl, ITSCntrlFltr, ITSVSearch, ITSBetween, and ExtDropDown
Row and bulk actions	Cell Cmm definitions and the multirow VCmm launcher
Context-sensitive panels	Reactive visibility and floating flyouts
Integrated reporting	RViewer with server-side session payloads
Configuration tables	Meta, GetConf, SSRS, VCmm, and MainMenu

The developer declares what the page should do. The control suite owns when and how the recurring behavior happens.

The Architecture of the Web Suite

The target environment is ASP.NET Web Forms on .NET Framework 4.8. This web compatibility target is intentionally separate from the ITS Framework desktop runtime on .NET 10 for Windows. Pages use Master Pages, .aspx markup, C# code-behind, ScriptManager, and UpdatePanel for partial-page interaction. Three projects divide ownership:

• ITSWHF: the Web Forms control library. It owns ITSV, ITSVPanel, ITSCntrlPnl, ITSCntrlFltr, ITSVSearch, ITSBetween, WFBasePage, GlobalSettings, and AllowDownload.
• ITSWH: shared utilities and contracts, including IContracts/ITbl, ExtControl, ExtDropDown, TknPayload, and ExtDataDataSet.
• ITSGRWeb: the host application containing Master Pages and business pages such as Dashboard, Agent, ClaimReport, Interchange, AIContext, ECard, RViewer, and Subscriber.

The critical dependency points inward through a small contract. Controls in ITSWHF do not know the consuming application. They request a table through ITbl.GetTbl(t, k, f); each page resolves that request through its own source, such as Usr.GetDT. The same grid or dynamic parameter panel can therefore run in Dashboard, Agent, or a future page without acquiring a dependency on any of them.

ITSGRWeb page implements ITbl
             ↓ supplies named tables
ITSWHF control interprets metadata
             ↓ uses shared contracts
ITSWH utilities and payload types
             ↓
configured Web Forms experience

Cross-cutting components provide a stable shell. WFBasePage centralizes session, culture, and security services. GlobalSettings and AllowDownload govern global behavior. Master Pages own layout, authentication, inactivity handling through SessionTTL.js, and language selection through CbLg.

ITSV: The Dynamic Grid

ITSV is the web counterpart of the ITS smart grid. Its configuration is read from metadata groups such as MCol, MAgg, MLnks, and mvcmm. Those definitions drive columns, formatting, paging, sorting, aggregations, relationships, and available actions.

Stable row identity across postbacks

The grid uses an internal logical key such as csys_internal_k to recover the authoritative row on postback. Client events do not need to carry the full record or sensitive identifiers. The server uses the logical key and its retained table context to resolve the selected row.

Active cells and server-resolved commands

Cell commands are metadata. A TKN command can launch a report or configured URL using row context. An SMT command can contain tokens such as {|claim_id|}, but token resolution occurs on the server against the selected row rather than trusting client-supplied values.

Report parameters and target data are stored in a SessionTknPayload under an opaque GUID. The browser receives only a reference such as ?k={guid}. RViewer retrieves the payload on the server and launches the corresponding SSRS report.

Relationships and bulk work

MLnks describes master-detail relationships between grids. Aggregates from MAgg can recompute as the active filter or page changes. The ITSVPanel wrapper adds the top filter bar, selection-conditioned zones, and a VCmm flyout for running configured commands over multiple selected rows.

ITSCntrlPnl: Building Controls on the Fly

ITSCntrlPnl begins as an empty container. At runtime it reads a collection of metadata rows from DMetas and creates the required controls:

• Type=cb creates a DropDownList with a named dataset, static or default filter, previous-value restoration, and optional cascading dependencies.
• Type=chk creates a CheckBox for flags.
• Type=txt, the default, creates a TextBox for free-form values.
• Additional types can be registered centrally without changing each consuming page.

Conventional identifiers such as dyn_par_cb_*, dyn_par_chk_*, and dyn_par_txt_* let the framework collect the resulting values uniformly as report or query parameters.

Web Forms requires dynamic controls to be reconstructed early and consistently for ViewState and posted values to work. The panel therefore caches its definition at the appropriate page or session scope and safely rehydrates the same control tree across postbacks. Controls flagged for server interaction register as AsyncPostBackTrigger elements inside the UpdatePanel. A parent selection can refresh dependent controls without a full-page reload.

[report group] → [report] → dynamic parameter panel
                                      |
                                      v
                                  Load action
                                      |
                                      v
                                    ITSV
                       +--------------+--------------+
                       |              |              |
                selection panel   VCmm flyout   action + note

The Filter and Input-Control Family

The grid depends on smaller controls that share the same contract-first approach:

• ITSCntrlFltr: reusable composite filtering.
• ITSVSearch: a consistent search surface for configured grids.
• ITSBetween: coordinated lower and upper values for date or numeric ranges.
• ExtDropDown and other Ext* controls: convention-bound editors with localization support.

Each page implements ITbl; each control requests the table it needs. This keeps lookup loading and business context under the host page while leaving rendering, binding, restoration, and common interaction inside the reusable control.

Dynamic Panels and the Live Experience

A metadata-driven page must still feel responsive. ExternalControlVis evaluates client-side visibility rules so panels can appear when a row is selected, a combo gains a value, or another region becomes active without forcing a postback. Floating flyouts use layering rather than restructuring the page, which is useful for multirow command launchers.

The content of a panel can vary by configuration. A VCmm.grp value determines which action catalog applies to the current grid. MLnks describes master-detail behavior. Hidden fields and indicators such as hfCtxLabel, ctxIcon, and ctxChanged can warn when the visible parameters no longer match the context used for the loaded results.

The resulting experience is reactive within the boundaries of Web Forms: JavaScript handles immediate presentation changes, partial postbacks perform scoped server work, and the server remains authoritative for data and protected actions.

Security by Design

The browser is not part of the trusted server environment. ITSV therefore does not reproduce the direct relational trust model of the RDP-hosted WinForms runtime. It adapts the shared philosophy to a stricter boundary:

• Command arguments carry logical indices or opaque row keys, not complete sensitive payloads.
• The server resolves metadata tokens against its own ClMetaDic and authoritative DataTable.
• SessionTknPayload stores report parameters, destinations, and filters under a GUID that reveals no business values.
• VCmm.grp limits commands to the catalog associated with the current grid context.
• Usr.Authenticate, Master Page controls, and centralized session caches provide consistent authentication and configuration.
• SessionTTL.js supports inactivity handling declared by the shared shell.

Opaque references reduce exposure, but they are not authorization by themselves. Every server-side command must still validate the user, context, record access, payload lifetime, and action permission when it executes.

Why Reuse Matters in Web Forms

Web Forms makes it easy for pages to accumulate event handlers, binding code, ViewState workarounds, and slightly different versions of the same filter or report launcher. ITSV places that repeated engineering in tested controls.

• Business pages contain more layout and intent, and less infrastructure code.
• Filtering, searches, commands, flyouts, and report launches behave consistently.
• A new configured screen can begin with metadata rows and an ITbl implementation rather than a new control framework.
• Server-resolved actions establish a consistent security pattern.
• Teams already familiar with the ITS WinForms suite retain the same mental model.

The gain is not that every page becomes code-free. Unique workflows and business algorithms still belong in focused code-behind or service components. The suite removes repetition around behaviors the platform already knows how to perform.

The Stack and Its Future

ASP.NET Web Forms remains tied to .NET Framework; it was not carried into modern .NET. The current implementation therefore targets .NET Framework 4.8 and its Windows lifecycle. This is an operating constraint, not a reason to discard a working internal application prematurely.

The durable asset is the declarative model: metadata definitions, table contracts, payload semantics, command catalogs, token resolution, and the rules behind ITSV, ITSVPanel, and ITSCntrlPnl. A future migration can separate those contracts from Web Forms-specific control lifecycle code. Where dependencies permit it, shared logic can move into a portable library while a modern UI layer reimplements the renderer as Razor or Blazor components.

That migration is not a simple control substitution. ViewState, postback reconstruction, UpdatePanel triggers, server events, session affinity, and Master Page responsibilities must be mapped explicitly to component state, endpoints, authorization, and navigation in the target platform. Preserving metadata does not eliminate migration work; it protects the business definitions from being rewritten unnecessarily.

Operating Boundaries and Tradeoffs

ITSV is appropriate for governed enterprise web applications that already depend on the Microsoft stack, server-side sessions, SSRS, and configuration-driven workflows. It is especially valuable when an organization maintains both WinForms and Web Forms experiences and wants the same architectural vocabulary across them.

The tradeoffs are concrete:

• Dynamic control reconstruction must follow the Web Forms lifecycle precisely.
• UpdatePanel improves perceived responsiveness but still performs server lifecycle work and can become expensive if boundaries are too broad.
• Session payloads require expiration, cleanup, affinity planning, and protection against replay or unauthorized lookup.
• Configuration failures surface at runtime, so metadata validation and diagnostics are essential.
• Classic Web Forms is a maintenance platform rather than the destination for new public-facing greenfield systems.

The architecture should be judged against its operating environment. It is not a recommendation to introduce Web Forms into a new browser platform. It is a disciplined way to extend and govern an established Web Forms estate while preserving a reusable ITS development model.