WebForms Core is based on a Commander / Executor architecture. The Commander determines what should happen, generates WebForms Core commands, and the Executor performs those commands in the target runtime.
In a browser-based application, the most common implementation places the WebForms class on the server as the Commander and WebFormsJS in the browser as the Executor.
The fundamental flow can be summarized as:
This changes the communication model between the server and browser from primarily data flow to command flow. Instead of sending only data and requiring client-side application code to determine what should happen with that data, the Commander can send explicit operations that the Executor can perform.
Every WebForms Core interaction begins with an intended behavior.
The application may need to change an element, add or remove content, modify an attribute, submit data, perform a request, execute a condition, repeat an operation, change browser state, or perform another supported browser operation.
The Commander determines the required behavior and converts that intent into WebForms Core commands.
The intent does not need to be expressed as a client-side component tree or as a complete description of the desired interface. It can be expressed as a sequence of specific operations.
The Commander is the part of the architecture that generates commands.
In a server-client application, the WebForms class acts as the Commander. Developers can use its methods to construct the required Action Controls.
For example:
The WebForms class does not directly manipulate the browser DOM when it is running on the server. Instead, it records the requested operation in the WebForms Core command format.
This separation is fundamental to the architecture:
The Commander therefore describes and organizes execution rather than performing the browser operation itself.
The commands generated by the Commander are represented as Action Controls.
Action Controls are the executable units of the WebForms Core protocol. They describe operations that the Executor can interpret and perform.
For example, a WebForms Core response can contain:
The first command can set the text of the selected element, while the second can set an attribute. The GS separator represents the WebForms Core control-character separator used to separate command parameters.
Action Controls are therefore different from a generic data structure or a JSON UI schema. They represent executable operations in the WebForms Core protocol.
A WebForms class can generate multiple Action Controls during the same execution.
The commands are organized into an execution sequence:
This sequence can contain not only simple DOM operations, but also conditions, loops, requests, delays, asynchronous operations, state operations, browser operations, and other WebForms Core instructions.
The Commander can therefore construct an execution flow rather than merely returning a static collection of data.
Once the Action Controls have been generated, they can be returned to the browser through the appropriate response mechanism.
WebForms Core supports different response forms depending on whether the application also needs to transfer HTML.
When HTML is being returned together with WebForms Core commands, ExportToHtmlComment() can place the Action Controls inside HTML comments:
This allows HTML and executable commands to travel together in the same response while keeping the Action Controls outside the visible document content.
When the application does not need to return HTML and only needs to send commands, Response() can return the WebForms Core response directly:
This separation allows WebForms Core to work with both document-oriented responses and command-only responses.
The Executor receives the Action Controls and executes them.
In browser-based applications, WebFormsJS is the primary WebForms Core Executor.
The Executor is responsible for translating the protocol commands into actual browser operations. The server therefore does not need to directly manipulate the browser DOM. It only needs to generate the appropriate commands.
WebForms Core commands can identify their target through WebForms Place Criteria (WPC) and related input-place expressions.
This allows a command to address an existing HTML element or another browser structure without requiring the HTML element to become a framework-specific component.
This is one of the reasons WebForms Core can maintain HTML fidelity. The command protocol operates on the browser structures that already exist instead of requiring the page to be reconstructed as a separate client-side representation.
WebForms Core is not limited to executing isolated commands. Action Controls can form an execution sequence.
For example, a sequence can conceptually perform the following operations:
The Executor processes the commands according to the execution rules defined by the WebForms Core protocol.
This makes WebForms Core more than a collection of DOM manipulation methods. It provides a command-oriented execution flow that can contain logic and control structures.
In a server-client scenario, the server can orchestrate the interface behavior by generating the required sequence of Action Controls.
The server does not need to send a complete description of the final interface state. It can send the operations required to transform the current browser state into the required state.
This is the basis of the Server-Orchestrated UI model used by WebForms Core.
One important consequence of the command-oriented protocol is that the server can create new combinations of existing commands at runtime.
The client does not need a predefined implementation for every possible combination of operations.
For example, the server can generate a sequence such as:
The Executor does not need to have been specifically updated for this particular sequence. It only needs to understand the individual WebForms Core commands used in the sequence.
This creates an important separation between protocol capability and application behavior. The Executor provides the capabilities, while the Commander can compose those capabilities into different behaviors at runtime.
WebForms Core can also use multiple responses as part of an interaction rather than treating every request as a single document replacement.
A response can contain targeted operations that update only the required parts of the browser interface.
This allows an interaction to be organized around precise changes rather than requiring the entire interface to be regenerated whenever a small part of the page changes.
The exact mechanisms for asynchronous responses, WebSocket, Server-Sent Events, and other communication methods are covered in later chapters.
WebForms Core establishes a clear division of responsibility between the Commander and Executor.
The Commander does not need to implement browser APIs, while the Executor does not need to contain the application's business logic.
This separation reduces the need to duplicate application behavior between server-side and client-side code.
A simplified WebForms Core interaction can be understood as follows:
The important point is that step 5 does not need to produce a new client-side application. The server produces commands for the existing Executor to execute.
The complete model can therefore be represented as:
In this architecture, the Commander and Executor are independent roles. The Commander creates executable instructions, while the Executor provides the runtime that executes them.
The Commander can be implemented on the server or on the client. Likewise, the execution environment is not conceptually limited to a single implementation. WebForms Core can therefore be used as a broader Commander / Executor architecture rather than being defined exclusively as a server-side technology.
Traditional web architectures often communicate by transferring data and leaving the client application to determine what should happen with that data.
WebForms Core can instead transfer the operation itself:
This is the fundamental conceptual change introduced by the Commander / Executor architecture: the communication can carry executable intent rather than only the data from which the client must derive that intent.
The result is a system in which the server can remain responsible for application and interface orchestration, while the browser remains responsible for executing precise operations against its own DOM and browser environment.
