In WebForms Core, the WebForms class and Action Controls form the server-side command generation layer of the technology.
The WebForms class provides the programming interface used by the server application to describe changes and actions that should occur in the browser. These operations are converted into Action Controls, which are then sent to WebFormsJS for execution.
This creates a clear separation of responsibilities:
- WebForms Class: defines and generates browser operations on the server. - Action Controls: represent those operations in the WebForms Core protocol. - WebFormsJS: parses and executes the Action Controls in the browser.The WebForms class is the server-side programming interface of WebForms Core. It allows backend code to describe operations that should be performed on the HTML document without manually writing JavaScript for each operation.
A WebForms class implementation is available for each supported server programming language. The exact programming syntax can therefore differ between languages, while the underlying WebForms Core concepts and protocol remain the same.
For example, a server application can create an instance of the WebForms class and use its methods to create an element, change its properties, modify its content, remove it, introduce a delay, or change its state.
These methods do not directly manipulate the browser DOM. Instead, they generate Action Controls that describe the requested operations.
In this sense, the WebForms class acts as the Commander of the WebForms Core architecture. It determines which operations should be performed, while WebFormsJS acts as the browser-side Runtime and Executor that performs those operations.
An Action Control is an executable instruction in the WebForms Core protocol. It represents an operation that WebFormsJS can apply to the browser, usually against an HTML element or another browser-side target.
Action Controls are generated by the WebForms class from server-side method calls. The server does not need to send a complete replacement HTML document for every interaction. Instead, it can send only the operations required for the current interaction.
For example, the following WebForms class calls represent several independent operations:
When the response is generated, these operations become Action Controls in the WebForms Core response.
The response is not a description of a component tree or a JSON representation of the user interface. It is a sequence of executable WebForms Core instructions.
The relationship can be represented as:
The WebForms class therefore provides a higher-level programming interface, while Action Controls provide the protocol-level representation of the requested operations.
This distinction is important. A developer normally works with WebForms class methods rather than manually constructing the protocol representation. WebFormsJS, on the other hand, receives and executes the resulting Action Controls.
The following example demonstrates the complete flow using a simple contact form.
To use WebForms Core technology, the WebFormsJS library is added to the <head> section of the HTML page.
On the server side, the application uses the WebForms class implementation for its programming language. The following example uses C# with the CodeBehind framework.
When the user submits the form, the request reaches the server. The server processes the submitted data and creates an instance of the WebForms class.
The WebForms class is then used to generate several browser operations:
<h3> element inside the <form>.green.The call to form.Response() produces a WebForms Core response containing the generated Action Controls. WebFormsJS receives the response, recognizes the [web-forms] marker, parses the Action Controls, and executes them in the browser.
WebForms Core does not require a special client-side data format for ordinary HTML form submission. The form can submit its data as standard form data.
The server can therefore process the submitted values using the normal form data mechanisms of the backend environment.
After processing the request, the server can return a WebForms Core response based on the INI-like protocol syntax.
Each instruction represents an Action Control. WebFormsJS interprets these instructions and applies them to the current document.
The important point is that the server does not need to send the resulting HTML document back to the browser. It sends the actions required to transform the existing document.
Action Controls are intentionally different from a static description of the desired user interface.
For example, a component-oriented system may describe a complete component tree and then determine how that tree should be rendered. In WebForms Core, the server can instead express operations such as adding an element, changing text, modifying an attribute, deleting an element, setting an event, changing state, or performing another supported browser operation.
This makes the protocol command-oriented. The server can compose different Action Controls at runtime according to the result of application logic.
For example, server-side code can decide that a particular user should see a message, another user should have a button disabled, and another user should receive a completely different sequence of operations. The browser does not need a prebuilt component definition for each possible combination. It only needs to understand the individual Action Controls supported by WebFormsJS.
Many Action Controls operate on existing HTML elements. WebForms Core uses WebForms Path Criteria (WPC) to identify those elements.
For example, <h3> can target an h3 element, while (button) can target an element by its name. This allows Action Controls to operate directly on the HTML document without requiring framework-specific component identifiers.
Consequently, the WebForms class can work with ordinary HTML while Action Controls provide the executable instructions that WebFormsJS applies to that HTML.
A WebForms Core response can contain multiple Action Controls. WebFormsJS processes the response and executes the operations as part of the defined execution sequence.
This allows a server response to describe a complete interaction rather than being limited to a single DOM modification.
In the example above, the response can create the success message, modify it, schedule its removal, and disable the submit button as part of the same server-generated response.
The three layers have distinct responsibilities:
This architecture separates application logic from browser execution. The server decides what should happen, the Action Controls carry those decisions, and WebFormsJS performs them against the browser.
Therefore, the WebForms class is not a server-side replacement for the DOM, and Action Controls are not HTML elements themselves. They form the command layer between server-side application logic and browser-side execution.
The complete flow can be summarized as:
This is one of the central ideas of WebForms Core: server-side code can generate executable browser behavior without requiring application-specific JavaScript for every interaction.
The WebForms class therefore provides the programming model, Action Controls provide the command representation, and WebFormsJS provides the browser runtime that executes those commands.
