DEV Community: Elanat Framework

Building a Bubble Popping Game with WebForms Core + Online Demo

Elanat Framework — Thu, 15 Oct 2026 13:12:07 +0000

WebForms Core (WFC) is a server-side UI manipulation technology that lets developers control HTML elements and handle browser events through commands generated on the server. In this tutorial, we will use WebForms Core with C# and CodeBehind to build a simple bubble popping game.

Live demo: Bubble Popping Game

The game demonstrates how to create HTML elements dynamically, attach events, update the score, run intervals, and detect when an element exceeds a specified width, all through WebForms Core commands.

WebForms Core is a technology developed by Elanat and is available in 18 programming languages.

Note: WebForms Core can be used to build simple to moderately complex games, including animated games and logic-based games such as Memory. For large or highly complex games, specialized technologies and tools, such as WebGL, WebGPU, and dedicated game engines, are recommended.

1. Defining the Game Interface

The page contains a game area, a score counter, a speed counter, a message for the end of the game, and a button to start a new game.

<div id="GameArea"></div>
<br />

<b id="Points">Points: <span>0</span></b>
<b id="Speed">Speed: <span>5</span></b>
<b id="Finall"></b>

<input id="PointsValue" type="hidden" value="0">
<input id="SpeedValue" type="hidden" value="5">
<input id="Start" type="button" value="Start New">

The GameArea element is the main container for the bubbles. The Points and Speed elements display the current game values, while the hidden inputs store those values so that WebForms Core commands can read and update them.

The Start button restarts the game, and Finall displays the player's final score when the game ends.

Styling the bubbles

CSS gives the game its visual appearance. The game area uses a light blue background, while each bubble is a green circle with white curved lines to create a three-dimensional appearance.

#GameArea {
    width: 1280px;
    height: 720px;
    background-color: lightblue;
    overflow-x: auto;
    white-space: nowrap;
    display: inline-block;
}

.bubblebox {
    width: 100%;
    height: 100px;
}

.bubble {
    width: 100px;
    height: 100px;
    background-color: #c9e83b;
    border-radius: 50%;
    box-shadow: -10px 0px 10px rgba(0, 0, 0, 0.3);
    float: left;
    position: relative;
    overflow: hidden;
}

.pusher {
    width: 100px;
    height: 100px;
    float: left;
}

The .bubblebox class represents a row containing a pusher and a bubble. The .pusher element occupies space before the bubble, allowing the bubble's horizontal position to change as the pusher grows.

The remaining CSS uses ::before and ::after pseudo-elements to draw decorative curves inside each bubble. Attribute selectors such as [bubblerow="1"] assign different top margins to different rows.

2. Initializing WebForms Core

The main controller is BubblePoppingGameController, which inherits from CodeBehindController.

using CodeBehind;

public partial class BubblePoppingGameController
    : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        WebForms form = new WebForms();

        form.SetCommentEventListener(
            "GameArea", "mutationobserver", "end");

        form.SetCommentEvent(
            "Start", HtmlEvent.OnClick, "start");

        // Game commands are defined here.
    }
}

The WebForms class is used to define the commands that control the game.

Two event configurations are especially important:

SetCommentEventListener registers a MutationObserver-based listener for changes in GameArea. The listener invokes the end command index when the configured event condition is met.
SetCommentEvent associates the button's click event with the start command index.

The controller then defines the command sequences for starting, playing, and ending the game. WebForms Core exports these commands as HTML comments, which WebFormsJS processes in the browser.

This approach allows the developer to define UI operations and event handling in C# without manually writing JavaScript for each interaction.

3. Starting a New Game

The start command index initializes the game:

form.StartIndex("start");

form.AppendForm(Reset());

form.SetText("Finall", "");
form.SetValue("PointsValue", "0");
form.SetText(
    "Points|<span>",
    Fetch.GetValue("PointsValue"));

form.SetValue("SpeedValue", "5");
form.SetText(
    "Speed|<span>",
    Fetch.GetValue("SpeedValue"));

form.AppendForm(Initialization());

form.IncreaseWidth("{pusher}-1", 5);
form.AssignInterval(100, "pusher");

Each operation has a specific purpose.

First, Reset() removes the existing game elements and stops the intervals from the previous game. The final-score message is cleared, and the score and speed values are restored to their initial values.

Fetch.GetValue() reads the value of a hidden input. The result is then used by SetText() to update the corresponding display.

Next, Initialization() creates the first row and its bubble.

Finally, IncreaseWidth() increases the width of the pusher, and AssignInterval() schedules repeated execution of the command associated with the pusher index.

This is an important characteristic of WebForms Core: an interval can repeatedly execute a sequence of UI commands without requiring a custom JavaScript timer for the game logic.

4. Creating Bubbles Dynamically

The Initialization() method defines the structure of a bubble row.

private WebForms Initialization()
{
    WebForms form = new WebForms();

    form.AddTag("GameArea", "div");

    form.SetClass(
        "GameArea|<div>-1", "bubblebox");

    form.SetAttribute(
        "{bubblebox}-1",
        "bubblerow",
        Fetch.Random(1, 8));

    form.AddTag("{bubblebox}-1", "div");
    form.SetClass(
        "{bubblebox}-1|<div>-1", "pusher");

    form.AddTag("{bubblebox}-1", "div");
    form.SetClass(
        "{bubblebox}-1|<div>-1", "bubble");

    form.SetCommentEvent(
        "{bubble}-1",
        HtmlEvent.OnMouseEnter,
        "popping");

    // Movement and overflow detection follow.

    return form;
}

The method creates three elements:

A bubblebox container inside GameArea.
A pusher element inside the container.
A bubble element beside the pusher.

SetClass() assigns the CSS classes, while SetAttribute() adds a bubblerow attribute. Fetch.Random(1, 8) supplies the row number used to determine the bubble's vertical placement.

The last command associates the bubble's mouseover-style event, HtmlEvent.OnMouseEnter, with the popping command index.

When the pointer enters a bubble, WebForms Core can therefore execute the commands defined under popping.

The important point is that the bubble elements are created dynamically. They do not need to be written individually into the original HTML page.

5. Moving the Bubble

The pusher controls the bubble's horizontal position. Its width increases over time, making the bubble move across the game area.

form.IncreaseWidth("{pusher}-1", 1);
form.AssignInterval(10, "pusher-pluse");

The pusher-pluse command index increases the pusher's width by one unit. The interval is assigned a delay of 10 milliseconds.

When the game starts, the pusher index is also assigned a 100-millisecond interval:

form.IncreaseWidth("{pusher}-1", 5);
form.AssignInterval(100, "pusher");

These two intervals perform different roles: pusher-pluse controls the continuous growth of the pusher, while pusher is the separate interval configured during game initialization.

The game also needs to detect when the pusher grows too large. WebForms Core provides a custom DOM event for this purpose.

form.CreateCustomDOMEvent(
    "{pusher}-1",
    "widthOverflow",
    "style",
    "width",
    "greater",
    "1100",
    "",
    true,
    200);

form.SetCommentEventListener(
    "{pusher}-1",
    "widthOverflow",
    "end");

The custom event monitors the pusher's width style and checks whether it exceeds 1100. Its configuration also includes the event options true and 200.

When widthOverflow occurs, the listener invokes the end command index. This connects the movement logic to the end-of-game logic without requiring a manually written JavaScript event handler.

6. Popping a Bubble and Updating the Score

The popping command index defines what happens when the player touches a bubble.

form.StartIndex("popping");

form.IncreaseValue("PointsValue", 1);
form.SetText(
    "Points|<span>",
    Fetch.GetValue("PointsValue"));

form.IncreaseValue("SpeedValue", 1);
form.SetText(
    "Speed|<span>",
    Fetch.GetValue("SpeedValue"));

form.Delete("$/");
form.AppendForm(Initialization());

First, IncreaseValue() increments the score stored in PointsValue. Fetch.GetValue() retrieves the updated value, and SetText() refreshes the score shown on the page.

The speed value is updated in the same way. Each successful bubble interaction increases it by one and refreshes the display.

The command Delete("$/") removes the element selected by that input-place expression. The game then calls Initialization() again, creating another bubble row.

Consequently, a successful interaction updates the counters, removes the targeted element, and creates another bubble. The player can continue interacting with bubbles until the overflow event ends the game.

In this implementation, the speed counter is incremented as a displayed value, but the interval delays themselves remain fixed at 100 and 10 milliseconds.

7. Ending the Game

When the overflow listener invokes the end command index, the controller displays the final score and resets the game elements.

form.StartIndex("end");

form.SetText(
    "Finall",
    "@:Your point is: " +
    form.Inject(
        Fetch.GetText("Points|<span>")));

form.AppendForm(Reset());

Fetch.GetText() reads the displayed score, and Inject() inserts the retrieved text into the command being constructed.

SetText() then displays the final-score message inside Finall. The Reset() method removes the game elements and stops the intervals.

The reset method is defined as follows:

private WebForms Reset()
{
    WebForms form = new WebForms();

    form.ElementExists("GameArea|<div>");
    form.Delete("GameArea|<div>");

    form.DeleteInterval("pusher");
    form.DeleteInterval("pusher-pluse");

    return form;
}

The element-existence check precedes the deletion of the game rows. The method also removes both named intervals, preventing the previous game's movement commands from continuing after a restart or game end.

The Start New button can then execute the start command index to initialize a fresh game.

8. Exporting the Commands

At the end of PageLoad(), the controller exports the commands:

Write(form.ExportToHtmlComment());

This writes the WebForms Core command representation as HTML comments in the response.

WebFormsJS processes these comments in the browser and executes the corresponding operations against the actual HTML DOM. The server defines the command sequences, while the client executes them.

The result is a game whose interface is built and manipulated through WebForms Core rather than through a collection of hand-written JavaScript DOM operations.

Screenshot of Bubble Popping Game

Conclusion

The Bubble Popping Game demonstrates several practical WebForms Core capabilities in a single example:

Dynamically creating HTML elements and assigning CSS classes and attributes.
Connecting browser events to named command indexes.
Updating values and displayed text.
Executing repeated commands through intervals.
Detecting DOM conditions through custom events.
Removing elements, stopping intervals, and restarting the game.

These features make it possible to implement interactive browser experiences using C# and WebForms Core, with WebFormsJS executing the generated commands in the browser.

Try the game: Open the Bubble Popping Game demo

CSRF Protection in WebForms Core Using CodeBehind

Elanat Framework — Sat, 10 Oct 2026 16:03:18 +0000

1. Introduction to CSRF Protection in WebForms Core

Cross-Site Request Forgery (CSRF) is a web security vulnerability in which an attacker tricks a user's browser into sending an unwanted request to a website where the user is authenticated. If the website relies on automatically attached authentication cookies without properly verifying the request, an attacker may be able to trigger actions on behalf of the victim.

WebForms Core (WFC), introduced by Elanat, provides a server-oriented approach to web interface manipulation. The backend generates commands that WebFormsJS executes in the browser, allowing web interfaces to be manipulated through server-generated instructions without requiring a separate frontend framework.

In this article, we will implement a basic CSRF protection mechanism using WebForms Core and CodeBehind, a backend web framework developed by Elanat. We will generate a secure token, store it in a session, add it to an HTML form, and validate it when the form is submitted.

2. CodeBehind as the Backend

CodeBehind handles HTTP requests, manages the session-based CSRF token, validates submitted data, and generates responses through WebForms Core.

The process follows this sequence:

The browser requests the page.
CodeBehind retrieves an existing CSRF token from the session or generates a new one.
WebForms Core adds the token to the HTML form as a hidden input.
The browser submits the form with the token.
CodeBehind compares the submitted token with the token stored in the session.
WebForms Core generates commands to display the validation result.

The security decision takes place on the backend. WebFormsJS executes the resulting interface commands, but it does not determine whether the CSRF token is valid.

3. Generating a Secure CSRF Token

A CSRF token must be unpredictable so that an attacker cannot easily construct a valid request. C# provides RandomNumberGenerator, which is designed for cryptographically secure random number generation.

The following code generates a token from 32 random bytes and converts it into a hexadecimal string:

using System.Security.Cryptography;

string token = Convert.ToHexString(
    RandomNumberGenerator.GetBytes(32));

This produces a 64-character hexadecimal token representing 256 bits of random data.

Unlike a token generated with the ordinary Random class, this value is suitable for security-sensitive purposes. The token should be generated on the server and must not be predictable from public information such as usernames, timestamps, or sequential identifiers.

4. Storing the Token in Session

The token must remain available between the initial page request and the subsequent form submission. In this example, ASP.NET Core Session provides the required storage.

The following method retrieves the existing token or generates and stores one if it does not exist:

private string GetCsrfToken(HttpContext context)
{
    string token = context.Session.GetString("csrf_token");

    if (string.IsNullOrEmpty(token))
    {
        token = Convert.ToHexString(
            RandomNumberGenerator.GetBytes(32));

        context.Session.SetString("csrf_token", token);
    }

    return token;
}

The session allows the server to associate the token with the user's session and retrieve it when the form is submitted. Session services and middleware must be configured correctly in the ASP.NET Core application.

The session cookie should also be protected with appropriate security settings, including HTTPS and suitable cookie attributes.

5. Adding the Token to the HTML Form with WebForms Core

The CSRF token is included in the form as a hidden input. WebForms Core can generate the required interface command without requiring a separate JavaScript operation to create the field.

The example form is:

<form method="POST" action="/security_csrf">
    <label for="email">Email: </label>
    <input type="text" name="email" id="email" />
    <br />
    <button type="submit">Update Email</button>
</form>

In the CodeBehind controller, the token is added to the form using WebForms Core:

WebForms form = new WebForms();

form.AddHidden("<form>", "csrf_token", csrfToken);

Write(form.ExportToHtmlComment());

AddHidden targets the form and adds a hidden field named csrf_token. ExportToHtmlComment() exports the WebForms Core commands in the format expected by the client-side executor.

To execute WebForms Core commands in the browser, the page must also include the WebFormsJS client-side library. For example, if the library is located at /script/web-forms.js, add the following script to the HTML document's <head>:

<script type="module" src="/script/web-forms.js"></script>

Adjust the script path to match the location of the WebFormsJS file in your application.

The browser submits the hidden token along with the other form fields. Although the token is not visible in the interface, it is accessible to the page and must not be treated as a secret from JavaScript executing in that page. Its security depends on its unpredictability and server-side validation, not on the hidden field itself.

Full page management code

public void PageLoad(HttpContext context)
{
    string csrfToken = GetCsrfToken(context);

    if (context.Request.Method == "POST")
    {
        Button_Click(context, csrfToken);
        return;
    }

    WebForms form = new WebForms();

    form.AddHidden("<form>", "csrf_token", csrfToken);

    Write(form.ExportToHtmlComment());
}

6. Validating CSRF Tokens on POST Requests

When the form is submitted, CodeBehind retrieves the token from the request and compares it with the token stored in the session.

The following example checks that both values are non-empty before comparing them:

string formToken =
    context.Request.Form["csrf_token"].ToString();

if (!string.IsNullOrEmpty(csrfToken) &&
    !string.IsNullOrEmpty(formToken) &&
    formToken == csrfToken)
{
    // Continue with the protected operation.
}
else
{
    // Reject the protected operation.
}

Checking both values is important. If the session token is missing or the submitted form does not contain a token, the request must not be accepted.

The == comparison makes the basic validation logic easy to understand. For applications requiring stronger protection against timing-based comparison attacks, a fixed-time comparison can be used instead, as discussed in the final section.

A successful comparison means that the request contains the expected session token. It does not replace authentication, authorization, or validation of the submitted email address.

7. Handling Validation Results with WebForms Core

After validating the token, the controller uses WebForms Core to generate a response that communicates the result to the user.

private void Button_Click(HttpContext context, string csrfToken)
{
    string formToken =
        context.Request.Form["csrf_token"].ToString();

    string email =
        context.Request.Form["email"].ToString();

    WebForms form = new WebForms();

    if (!string.IsNullOrEmpty(csrfToken) &&
        !string.IsNullOrEmpty(formToken) &&
        formToken == csrfToken)
    {
        form.Message(
            "CSRF token validation succeeded.",
            "success");

        form.Message(
            "Your Email is: " + new Security().SafeValue(email));
    }
    else
    {
        form.Message(
            "Security check failed. Please refresh the page and try again.",
            "warning");
    }

    IgnoreAll(); // Transition by bypassing View and Layout
    Write(form.Response());
}

The example uses new Security().SafeValue(email) before including the submitted email in a message. This is intended to prevent untrusted email content from injecting executable HTML or script content into the interface. It is important to use the appropriate output-safety method for the rendering context and avoid encoding the same content twice.

Message generates the interface feedback, while Response() generates the WebForms Core response. IgnoreAll() bypasses the view and layout for this response, allowing the command response to be returned directly.

This demonstrates the separation between security decisions and interface updates: CodeBehind validates the request on the server, WebForms Core generates the commands, and WebFormsJS executes them in the browser.

The application does not have to return an HTTP 403 status solely to display a validation warning. In this command-response workflow, a normal response can preserve Action Control execution. The essential requirement is that the protected operation must never run when validation fails.

8. Additional Security Layers and Conclusion

A session-based CSRF token is an important protection, but it should be part of a broader security strategy.

Fixed-time token comparison

For additional protection, the simple == comparison can be replaced with CryptographicOperations.FixedTimeEquals. This method compares equal-length byte arrays in a way designed to reduce information leakage through timing differences.

For example:

private bool FixedTimeEquals(string a, string b)
{
    if (string.IsNullOrEmpty(a) ||
        string.IsNullOrEmpty(b))
        return false;

    byte[] aBytes = System.Text.Encoding.UTF8.GetBytes(a);
    byte[] bBytes = System.Text.Encoding.UTF8.GetBytes(b);

    if (aBytes.Length != bBytes.Length)
        return false;

    return CryptographicOperations.FixedTimeEquals(
        aBytes, bBytes);
}

The empty-value checks ensure that two missing tokens are never treated as a successful match. The length check ensures that the comparison receives byte arrays of equal length.

Other security measures

Depending on the application, additional measures can include:

Origin validation: Check the Origin header against the expected origin for state-changing requests. A carefully implemented Referer check can be used as a fallback when appropriate.
SameSite cookies: Configure authentication cookies with an appropriate SameSite policy, such as Lax or Strict, according to the application's requirements.
HTTPS: Protect session cookies and requests in transit using HTTPS and suitable secure-cookie settings.
Authentication and authorization: Verify that the user is authenticated and permitted to perform the requested operation.
Input validation and output safety: Validate submitted data and use Security.SafeValue or another appropriate context-specific output-encoding mechanism when displaying untrusted content.

These measures complement one another. Origin validation and SameSite cookies provide additional layers of defense, but they should not automatically be treated as replacements for CSRF token validation where it is required.

With CodeBehind handling the backend logic and WebForms Core managing server-generated interface commands, CSRF protection fits naturally into a server-oriented web application. The security decision remains on the server, while the resulting feedback is delivered through the WebForms Core response mechanism.

Drag and Drop Without Writing JavaScript with WFC + Online Demo

Elanat Framework — Thu, 08 Oct 2026 12:43:58 +0000

Drag and Drop interactions are usually implemented with client-side JavaScript. Developers typically need to listen for pointer events, track the dragged element, prevent default browser behavior, update CSS classes, and finally move or remove the element.

With WebForms Core (WFC), the same interaction can be implemented by defining events and commands on the server. No custom JavaScript event handlers are required.

The following example uses Node.js and Express.

It is recommended to view the drag-and-drop demo before looking at the code.

webforms-core.github.io

The Example

The page contains two zones:

dragZone contains draggable elements.
dropZone is the destination.

When an item is dragged with a mouse, it can be moved between the two zones. On touch devices, where native HTML Drag and Drop is not normally suitable, a direct tap can be used to move an item between the zones.

const express = require('express');
const { WebForms, HtmlEvent, Fetch } = require('./WebForms');

const app = express();
const PORT = 3000;

app.use(express.static('public'));

app.get('/', (req, res) => {
    const form = new WebForms();

    form.setCommentEvent("dragZone|<div>*", HtmlEvent.OnDragStart, "drag-start");
    form.setCommentEvent("-", HtmlEvent.OnDragEnd, "drag-end");

    form.setPreventDefaultEvent("dragZone", HtmlEvent.OnDragOver);
    form.setCommentEvent("-", HtmlEvent.OnDragOver, "drag-over-back");
    form.setCommentEvent("-", HtmlEvent.OnDragLeave, "drag-leave-back");
    form.setCommentEvent("-", HtmlEvent.OnDrop, "drop-back");

    form.setPreventDefaultEvent("dropZone", HtmlEvent.OnDragOver);
    form.setCommentEvent("-", HtmlEvent.OnDragOver, "drag-over");
    form.setCommentEvent("-", HtmlEvent.OnDragLeave, "drag-leave");
    form.setCommentEvent("-", HtmlEvent.OnDrop, "drop");

    form.setCommentEvent("dragZone|<div>*", HtmlEvent.OnTouchStart, "touch-start");

    form.startIndex("drag-start");
    form.saveOuterText("$");
    form.saveId("$", "id");

    form.startIndex("drag-end");
    form.deleteClass("$", "hide");
    form.assignDelay(100);

    form.startIndex("drag-over");
    form.insertClass("dropZone", "highlight");

    form.startIndex("drag-leave");
    form.deleteClass("dropZone", "highlight");

    form.startIndex("drop");
    form.delete(Fetch.save("id"));
    form.addText("dropZone", Fetch.save());

    form.startIndex("drag-over-back");
    form.insertClass("dragZone", "highlight");

    form.startIndex("drag-leave-back");
    form.deleteClass("dragZone", "highlight");

    form.startIndex("drop-back");
    form.delete(Fetch.save("id"));
    form.addText("dragZone", Fetch.save());

    form.startIndex("touch-start");
    form.elementExists("dragZone|{{id}}");
    form.assignReplace("{{id}}", Fetch.getId("$"));
    form.addText("dropZone", Fetch.getOuterText("$"));
    form.else();
    form.addText("dragZone", Fetch.getOuterText("$"));
    form.delete("$");

    res.send(`
        <!DOCTYPE html>
        <html>
        <head>
          <title>Drag and Drop - WebForms Core</title>
          <script type="module" src="/script/web-forms.js"></script>

          <style>
            #dropZone, #dragZone {
                width: 100%;
                max-width: 600px;
                height: auto;
                min-height: 200px;
                border: 2px dashed #ccc;
                border-radius: 5px;
                text-align: center;
                padding: 20px;
                margin: 20px auto;
            }

            #dropZone.highlight, #dragZone.highlight {
                border-color: #4CAF50;
                background-color: #f8f8f8;
            }

            .dragitem {
                width: 100px;
                height: 100px;
                background-color: #4CAF50;
                color: white;
                text-align: center;
                line-height: 100px;
                cursor: move;
                margin: 20px auto;
            }

            .hide {
                display: none;
            }
          </style>
        </head>

        <body>
            <h2>Drag and Drop</h2>

            <blockquote>
                With a mouse, items are moved via drag and drop;
                with touch, they are moved by a direct tap.
            </blockquote>

            <div id="dragZone">
                <div class="dragitem" id="dragitem1" draggable="true">Drag me! 1</div>
                <div class="dragitem" id="dragitem2" draggable="true">Drag me! 2</div>
                <div class="dragitem" id="dragitem3" draggable="true">Drag me! 3</div>
                <div class="dragitem" id="dragitem4" draggable="true">Drag me! 4</div>
            </div>

            <div id="dropZone">Drop here</div>

            ${form.exportToHtmlComment()}
        </body>
        </html>
    `);
});

app.listen(PORT, () => {
    console.log(`Server is running on http://localhost:3000`);
});

Defining the Drag Events

The first step is to associate WebForms Core events with the draggable elements.

form.setCommentEvent(
    "dragZone|<div>*",
    HtmlEvent.OnDragStart,
    "drag-start"
);

form.setCommentEvent(
    "-",
    HtmlEvent.OnDragEnd,
    "drag-end"
);

The selector:

dragZone|<div>*

targets the div elements inside dragZone. Each of these elements can therefore participate in the same drag behavior.

The - input place refers to the event target, allowing the same command sequence to operate on the element that triggered the event.

Saving the Dragged Element

When dragging starts, the example stores two pieces of information:

form.startIndex("drag-start");
form.saveOuterText("$");
form.saveId("$", "id");

The outer text is saved so it can later be inserted into another zone, while the element's ID is saved as id.

This is important because the server-generated commands can later use the saved values without requiring custom client-side JavaScript variables.

Highlighting the Drop Zone

While the user is dragging an item over the destination, the destination receives a visual highlight:

form.startIndex("drag-over");
form.insertClass("dropZone", "highlight");

When the pointer leaves the zone, the class is removed:

form.startIndex("drag-leave");
form.deleteClass("dropZone", "highlight");

The same mechanism is used for the original dragZone.

This means the visual state is controlled through WebForms Core commands rather than through a JavaScript event handler.

Moving the Item

The actual drop operation is particularly simple:

form.startIndex("drop");
form.delete(Fetch.save("id"));
form.addText("dropZone", Fetch.save());

The sequence performs two operations:

Remove the original element using its saved ID.
Add its saved content to dropZone.

The important point is that these are DOM manipulation commands generated by the server-side WebForms class. There is no client-side dragstart, dragover, or drop function written by the developer.

Supporting the Reverse Direction

The same mechanism works when moving an element back from dropZone to dragZone.

form.startIndex("drop-back");
form.delete(Fetch.save("id"));
form.addText("dragZone", Fetch.save());

The destination changes, but the basic operation remains the same:

Delete original element → Add its content to destination

Touch Interaction Without JavaScript

Native HTML Drag and Drop is primarily designed around pointer-based dragging and is not a reliable interaction model for touch devices.

Instead of implementing a separate JavaScript touch system, this example defines a WebForms Core OnTouchStart event:

form.setCommentEvent(
    "dragZone|<div>*",
    HtmlEvent.OnTouchStart,
    "touch-start"
);

The touch behavior is then implemented with WebForms Core commands:

form.startIndex("touch-start");

form.elementExists("dragZone|{{id}}");
form.assignReplace("{{id}}", Fetch.getId("$"));

form.addText("dropZone", Fetch.getOuterText("$"));

form.else();

form.addText("dragZone", Fetch.getOuterText("$"));
form.delete("$");

Screenshot of Drag & Drop Example

The logic is:

If the touched element already exists in dragZone, move it to dropZone.
Otherwise, move it back to dragZone.

In other words, a touch interaction can provide a simple toggle between the two zones without implementing a custom JavaScript drag-and-drop engine.

One Server-Side Definition, Multiple Client Behaviors

The example demonstrates an important aspect of WebForms Core.

The developer describes the interaction on the server:

Event
    ↓
WebForms command sequence
    ↓
WebFormsJS
    ↓
HTML DOM

WebFormsJS executes the commands in the browser. It does not require the developer to write separate JavaScript functions for each event.

The application therefore does not contain code such as:

element.addEventListener("dragstart", ...);
element.addEventListener("dragover", ...);
element.addEventListener("dragleave", ...);
element.addEventListener("drop", ...);
element.addEventListener("touchstart", ...);

Instead, the interaction is declared through the server-side WebForms class.

Why This Is Different

A conventional implementation usually requires the developer to create a client-side interaction layer:

HTML
  ↓
JavaScript event handlers
  ↓
Application state
  ↓
DOM manipulation

With WebForms Core, the interaction can be expressed as server-defined commands:

Server
  ↓
WebForms
  ↓
WebForms Core commands
  ↓
WebFormsJS
  ↓
HTML DOM

The browser still performs the actual DOM operations, but the developer does not need to implement those operations as custom JavaScript code.

This is particularly useful for applications where interaction logic is already organized around server-side controls and commands.

No Custom JavaScript Required

The only JavaScript referenced by the page is the WebFormsJS executor:

<script type="module" src="/script/web-forms.js"></script>

There is no custom JavaScript file containing drag-and-drop handlers.

The HTML remains ordinary HTML, and the draggable elements use the standard draggable attribute:

<div class="dragitem" id="dragitem1" draggable="true">
    Drag me! 1
</div>

The interaction logic is defined entirely through the server-side WebForms API.

Conclusion

This example shows that Drag and Drop does not necessarily require a custom JavaScript implementation.

With WebForms Core, mouse-based Drag and Drop can be defined through standard HTML events and server-generated commands, while touch interaction can be handled through a separate OnTouchStart event.

The result is a server-orchestrated interaction where:

the server defines the behavior,
WebForms Core generates the commands,
WebFormsJS executes those commands,
and the browser performs the final DOM operations.

Most importantly, the developer does not have to write a JavaScript Drag and Drop implementation or maintain a separate client-side interaction layer.

If you have any questions, feel free to ask.
If you have any comments, please share them.
We will gladly answer!

No React, No Vue, No Angular: Explore the WebForms Core Demo Website in Action

Elanat Framework — Tue, 06 Oct 2026 22:05:44 +0000

The new WebForms Core Demo is now available:

https://webforms-core.github.io/demo

Explore WebForms Core through interactive examples and see how server-orchestrated UI works in practice.

The demo includes examples of:

Chart using an extension method
Custom DOM events
Value formatting
Server-driven rendering with Render
Interactive applications such as a Memory Tiles game

WebForms Core uses a Commander–Executor architecture. The WebForms class generates commands, and WebFormsJS executes them directly on the HTML DOM. The server is stateless, while routing and UI infrastructure are handled automatically, allowing developers to focus on writing the application logic.

No React. No Vue. No Angular. No JSX.

Just server-generated commands and direct DOM execution.

Try the demo now:
https://webforms-core.github.io/demo

Source code
https://github.com/webforms-core/demo

Have You Used WebForms Core? Share Your Experience

Elanat Framework — Tue, 06 Oct 2026 12:26:55 +0000

WebForms Core is launching on Product Hunt on October 7.

If you have already used WebForms Core, I’d really appreciate you sharing your experience and opinion when the launch goes live (October 7).

What did you like? What could be improved? How did you use it in your projects?

Your feedback as someone who has actually used WebForms Core is especially valuable.

WebForms Core on Product Hunt

WebForms Core 2.2 Released: Render, a New Approach to UI Rendering

Elanat Framework — Sun, 04 Oct 2026 12:59:10 +0000

WebForms Core is a modern, server-orchestrated technology for building interactive HTML user interfaces, introduced by Elanat in 2024. It enables direct and deterministic DOM management from the server, eliminating the need for separate client-side frameworks such as React, Vue, or Angular.

WebForms Core 2.2 has been released.

This release introduces several new capabilities, but one feature deserves special attention: Render.

Render is a high-level UI rendering primitive designed to make repeated server-side rendering of an existing HTML element predictable and manageable. It brings together several mechanisms that are all new in this version—Snapshot, Rollback, and Transient DOM—into a single high-level primitive.

The result is a simpler way to replace, rebuild, and restore parts of an HTML document while keeping the operation under server-side control.

Render

In this new version, Snapshot, Rollback, and Render are all new additions. Render is a high-level method that uses Snapshot and Rollback internally.

In WebForms Core 2.2, Render brings these operations together.

A simple example is:

form.Render(f =>
{
    f.Replace(InputPlace.Root, "{{name}}", name);
    f.Replace("-", "{{email}}", email);
    f.Replace("-", "{{phone}}", phone);
    f.Replace("-", "{{age}}", age);
    f.Replace("-", "{{city}}", city);
    f.Replace("-", "{{country}}", country);
}, "user");

The rendering process can also be used directly with a template:

var data = new Dictionary<string, string>
{
    { "name", name},
    { "email", email},
    { "phone", phone},
    { "age", age},
    { "city", city},
    { "country", country}
};
string json = JsonSerializer.Serialize(data);

form.Render(f =>
{
    f.BindJSONToTemplate(InputPlace.Root, json, "", "{{value}}");
}, "user");

The important part is not simply the number of lines saved by Render. The important part is that the lifecycle of the rendered element is handled as one operation.

Internally, Render checks whether a previous version of the selected element already exists. If it does, that version is restored. Otherwise, a Snapshot is created.

The rendering process then enters the Transient DOM, appends the generated WebForms commands, exits the Transient DOM, and appends the new form.

In simplified form:

Existing State
      ↓
Rollback or Snapshot
      ↓
Start Transient DOM
      ↓
Apply New Rendering
      ↓
End Transient DOM
      ↓
New UI State

This is particularly useful when the same element has to be rendered repeatedly with different data or templates.

Render and Transient DOM

Render uses the Transient DOM internally.

This is important when selecting InputPlace values inside the Render operation. The root of the selected InputPlace must be considered relative to the Transient DOM being processed.

Render is therefore not simply a shortcut for a sequence of unrelated commands. It creates a controlled rendering process in which the existing state and the new state can be handled together.

The implementation is:

// The Render Method is Sensitive to DOM Changes; It is Recommended to Assign a Stable ID to the Selected Element.
// This Method Utilizes the Transient DOM; Therefore, When Selecting InputPlaces, You Must Consider the Root of the Selected InputPlace Within the Method.
public WebForms Render(WebForms newForm, string InputPlace, string Key = "", bool Permanent = false)
{
    if (newForm == null)
        return this;

    string bodyData = newForm.GetWebFormsData();

    if (string.IsNullOrEmpty(bodyData))
        return this;

    if (string.IsNullOrEmpty(Key))
        Key = InputPlace;

    WebForms form = new WebForms();

    form.Exist(Permanent ? Fetch.Cache(Key) : Fetch.Save(Key));
        form.Rollback(InputPlace, Key, Permanent);
    form.Else();
        form.Snapshot(InputPlace, Key, Permanent);

    form.StartTransientDOM(InputPlace);

    AppendForm(form);
    newForm.EndTransientDOM();
    AppendForm(newForm);

    return this;
}

There is also a configuration-based overload:

public WebForms Render(
    System.Action<WebForms> configure,
    string InputPlace,
    string Key = "",
    bool Permanent = false)
{
    var newForm = new WebForms();
    configure(newForm);

    return Render(newForm, InputPlace, Key, Permanent);
}

This makes Render suitable for both manually constructed WebForms and dynamically configured rendering operations.

Snapshot and Rollback

Render is built on top of the Snapshot and Rollback mechanisms introduced in WebForms Core 2.2.

A Snapshot stores the state of a selected tag so that it can later be restored.

Consider a simple multilingual user template.

The page contains three buttons:

<input id="English" type="button" value="en-user">
<input id="Spanish" type="button" value="es-user">
<input id="Persian" type="button" value="fa-user">

<div id="user">
</div>

The templates are defined using HTML <template> elements:

<template id="en-user">
    <div id="user">
        <field>Name: {{name}}</field>
        <a href="mailto:{{email}}">Email: {{email}}</a>
        <field>Phone: {{phone}}</field>
        <field>Age: {{age}}</field>
        <field>City: {{city}}</field>
        <field>Country: {{country}}</field>
    </div>
</template>

<template id="es-user">
    <div id="user">
        <field>Nombre: {{name}}</field>
        <a href="mailto:{{email}}">Correo electrónico: {{email}}</a>
        <field>Teléfono: {{phone}}</field>
        <field>Edad: {{age}}</field>
        <field>Ciudad: {{city}}</field>
        <field>País: {{country}}</field>
    </div>
</template>

<template id="fa-user">
    <div id="user">
        <field>نام: {{name}}</field>
        <a href="mailto:{{email}}">ایمیل: {{email}}</a>
        <field>تلفن: {{phone}}</field>
        <field>سن: {{age}}</field>
        <field>شهر: {{city}}</field>
        <field>کشور: {{country}}</field>
    </div>
</template>

The WebForms code creates a Snapshot for each template:

using CodeBehind;

public partial class SnapshotAndRollbackController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        WebForms form = new WebForms();

        form.Snapshot("en-user");
        form.Snapshot("es-user");
        form.Snapshot("fa-user");

        form.SetCommentEvent(
            InputPlace.AllAttributes("type", "button"),
            HtmlEvent.OnClick,
            "set-state");

        form.StartIndex("set-state");

        form.Rollback("user", Fetch.GetValue("$"));

        form.Replace("user", "{{name}}", Fetch.GetValue("name"));
        form.Replace("user", "{{email}}", Fetch.GetValue("email"));
        form.Replace("user", "{{phone}}", Fetch.GetValue("phone"));
        form.Replace("user", "{{age}}", Fetch.GetValue("age"));
        form.Replace("user", "{{city}}", Fetch.GetValue("city"));
        form.Replace("user", "{{country}}", Fetch.GetValue("country"));

        Write(form.ExportToHtmlComment());
    }
}

When one of the buttons is clicked, the corresponding Snapshot is restored and the user data is inserted into the selected template.

The API itself is intentionally small:

public void Snapshot(
    string InputPlace,
    string Key = "",
    bool Permanent = false)

public void Rollback(
    string InputPlace,
    string Key = "",
    bool Permanent = false)

The Snapshot and Rollback mechanism is sensitive to DOM changes, so assigning a stable ID to the selected element is recommended.

Render uses these mechanisms automatically, so developers do not need to manually coordinate Snapshot and Rollback when using the high-level rendering API.

GetTagHash

WebForms Core 2.2 also introduces Fetch.GetTagHash.

It calculates a hash from the outerHTML of a tag.

form.SetCommentEvent(
    "GetHash",
    HtmlEvent.OnClick,
    "get-hash");

form.StartIndex("get-hash");
form.AddText("Text", "-a");
form.Message(Fetch.GetTagHash("Box"));

The hash is based only on the tag's outerHTML.

This makes it useful for detecting whether the DOM representation of a tag has changed.

Formatting Values with Regex

WebForms Core 2.2 adds:

SetFormatCacheValue
SetFormatSaveValue

These methods apply Regex-based formatting to values stored in Cache or Save.

For example, the following page contains a money value and a time value:

<button id="SetFormat">Click to Set Format</button>

<input type="text" id="Money" value="12345678">
<input type="text" id="Clock" value="15:1:3">

The WebForms code stores each value and applies a regular-expression replacement:

using CodeBehind;

public partial class SetFormatController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        WebForms form = new WebForms();

        form.SetCommentEvent(
            "SetFormat",
            HtmlEvent.OnClick,
            "set-format");

        form.StartIndex("set-format");

        form.SaveValue("Money", "money");
        form.SetFormatSaveValue(
            "money",
            "(\\d)(?=(\\d{3})+$)",
            "$$1,");

        form.SetValue("Money", Fetch.Save("money"));

        form.CacheValue("Clock", "clock");
        form.SetFormatCacheValue(
            "clock",
            "(^|:)(\\d)(?=:|$)",
            "$$10$2"); // Two $$ for escape JavaScript interpretation

        form.SetValue("Clock", Fetch.Cache("clock"));

        Write(form.ExportToHtmlComment());
    }
}

The first operation formats:

12345678

as:

12,345,678

The second transforms:

15:1:3

into:

15:01:03

The $$ in the replacement string is important because it escapes the $ for JavaScript interpretation.

This is also useful when formatting must happen as part of a larger WebForms operation, where the formatted value can then be applied back to the corresponding HTML element.

Arithmetic Operations

WebForms Core 2.2 adds arithmetic operations for values stored in Cache and Save.

The supported operations are:

+
-
*
/
%
//
**

The following example provides a button for each operation:

<button id="Addition">+</button>
<button id="Subtraction">-</button>
<button id="Multiplication">*</button>
<button id="Division">/</button>
<button id="Remainder">%</button>
<button id="FloorDivision">//</button>
<button id="Power">**</button>

<input type="text" id="Value1" value="10"> |
<input type="text" id="Value2" value="7">
=
<b id="Result"></b>

The WebForms code is:

using CodeBehind;

public partial class ArithmeticController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        WebForms form = new WebForms();

        form.SetCommentEvent(
            "<button>*",
            HtmlEvent.OnClick,
            "result");

        form.StartIndex("result");

        form.SaveValue("Value1", "result");

        form.SetArithmeticSaveValue(
            "result",
            Fetch.GetText("$"),
            Fetch.GetValue("Value2"));

        form.SetText(
            "Result",
            Fetch.Save("result"));

        Write(form.ExportToHtmlComment());
    }
}

The // operation is implemented in WebFormsJS as:

case "//":
    return Math.floor(a / b);

For example, with 10 and 7, / produces the normal division result, while // produces the floored result.

The operations allow common numerical transformations to be performed directly within the WebForms command flow.

Text Operations

WebForms Core 2.2 currently provides six text operations:

textafter
textafterlast
textbefore
textbeforelast
substring
remove

The example below provides a button for each operation:

<button>textafter</button>
<button>textafterlast</button>
<button>textbefore</button>
<button>textbeforelast</button>
<button>substring</button>
<button>remove</button>

<input type="text" id="Value1" value="This is a Hello World!"> |
<input type="text" id="Value2" value=""> |
<input type="text" id="Value3" value="">
=
<b id="Result"></b>

The WebForms implementation is:

using CodeBehind;

public partial class TextOperationController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        WebForms form = new WebForms();

        form.SetCommentEvent(
            "<button>*",
            HtmlEvent.OnClick,
            "result");

        form.StartIndex("result");

        form.SaveValue("Value1", "result");

        form.SetTextOperationSaveValue(
            "result",
            Fetch.GetText("$"),
            Fetch.GetValue("Value2"),
            Fetch.GetValue("Value3"));

        form.SetText(
            "Result",
            Fetch.Save("result"));

        Write(form.ExportToHtmlComment());
    }
}

The current set is intentionally compact. More text operations can be added in future versions based on developer feedback and practical use.

Regex-Based Element Selection

The Criteria system can use regular expressions to select elements.

Consider the following HTML:

<div id="Regex">
    <div>2026-10-01</div>
    <div>Adrian</div>
    <div>43</div>
    <div>00125478744</div>
    <div>Brazil</div>
</div>

The following commands select elements based on their text:

form.SetBackgroundColor(
    "Regex|*?t#\\d{4}-\\d{2}-\\d{2}$",
    "pink");

form.SetBackgroundColor(
    "Regex|*?t#^[0-9]+$",
    "brown");

The t criterion works with the text of the element, while # specifies a regular-expression comparison.

The first expression matches a date such as:

2026-10-01

The second matches text consisting entirely of digits, such as:

43
00125478744

The underlying WebFormsJS implementation uses JavaScript's RegExp:

case '#':
{
    let pattern = tmpValue;
    let flags = "";

    const m = pattern.match(/^\/([\s\S]+)\/([a-z]*)$/);

    if (m)
    {
        pattern = m[1];
        flags = m[2];
    }

    try
    {
        result = new RegExp(pattern, flags).test(text);
    }
    catch
    {
        result = false;
    }

    break;
}

This allows the Criteria system to perform more precise element selection without requiring a separate selector language.

JavaScript Objects from WebForms

A value beginning with $ in a WebForms class method can be interpreted by WebFormsJS as a JavaScript object reference.

This provides a direct way for server-generated commands to refer to objects that exist in the browser.

The distinction is important: the WebForms class generates the command, while WebFormsJS performs the corresponding client-side execution.

Try and Catch

WebForms Core 2.2 adds Try and Catch for explicit error handling.

For example:

form.Try();

form.AddTag("<h5>", "div");
form.SetText("<h5>|<>-1", "New tag!");
form.Message("New Tag Was Added!");

form.Catch();

form.Message("h5 Tag Not Exist 1!");
form.Message("h5 Tag Not Exist 2!");

If an Action Control inside Try encounters an error, execution stops and continues at Catch.

Without Try and Catch, there is no automatic recovery mechanism. The developer decides which operations may cause problems and places those operations inside an appropriate error-handling structure.

LockQueue

The queue behavior was changed in WebForms Core 2.2.

In the previous version, the queue was automatically locked. In 2.2, the queue is no longer automatically locked in that way.

The default duration is controlled by:

WebFormsOptions.QueueLockDuration = 100;

When a process needs additional protection, the developer can explicitly call:

form.LockQueue(10000);

LockQueue dynamically increases the lock duration for the current process and then restores the previous configured value automatically.

This is useful when a process must be allowed to complete before another queued process starts doing something else.

Native HTML Validation from the Server

WebForms Core 2.2 adds SetCustomValidity.

WebForms Core does not introduce a new validation framework.

Instead, it brings the browser's existing validation capability into the server-generated command model.

For example:

form.SetCommentEvent(
    "(name)",
    HtmlEvent.OnInput,
    "custom-validity");

form.StartIndex("custom-validity");

form.IsEqualTo("admin", Fetch.GetValue("$"));

form.SetCustomValidity(
    "$",
    "The username cannot be \"admin\".");

form.Else();

form.SetCustomValidity("$", "");

The browser's native Constraint Validation API remains responsible for the validation behavior.

The server determines the condition and sends the appropriate command to the HTML element.

Stable WebAssembly Support

WebForms Core 2.2 brings stable WebAssembly support across seven languages and environments:

AssemblyScript
C
C++
C#
Go
Java
Rust

Go and Rust provide WebAssembly targets directly, while AssemblyScript is designed specifically for WebAssembly.

For example, Go can be built with its native WebAssembly target:

@echo off

set GOOS=js
set GOARCH=wasm

go build -o webforms-go.wasm

for /f "delims=" %%i in ('go env GOROOT') do set GOROOT=%%i

copy "%GOROOT%\lib\wasm\wasm_exec.js" wasm_exec.js

pause

Rust can be built with the WebAssembly target and processed with wasm-bindgen:

cargo +stable-x86_64-pc-windows-gnu build --release --target wasm32-unknown-unknown

wasm-bindgen target/wasm32-unknown-unknown/release/webformscore_wasm_test.wasm --target web --out-dir pkg

The current implementations are:

AssemblyScript: WebAssembly
C: Emscripten
C++: Emscripten
C#: AOT and Runtime
Go: native WebAssembly support
Java: TeaVM
Rust: native WebAssembly support and wasm-bindgen

WebAssembly does not change the WebForms Core command model. It provides another execution environment while WebForms Core continues to generate WebForms responses and commands.

WebForms Classes Across 18 Programming Languages

WebForms Classes are now directly available for 18 programming languages, making WebForms Core accessible across a broad range of programming environments.

The collection includes AssemblyScript, C, C++, C#, Dart, Elixir, Go, Java, JavaScript, Julia, Perl, PHP, Python, R, Ruby, Rust, Swift, and TypeScript.

WebForms Core 2.2 is currently available for .NET and Java. The remaining language implementations will be updated to version 2.2 over the next 10 days.

This means the WebForms Classes ecosystem is not limited to a single backend language. Developers can use the same WebForms Core architecture and programming model across a wide range of languages and environments, while each implementation remains native to its own ecosystem.

Why WebForms Core Did Not Add Middleware

One of the hardest architectural decisions during the development of 2.2 was whether to introduce a generic Middleware structure into WebForms Core.

Technically, it was possible to build a very general Function-level Middleware system.

For example:

function A(x, y) {
    const result = Middleware.call(this, A, B, arguments);

    if (result !== undefined)
        return result;

    return x * y;
}

function B(x, y) {
    return [2, 20];
}

function Middleware(method, middleware, args) {
    if (!(this.__middleware ??= []).includes(method.name)) {
        this.__middleware.push(method.name);

        const newArgs = middleware.apply(this, args);
        const result = method.apply(this, newArgs);

        this.__middleware.splice(
            this.__middleware.indexOf(method.name),
            1);

        return result;
    }
}

Such a system could do much more than a conventional Middleware implementation. It could change arguments, stop execution, and execute the original function again with new arguments.

But there was a problem.

Adding this abstraction to WebFormsJS would make the core considerably more complicated. Lifecycle management, recursion, execution order, argument changes, and the different paths through which Functions are executed would all have to be managed.

In the end, we decided not to add it.

Instead, when a requirement is genuinely specific to client-side processing, a JavaScript Module is a better place for that logic.

For example, if form data needs to be reduced or modified before submission, a JavaScript Module can perform that operation directly without adding a generic Middleware layer to WebFormsJS.

This decision is not a statement that Middleware is impossible in WebForms Core.

It is an architectural decision to keep the core smaller and move client-specific behavior into JavaScript Modules.

Other Changes

WebForms Core 2.2 also includes several smaller improvements and fixes.

Reflection renamed to Reflect

The Reflection method has been renamed to:

Reflect

Debugger numbering

Debugger logs now include numbering, making it easier to follow the execution sequence of generated Action Controls.

JavaScript Object escaping

An escaping issue involving JavaScript Objects containing two consecutive $ characters was fixed.

WebForms Core 2.1.1 and 2.1.2

The 2.1.x maintenance releases also included several changes that lead into the 2.2 release:

Fixed the hash-link behavior so hash links no longer create an unnecessary server request.
Added the Modulo Filter to Criteria.
Fixed Replace behavior for values stored in Save and Cache.
Added Fetch support in InputPlace.
Removed CSharpMediator.
CSharpWASM can infer the JavaScript file path from the WASM file path.
CSharpWASM supports both CLI and AOT.
Rust WASM can be built through wasm-bindgen or directly as WebAssembly.

Final Thoughts

WebForms Core 2.2 is not simply a collection of additional methods.

The most important change is the introduction of higher-level operations that allow developers to describe what should happen to a UI without manually coordinating every underlying step.

Render is the clearest example.

Snapshot, Rollback, and Transient DOM already provided the mechanisms needed to manage complex DOM transformations. Render combines those mechanisms into a single operation that can manage the transition from an existing UI state to a new one.

At the same time, 2.2 keeps the underlying system explicit.

Native browser validation remains native browser validation. Client-specific processing can remain in JavaScript Modules. WebAssembly provides additional execution environments without changing the WebForms Core command model. Queue locking is explicit when a process actually needs it.

The result is a more capable WebForms Core without turning the core itself into a larger collection of abstractions.

Java WebAssembly Meets WebForms Core 2.2

Elanat Framework — Sat, 03 Oct 2026 20:24:15 +0000

WebAssembly allows applications written in languages other than JavaScript to execute directly in the browser. With WebForms Core 2.2, Java can also be used as a WebAssembly Commander and generate WebForms commands that are executed by WebFormsJS.

For Java, WebForms Core currently supports TeaVM as its supported WebAssembly compiler.

The architecture is straightforward:

Java
 ↓
TeaVM
 ↓
WebAssembly
 ↓
WebForms Core
 ↓
WebFormsJS
 ↓
HTML DOM

The important point is that Java does not manipulate the browser DOM directly. The Java code generates a WebForms response, and WebFormsJS executes that response in the browser.

Java WebAssembly with TeaVM

TeaVM compiles Java bytecode to WebAssembly. WebForms Core can use the resulting WebAssembly module as a Commander.

For this example, the Java WebForms Classes package is used:

<dependency>
    <groupId>net.elanat</groupId>
    <artifactId>WFC</artifactId>
    <version>2.2.0</version>
</dependency>

The Java class contains three methods:

package com.example.demo;

import org.teavm.jso.JSExport;
import webformscore.WebForms;

public class MyClass
{
    @JSExport
    public static int Add(int a, int b)
    {
        return a + b;
    }

    @JSExport
    public static String SetData(
        String inputPlace,
        String text,
        String backgroundColor,
        String fontSize)
    {
        WebForms form = new WebForms();

        form.setText(inputPlace, text);
        form.setBackgroundColor("-", backgroundColor);
        form.setFontSize("-", fontSize);

        return form.response();
    }

    @JSExport
    public static String GetHtml()
    {
        return "<marquee>Tag From Wasm!</marquee>";
    }
}

The Add method returns a normal Java value.

The SetData method uses the WebForms Class to generate WebForms commands. The Java code does not need to know anything about the browser DOM.

GetHtml simply returns an HTML fragment.

Compiling Java to WebAssembly

TeaVM can generate WebAssembly GC output for the Java application.

The important configuration is:

<configuration>
    <mainClass>com.example.demo.MyClass</mainClass>
    <targetType>WEBASSEMBLY_GC</targetType>
    <optimizationLevel>FULL</optimizationLevel>
</configuration>

The resulting WebAssembly module can then be used by WebForms Core.

For example:

/web-assembly/java/tea_vm/classes.wasm

TeaVM can also generate its runtime JavaScript:

/web-assembly/java/tea_vm/classes.wasm-runtime.js

WebForms Core can accept either form.

Using Java WebAssembly from CodeBehind

The CodeBehind controller defines the WebAssembly path and uses the WebForms Core WASM API.

using CodeBehind;

public partial class WasmJavaController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        string WasmPath = "/web-assembly/java/tea_vm/classes.wasm"; // Using TeaVM
        //string WasmPath = "/web-assembly/java/tea_vm/classes.wasm-runtime.js"; // Using TeaVM

        WebForms form = new WebForms();

        form.AddText("<b>", Fetch.WasmMethod(WasmLanguage.JAVA, WasmPath, "Add", [10000, 3]));

        form.SetWasmEvent("WasmEvent", HtmlEvent.OnClick, WasmLanguage.JAVA, WasmPath, "SetData", ["h3Tag", "Text From Wasm", "lightgreen", "30px"]);
        form.SetWasmEvent("WasmEventWithOutput", HtmlEvent.OnClick, WasmLanguage.JAVA, WasmPath, "GetHtml", [], "WasmHtmlOutput");

        Write(form.ExportToHtmlComment());
    }
}

The first call executes Add and places its result in the generated WebForms response:

form.AddText("<b>", Fetch.WasmMethod(
    WasmLanguage.JAVA,
    WasmPath,
    "Add",
    [10000, 3]));

The result is therefore produced by Java WebAssembly.

The next command connects a browser event to the Java WebAssembly method:

form.SetWasmEvent(
    "WasmEvent",
    HtmlEvent.OnClick,
    WasmLanguage.JAVA,
    WasmPath,
    "SetData",
    ["h3Tag", "Text From Wasm", "lightgreen", "30px"]);

When the button is clicked, WebForms Core executes the Java method and applies its WebForms response.

The third example sends the returned HTML to a specific element:

form.SetWasmEvent(
    "WasmEventWithOutput",
    HtmlEvent.OnClick,
    WasmLanguage.JAVA,
    WasmPath,
    "GetHtml",
    [],
    "WasmHtmlOutput");

HTML

The page remains ordinary HTML:

@page
@controller WasmJavaController
@layout "/layout.aspx"
@{
  ViewData.Add("title","Java Wasm");
}
<h3>Java Wasm</h3>
<b>Java WASM Result: </b>
<br>
<button id="WasmEvent">Wasm Event</button>
<br>
<h3 id="h3Tag">Wasm Tag Changing!</h3>
<button id="WasmEventWithOutput">Wasm Event With Output</button>
<p id="WasmHtmlOutput">Wasm Html Output</p>

There is no additional WebForms-specific markup in the HTML.

WebForms Core generates its commands on the server:

Server
  ↓
CodeBehind
  ↓
WebForms
  ↓
WebAssembly command
  ↓
WebFormsJS
  ↓
HTML DOM

This keeps the browser side lightweight and allows the Java WebAssembly code to remain a Commander rather than becoming a separate frontend framework.

What about Bytecoder?

Bytecoder was also tested as a possible Java-to-WebAssembly compiler for WebForms Core.

The problem was not the WebForms Core API itself.

The unchanged WebForms Classes implementation contains:

public void setText(String inputPlace, String text)
{
    add("st" + inputPlace, text.replace("\n", "$[ln];"));
}

Bytecoder's compiler failed while analyzing this existing method and reported:

No such method :
java/lang/String.replace
(Ljava/lang/CharSequence;Ljava/lang/CharSequence;)Ljava/lang/String;

Interestingly, the Bytecoder Java class library itself contains the corresponding String.replace(CharSequence, CharSequence) method. The problem occurred in Bytecoder's compiler/analyzer when resolving the method used by the existing WFC code.

Therefore, the WFC implementation was not changed to accommodate Bytecoder.

This is important because WebForms Core should not have to change its Java API simply to satisfy a particular compiler backend.

Bytecoder therefore remains an experimental option for Java WebAssembly with WFC rather than the supported route.

What about CheerpJ?

CheerpJ takes a different approach.

Unlike TeaVM, CheerpJ is not primarily producing a standalone Java-specific .wasm module together with a generated JavaScript wrapper in the way expected by WebForms Core's WASM model.

CheerpJ provides a WebAssembly-based Java runtime and executes Java bytecode/JAR files through that runtime.

The model is closer to:

Java JAR
   ↓
CheerpJ Runtime
   ↓
WebAssembly
   ↓
Browser

rather than:

Java
   ↓
Java → WASM compiler
   ↓
Standalone WASM module
   ↓
WebForms Core

CheerpJ therefore follows its own execution model and does not produce the JavaScript/WASM artifact structure expected by the current WebForms Core WASM integration.

This makes CheerpJ interesting as a Java-in-the-browser technology, but it is architecturally different from the WebAssembly Commander model used by WebForms Core.

For this reason, TeaVM is currently the Java WebAssembly implementation supported by WebForms Core.

Why TeaVM?

The important requirement for WebForms Core is not simply that Java can execute in a browser.

The requirement is that Java can act as a WebAssembly Commander:

Java Method
    ↓
WebForms Class
    ↓
WebForms Response
    ↓
WebFormsJS
    ↓
DOM

TeaVM fits this model directly because it produces WebAssembly that can be loaded and invoked by the WebForms Core WASM infrastructure.

The Java code can therefore use the same WebForms Classes API used by other languages.

Conclusion

Java can be used with WebForms Core 2.2 as a WebAssembly Commander through TeaVM.

The resulting architecture is:

             Java
               │
               ▼
             TeaVM
               │
               ▼
         WebAssembly
               │
               ▼
        WebForms Core
               │
               ▼
          WebFormsJS
               │
               ▼
           HTML DOM

The Java application does not need a separate JavaScript frontend.

It generates WebForms commands, and WebFormsJS executes those commands in the browser.

At present, TeaVM is the supported Java WebAssembly path for WebForms Core. Bytecoder has a compiler compatibility problem with existing WFC Java code, while CheerpJ follows a different runtime/JAR-oriented architecture instead of the standalone WebAssembly module model used by WFC.

CodeBehind 4.8 Released

Elanat Framework — Sat, 03 Oct 2026 13:01:02 +0000

CodeBehind

CodeBehind is a server-side web framework for .NET that enables developers to build dynamic web applications using C# and standard web technologies. It provides a structured approach to server-side page development while supporting modern web application architectures.

What's New in CodeBehind 4.8

CodeBehind 4.8 includes WebForms Core 2.2, bringing the latest WebForms Core features and improvements to CodeBehind applications.

In WebForms Core 2.2, Render, Snapshot, and Rollback are new structural rendering primitives.

Snapshot captures the current HTML structure of a target element and stores it as a stable rendering base under a specified key. Rollback restores the target to a previously captured snapshot before further commands are applied, preventing repeated renders from accumulating stale attributes or values.

Render is a higher-level rendering operation built on these two primitives and TransientDom. It checks whether a rendering base already exists, restores it with Rollback or creates it with Snapshot, then opens an isolated transient DOM scope on a clone of the target. The supplied WebForms commands are applied within that scope, after which the modified clone replaces the original target in a single DOM operation.

This allows repeated renders to start from a known structural state while remaining isolated, predictable, and repeatable, without using a virtual DOM.

We will introduce the new features of WebForms Core 2.2 in detail in a separate article soon.

From this version onward, the minified version of WebFormsJS is included in the CodeBehind framework.

The web-forms.min.js file is also added to the initial CodeBehind template by default.

The `Control` Method Has Been Removed

The Control method has been completely removed.

The web_forms_view_place option has also been removed.

The use_comment_mode_for_web_forms_combinate option has also been removed.

The options structure has been redesigned to provide more reliable behavior when options are removed or renamed.

After a successful update, an outdate section will be added to the end of the options file after a blank line. This section is no longer associated with the active options and has no effect on CodeBehind functionality.

For example:

;outdate
web_forms_view_place=<body>
use_comment_mode_for_web_forms_combinate=false

Going forward, use Write(form.ExportToHtmlComment()) instead of Control(form) when sending WebForms commands that include HTML.

For secondary commands that do not include HTML, use Write(form.Response()) together with IgnoreAll(). The IgnoreAll() method prevents the view and layout from being rendered.

Why Was the `Control` Method Removed?

There were two main reasons:

Performance improvement: Although the overhead was minimal, the Control method introduced additional processing on every request. Removing it eliminates this unnecessary overhead and improves the overall performance of the CodeBehind framework.
Standardization of the WebForms class: The WebForms class is available across a wide range of programming languages. The Control method introduced a language-specific syntactical pattern that was inconsistent with the design of the WebForms class across different implementations. Removing it provides a more consistent and standardized API across languages.

How to Update CodeBehind on Active Systems

To update to the new version, first replace the existing CodeBehind.dll with the latest version. Also replace or add your application's DLL, ASPX, and other required files as needed.

Then, it is recommended to systematically execute the following method from one of your admin paths:

SetCodeBehind.CodeBehindCompiler.ReCompile();

If you cannot execute this method systematically for any reason, delete the following files from your web server or hosting environment:

CodeBehindLastSuccessCompiled.dll.tmp
code_behind/views_class.cs.tmp

Then disable and re-enable your system on the web server or hosting environment.

Development Configuration

When developing a CodeBehind application on your local system, it is recommended to use the following configuration:

builder.Services.AddCodeBehind(!builder.Environment.IsDevelopment());

This configuration automatically determines whether the application is running in development mode or in its final production environment on the web server.

Installation and Requirements

CodeBehind is available as a NuGet package for ASP.NET Core applications.

Install CodeBehind using the .NET CLI:

dotnet add package CodeBehind

Or add it directly to the project file:

<PackageReference Include="CodeBehind" />

CodeBehind requires ASP.NET Core and a supported version of .NET (Version 10). For the exact supported target frameworks and package requirements, see the CodeBehind Package on NuGet.

After installing the package, configure CodeBehind in Program.cs:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCodeBehind(!builder.Environment.IsDevelopment());

var app = builder.Build();

app.UseCodeBehind();    // UseCodeBehindAsync() for asynchronous execution
                        // UseCodeBehindNextNotFound() to continue if the page is not found

app.Run();

C/C++ Experience with WebForms Core from Elanat

Elanat Framework — Thu, 01 Oct 2026 18:09:17 +0000

WebAssembly makes it possible to bring languages such as C and C++ into web applications without rewriting their core logic in JavaScript.

In this article, I explore using C and C++ with WebForms Core, a server-side UI manipulation technology from Elanat. The goal is not to use C or C++ to manipulate the browser DOM directly. Instead, the C or C++ code uses the WebForms Core API to generate WebForms Core responses, which are then executed in the browser by WebFormsJS.

The resulting architecture is:

C / C++
   ↓
Emscripten
   ↓
WebAssembly
   ↓
WebForms Core
   ↓
WebFormsJS
   ↓
HTML DOM

This approach allows C and C++ code to participate in the WebForms Core Commander architecture while keeping DOM execution on the client side.

WebForms Core and WebAssembly

WebForms Core separates UI command generation from UI execution.

The application generates WebForms Core commands, while WebFormsJS executes those commands against the HTML DOM.

A WebAssembly module can therefore act as a WebForms Core Commander.

Instead of calling JavaScript APIs such as:

document.getElementById("result").textContent = "Hello";

the C or C++ code can generate a WebForms Core response such as a command that changes the text of an HTML element.

The browser then receives and executes that response through WebFormsJS.

This distinction is important because the WebAssembly module does not need to know how the DOM is implemented or manipulate it directly.

WebForms Core Implementations

WebForms Core provides implementations for multiple programming languages.

The installation method depends on the language.

C in GitHub

WebForms Core C implementation

The C implementation is provided as a single WebForms.h file.

Get the file directly from the c directory and include it in the project:

#include "WebForms.h"

C++ in GitHub

WebForms Core C++ implementation

The C++ implementation is also provided as a single WebForms.h file.

Get the file directly from the cpp directory and include it in the project:

#include "WebForms.h"

The WebForms.h File

For C and C++, WebForms.h is the main WebForms Core interface.

It provides the functions and classes required to create WebForms Core responses.

The important point is that WebForms.h is not a browser-side DOM library. It does not provide functions such as document.querySelector() or element.innerHTML.

Instead, it provides the WebForms Core programming interface for generating commands.

For example, the C API can create a WebForms instance:

WebForms* form = webforms_create();

Commands can then be added to the response:

webforms_set_text(form, inputPlace, text);
webforms_set_background_color(form, "-", backgroundColor);
webforms_set_font_size(form, "-", fontSize);

Finally, the generated response is obtained:

char* response = webforms_response(form);

After the response has been generated, the WebForms instance can be cleaned up:

webforms_clean(form);
webforms_free(form);

The C++ API provides the same WebForms Core concept through a native C++ class:

WebForms form;

form.SetText(inputPlace, text);
form.SetBackgroundColor("-", backgroundColor);
form.SetFontSize("-", fontSize);

string response = form.Response();

Therefore, the role of WebForms.h can be summarized as:

C / C++
   ↓
WebForms.h
   ↓
WebForms Core Response
   ↓
WebFormsJS
   ↓
HTML DOM

C with WebForms Core

The first experiment uses C.

The following example exports three functions:

#include <stdbool.h>
#include <stdlib.h>
#include <string.h>

#include <emscripten/emscripten.h>

#include "WebForms.h"

EMSCRIPTEN_KEEPALIVE
int add(int a, int b)
{
    return a + b;
}

EMSCRIPTEN_KEEPALIVE
const char* set_data(
    const char* inputPlace,
    const char* text,
    const char* backgroundColor,
    const char* fontSize)
{
    static char* response = NULL;

    WebForms* form = webforms_create();

    if (!form)
        return NULL;

    webforms_set_text(form, inputPlace, text);
    webforms_set_background_color(form, "-", backgroundColor);
    webforms_set_font_size(form, "-", fontSize);

    if (response)
        free(response);

    response = webforms_response(form);

    webforms_clean(form);
    webforms_free(form);

    return response;
}

EMSCRIPTEN_KEEPALIVE
const char* get_html()
{
    return "<marquee>Tag From Wasm!</marquee>";
}

The add function is a simple numeric function.

The set_data function demonstrates the more interesting WebForms Core scenario. It receives data from JavaScript, creates a WebForms Core instance, generates several UI commands, and returns the resulting WebForms Core response.

The get_html function demonstrates that a WebAssembly method can also return HTML when that is appropriate for the application.

Compiling the C Code

Emscripten can compile the C source into WebAssembly:

upstream\emscripten\emcc.exe main.c -o main.html -sEXPORTED_RUNTIME_METHODS=ccall

The compilation produces files such as:

main.html
main.js
main.wasm

The important file for the WebAssembly runtime is main.wasm, while the generated JavaScript provides the Emscripten runtime and JavaScript interface.

Calling C WebAssembly from WebForms Core

WebForms Core provides WebAssembly method invocation through its WASM integration.

For example, a backend application can define a WebForms Core action that calls a WebAssembly method:

Fetch.WasmMethod(
    WasmLanguage.CPP,
    "/wasm/main.wasm",
    "set_data",
    InputPlace.Root,
    name,
    backgroundColor,
    fontSize
);

The returned WebForms Core response can then be executed by WebFormsJS.

The WebAssembly function itself does not need to know about the browser DOM.

The complete flow is:

Browser
   ↓
WebForms Core request
   ↓
Backend
   ↓
C WebAssembly
   ↓
WebForms Core response
   ↓
WebFormsJS
   ↓
HTML DOM

Setting a WebAssembly Event

A WebAssembly method can also be associated with a WebForms Core event.

For example:

SetWasmEvent(
    WasmLanguage.CPP,
    "btn_SetBodyValue",
    "click",
    "/wasm/main.wasm",
    "set_data"
);

This allows the WebAssembly function to participate in the WebForms Core event model rather than requiring custom JavaScript event handlers.

C++ with WebForms Core

The C++ implementation uses the same WebForms Core concept but exposes a native C++ interface.

#include <string>

#include <emscripten/emscripten.h>

#include "WebForms.h"

using namespace std;
using namespace WebFormsCore;

extern "C"
{
    EMSCRIPTEN_KEEPALIVE
    int Add(int a, int b)
    {
        return a + b;
    }

    EMSCRIPTEN_KEEPALIVE
    const char* SetData(
        const char* inputPlace,
        const char* text,
        const char* backgroundColor,
        const char* fontSize)
    {
        static std::string response;

        WebForms form;

        form.SetText(inputPlace, text);
        form.SetBackgroundColor("-", backgroundColor);
        form.SetFontSize("-", fontSize);

        response = form.Response();

        return response.c_str();
    }

    EMSCRIPTEN_KEEPALIVE
    const char* GetHtml()
    {
        return "<marquee>Tag From Wasm!</marquee>";
    }
}

The C++ version uses the WebForms class directly:

WebForms form;

Commands are then added through class methods:

form.SetText(inputPlace, text);
form.SetBackgroundColor("-", backgroundColor);
form.SetFontSize("-", fontSize);

The final response is generated with:

response = form.Response();

The response is stored in a static std::string because returning c_str() from a temporary or local string would leave an invalid pointer after the function returns.

Compiling C++

The C++ source can be compiled with Emscripten using em++:

upstream\emscripten\em++.exe main.cpp -o main.html -sEXPORTED_RUNTIME_METHODS=ccall

As with the C version, Emscripten produces the JavaScript and WebAssembly files required by the browser.

C and C++ API Comparison

The two implementations expose the same WebForms Core concept using language-specific APIs.

Operation	C	C++
Create	`webforms_create()`	`WebForms form;`
Set text	`webforms_set_text()`	`SetText()`
Set background	`webforms_set_background_color()`	`SetBackgroundColor()`
Set font size	`webforms_set_font_size()`	`SetFontSize()`
Generate response	`webforms_response()`	`Response()`
Cleanup	`webforms_clean()` / `webforms_free()`	Automatic object lifetime

The difference is primarily the programming interface.

The generated WebForms Core response follows the same architecture in both cases.

Automatic WebAssembly Method Arguments

One useful part of the WebForms Core WebAssembly integration is that method arguments can be passed from JavaScript based on their JavaScript types.

For example:

Add(10, 20)

passes numeric arguments, while:

SetData("~form", "Hello", "red", "18px")

passes string arguments.

The C/C++ Emscripten loader can determine the argument types from the JavaScript values:

const argTypes = args.map(arg =>
    typeof arg === "string" ? "string" : "number"
);

For the current C/C++ WebAssembly methods, this allows calls to be made without manually writing a separate signature for every method.

WebAssembly as a WebForms Core Commander

This experiment demonstrates an important aspect of the WebForms Core architecture.

WebAssembly does not have to be treated as a replacement for JavaScript DOM manipulation.

Instead, it can become another environment for generating WebForms Core commands.

The architecture can therefore be represented as:

                 WebForms Core
                       │
             ┌─────────┴─────────┐
             ↓                   ↓
        Server Code          WebAssembly
                                 │
                         ┌───────┴───────┐
                         ↓               ↓
                         C              C++
                         │               │
                         └───────┬───────┘
                                 ↓
                         WebForms Response
                                 ↓
                            WebFormsJS
                                 ↓
                              HTML DOM

The key point is that C and C++ do not need to directly control the browser DOM.

They generate WebForms Core commands, and WebFormsJS performs the client-side execution.

C with Mongoose

The same C WebForms Core implementation can also be used in a native C web server.

For example, Mongoose can receive an HTTP request, execute C code, generate a WebForms Core response, and return it to the browser.

The architecture becomes:

Browser
   ↓
HTTP
   ↓
Mongoose
   ↓
C Application
   ↓
WebForms Core
   ↓
WebForms Core Response
   ↓
WebFormsJS
   ↓
HTML DOM

This demonstrates that WebForms.h is not tied specifically to WebAssembly.

The same C WebForms Core implementation can be used in native C applications and in C WebAssembly applications.

Conclusion

Using C and C++ with WebForms Core provides another way to bring native-language code into web UI workflows.

The important part of this experiment is not simply compiling C or C++ into WebAssembly. The more interesting part is combining WebAssembly with the WebForms Core Commander architecture.

C and C++ generate WebForms Core responses through WebForms.h.

Emscripten compiles the code to WebAssembly.

WebForms Core provides the communication and command model.

WebFormsJS executes those commands in the browser.

The resulting architecture remains:

C / C++
   ↓
Emscripten
   ↓
WebAssembly
   ↓
WebForms Core
   ↓
WebFormsJS
   ↓
HTML DOM

This makes C and C++ another practical environment for building WebForms Core functionality while keeping the browser-side execution model consistent.

HTML5 Validation in WebForms Core 2.1

Elanat Framework — Wed, 30 Sep 2026 12:47:13 +0000

WebForms Core 2.1 introduces improved control over HTML5 form validation messages.

HTML already provides a powerful built-in validation system. Attributes such as required, minlength, maxlength, min, max, pattern, and input types such as email, url, and number allow browsers to validate user input automatically.

However, the default validation messages are controlled by the browser and may vary between browsers and languages. This can make it difficult to provide a consistent validation experience, especially when an application needs custom messages or supports multiple languages.

WebForms Core 2.1 extends this model by allowing validation messages to be configured dynamically through WebFormsJS options.

Configuring Validation Messages

The following example changes the messages used for different HTML5 validation states:

using CodeBehind;

public partial class ValidityController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        WebForms form = new WebForms();

        form.ChangeOption("ValidityValueMissing", "لطفاً این فیلد را تکمیل کنید");
        form.ChangeOption("ValidityTypeMismatch", "لطفاً یک مقدار معتبر وارد کنید");
        form.ChangeOption("ValidityPatternMismatch", "لطفاً مقدار را با قالب صحیح وارد کنید");
        form.ChangeOption("ValidityTooLong", "لطفاً حداکثر {{maxLength}} کاراکتر وارد کنید (در حال حاضر {{valueLength}} کاراکتر وارد شده است).");
        form.ChangeOption("ValidityTooShort", "لطفاً حداقل {{minLength}} کاراکتر وارد کنید (در حال حاضر {{valueLength}} کاراکتر وارد شده است).");
        form.ChangeOption("ValidityRangeUnderflow", "مقدار باید بزرگ‌تر یا مساوی {{min}} باشد.");
        form.ChangeOption("ValidityRangeOverflow", "مقدار باید کوچک‌تر یا مساوی {{max}} باشد.");
        form.ChangeOption("ValidityStepMismatch", "مقدار واردشده با گام مجاز سازگار نیست");
        form.ChangeOption("ValidityBadInput", "لطفاً یک مقدار معتبر وارد کنید");
        form.ChangeOption("ValidityCustomError", "مقدار واردشده معتبر نیست");

        Write(form.ExportToHtmlComment());
    }
}

The ChangeOption method allows WebForms Core to change WebFormsJS options dynamically.

This means validation behavior and messages do not necessarily need to be permanently configured in the JavaScript source. They can be configured through WebForms Action Controls and changed dynamically during application execution.

Supported Validation States

WebForms Core 2.1 provides configurable messages for the standard HTML5 validation states.

Value Missing

ValidityValueMissing is used when a required field has not been completed.

form.ChangeOption(
    "ValidityValueMissing",
    "لطفاً این فیلد را تکمیل کنید"
);

For example:

<input type="text" name="name" required>

If the user submits the form without entering a value, WebForms Core can display the configured message.

Type Mismatch

ValidityTypeMismatch is used when the entered value does not match the expected input type.

form.ChangeOption(
    "ValidityTypeMismatch",
    "لطفاً یک مقدار معتبر وارد کنید"
);

For example:

<input type="email" name="email" required>

or:

<input type="url" name="website">

An invalid email address or URL can trigger this validation state.

Pattern Mismatch

ValidityPatternMismatch is used when a value does not match the pattern specified by the pattern attribute.

form.ChangeOption(
    "ValidityPatternMismatch",
    "لطفاً مقدار را با قالب صحیح وارد کنید"
);

For example:

<input
    type="tel"
    name="phone"
    pattern="[0-9]{10,15}"
    placeholder="09123456789">

A provided value must match the specified pattern to pass pattern validation.

Dynamic Validation Values

Some validation messages can contain dynamic placeholders.

For example:

form.ChangeOption(
    "ValidityTooShort",
    "لطفاً حداقل {{minLength}} کاراکتر وارد کنید (در حال حاضر {{valueLength}} کاراکتر وارد شده است)."
);

The placeholders are replaced with the relevant validation values.

Minimum Length

<input
    type="text"
    name="name"
    required
    minlength="3">

If the entered value is shorter than the required minimum length, the message can use:

{{minLength}}
{{valueLength}}

to show both the required length and the current length.

For example, the resulting message could indicate that the field requires at least 3 characters while the user has entered fewer characters.

Maximum Length

The same approach can be used for maximum length validation:

form.ChangeOption(
    "ValidityTooLong",
    "لطفاً حداکثر {{maxLength}} کاراکتر وارد کنید (در حال حاضر {{valueLength}} کاراکتر وارد شده است)."
);

The available placeholders allow validation messages to contain information directly related to the current input.

Numeric Range Validation

WebForms Core also supports custom messages for numeric range validation.

Range Underflow

form.ChangeOption(
    "ValidityRangeUnderflow",
    "مقدار باید بزرگ‌تر یا مساوی {{min}} باشد."
);

Range Overflow

form.ChangeOption(
    "ValidityRangeOverflow",
    "مقدار باید کوچک‌تر یا مساوی {{max}} باشد."
);

Consider the following input:

<input
    type="number"
    name="age"
    min="18"
    max="100"
    required>

If the user enters a value below 18, the range-underflow message is used.

If the user enters a value above 100, the range-overflow message is used.

The {{min}} and {{max}} placeholders make it possible to create reusable validation messages without manually writing the allowed range for every field.

Step Mismatch

HTML5 inputs can also define allowed value increments using the step attribute.

WebForms Core 2.1 provides the following configurable message:

form.ChangeOption(
    "ValidityStepMismatch",
    "مقدار واردشده با گام مجاز سازگار نیست"
);

This message is used when the entered value does not match the allowed step configuration.

Bad Input and Custom Errors

Two additional HTML5 validation states can also be configured:

form.ChangeOption(
    "ValidityBadInput",
    "لطفاً یک مقدار معتبر وارد کنید"
);

form.ChangeOption(
    "ValidityCustomError",
    "مقدار واردشده معتبر نیست"
);

ValidityCustomError is used when a custom validation error has been set for an input.

A Complete HTML5 Validation Example

The following form uses several different HTML5 validation mechanisms:

<form>
    <h2>HTML5 Validation Test</h2>

    <label>
        Name:
        <input type="text" name="name" required minlength="3">
    </label>
    <br><br>

    <label>
        Email:
        <input type="email" name="email" required>
    </label>
    <br><br>

    <label>
        Password:
        <input type="password" name="password" required minlength="8">
    </label>
    <br><br>

    <label>
        Age:
        <input type="number" name="age" min="18" max="100" required>
    </label>
    <br><br>

    <label>
        Website:
        <input type="url" name="website" placeholder="https://example.com">
    </label>
    <br><br>

    <label>
        Phone:
        <input 
            type="tel" 
            name="phone" 
            pattern="[0-9]{10,15}"
            placeholder="09123456789">
    </label>
    <br><br>

    <label>
        Date:
        <input type="date" name="date" required>
    </label>
    <br><br>

    <label>
        Gender:
        <select name="gender" required>
            <option value="">-- Select --</option>
            <option value="male">Male</option>
            <option value="female">Female</option>
            <option value="other">Other</option>
        </select>
    </label>
    <br><br>

    <label>
        Country:
        <select name="country">
            <option value="az">Azerbaijan</option>
            <option value="ir">Iran</option>
            <option value="tr">Turkey</option>
        </select>
    </label>
    <br><br>

    <label>
        <input type="checkbox" name="terms" required>
        I accept terms
    </label>
    <br><br>

    <label>
        Comment:
        <textarea name="comment" required minlength="10"></textarea>
    </label>
    <br><br>

    <button type="submit">Submit</button>
</form>

This single form demonstrates multiple validation states:

Required text fields
Minimum-length validation
Email validation
Password validation
Numeric minimum and maximum ranges
URL validation
Pattern validation
Required date selection
Required <select> elements
Required checkboxes
Textarea validation

The important point is that the HTML itself continues to define the validation rules.

WebForms Core does not require developers to replace HTML5 validation attributes with a separate validation system. Instead, WebForms Core 2.1 works alongside the browser's native validation system and provides control over the messages presented to the user.

Dynamic Validation Configuration

Because validation messages are configured through ChangeOption, they can also be changed dynamically.

For example, an application could load different validation messages depending on:

The selected application language
The current user preferences
Different sections of an application
Runtime configuration

The configuration is not limited to a single hard-coded language.

WebForms form = new WebForms();

form.ChangeOption(
    "ValidityValueMissing",
    "Please complete this field"
);

form.ChangeOption(
    "ValidityTypeMismatch",
    "Please enter a valid value"
);

Write(form.ExportToHtmlComment());

Another page or runtime operation could change those messages again.

This makes the validation system particularly useful for applications that need dynamic localization.

Combining Native HTML Validation with WebForms Core

One of the advantages of this approach is that validation rules remain close to the HTML elements that use them.

<input
    type="number"
    min="18"
    max="100"
    required>

The HTML defines:

The type of value
The minimum value
The maximum value
Whether the field is required

WebForms Core then provides an additional layer for controlling how validation feedback is presented.

This creates a separation between:

Validation rules

required
minlength="3"
min="18"
max="100"
pattern="[0-9]{10,15}"

and:

Validation messages

form.ChangeOption(...);

The result is a flexible model where the browser continues to perform standard HTML5 validation while WebForms Core provides centralized and dynamically configurable validation messaging.

Validation in WebForms Core 2.1

Validation customization is one of the improvements introduced in WebForms Core 2.1.

Developers can configure messages for standard HTML5 validation states through WebFormsJS options and modify those options dynamically through WebForms Action Controls.

This approach preserves the simplicity and standards of native HTML5 validation while adding another layer of control for applications that need custom messages, dynamic configuration, or localization.

WebForms Core 2.2 Development Has Begun

Elanat Framework — Thu, 24 Sep 2026 22:54:13 +0000

A New Stateless Architecture for Server-Orchestrated UI

Unlike many server-driven UI approaches, including Blazor Server, WebForms Core introduces a fundamentally different architectural model: server-orchestrated UI built on a stateless server and server-defined UI structure. While Blazor Server maintains a stateful server-side circuit for each connected browser context, WebForms Core does not require the server to maintain a persistent component tree, render tree, or mirrored DOM state for each user. Instead, the server defines UI operations through the WebForms class and generates commands that WebFormsJS executes against the actual HTML document in the browser. This creates a clean separation between server-defined UI structure and client-side DOM execution, while preserving the stateless nature of the server architecture. The result is a lightweight and scalable model in which the server orchestrates the interface without becoming the permanent owner of its browser-side state. WebForms Core therefore approaches Server-Driven UI from a different direction: not by keeping the UI alive on the server, but by describing and orchestrating UI transformations from a stateless server.

WebForms Core 2.2 is focused on taking the server-orchestrated UI model to a higher level. The goal is not simply to add more commands, but to provide better mechanisms for rendering, state management, data transformation, formatting, arithmetic operations, and extensibility.

The direction of 2.2 is to make complex UI operations more expressive while keeping the WebForms Core architecture server-oriented, HTML-native, and independent of a separate frontend framework.

A More Expressive WebForms Model

WebForms Core uses a server-side WebForms class to generate commands that are executed by WebFormsJS in the browser:

Server
   ↓
WebForms
   ↓
Commands
   ↓
WebFormsJS
   ↓
HTML DOM

With 2.2, the focus is moving toward higher-level operations.

Instead of requiring developers to construct every transformation from small DOM commands, WebForms Core can increasingly perform formatting, text processing, arithmetic calculations, rendering operations, state detection, and other transformations directly within the WebForms execution model.

Isolated DOM Operations

One of the new capabilities in WebForms Core 2.2 is Isole.

Isole provides a high-level abstraction for working with the Transient DOM. It automatically performs the transient DOM initialization and completion around a group of operations.

This removes the need to manually manage the underlying StartTransientDOM and EndTransientDOM operations.

The result is a simpler way to isolate a complex group of DOM transformations while keeping them within the existing WebForms execution hierarchy.

Rendering and State Management

Rendering and state management are among the most important architectural directions in WebForms Core 2.2.

Complex UI updates are rarely just a single DOM operation. A rendering process may involve multiple transformations, temporary states, repeated template binding, state detection, and potentially restoring the previous state.

WebForms Core 2.2 is therefore introducing mechanisms that allow these operations to be treated as part of a larger rendering process.

Snapshot and Rollback

Snapshot and rollback provide a mechanism for preserving and restoring the HTML state of an element.

A snapshot can preserve the outerHTML of a target before a transformation. The element can then be modified, rendered, or repeatedly bound to a template. If necessary, the previous state can be restored.

Conceptually:

Current DOM State
    ↓
Snapshot
    ↓
Transform
    ↓
New DOM State
    ↓
Rollback
    ↓
Previous DOM State

This is particularly useful for complex rendering scenarios where several operations need to work against the same original state.

It also provides a foundation for higher-level rendering operations in which snapshot and rollback do not need to be explicitly managed by the developer.

Hash-Based State Detection

WebForms Core 2.2 also introduces GetTagHash.

The operation generates a hash from the HTML representation of a tag. The hash can be stored and later compared with a new hash to determine whether the HTML state has changed.

This provides a lightweight mechanism for detecting UI state changes without requiring the server to maintain a mirror of the browser DOM.

Conceptually:

HTML
 ↓
GetTagHash
 ↓
Hash
 ↓
Store
 ↓
Later
 ↓
GetTagHash
 ↓
Compare

This capability can become useful for state validation, conditional rendering, optimization, and future rendering mechanisms.

Rendering Without Mirroring the DOM

These mechanisms follow an important principle of WebForms Core.

The server does not need to maintain a complete representation of the browser's DOM.

Instead, the server can describe a transformation, while WebFormsJS performs that transformation against the actual HTML document in the browser.

This keeps the architecture server-orchestrated without turning the server into a permanent DOM state manager.

Formatting Data

WebForms Core 2.2 introduces formatting operations for cached and saved values.

This allows common formatting tasks to be performed directly inside the WebForms execution model.

For example:

4200
↓
4,200

A time value can also be normalized:

23:1:8
↓
23:01:08

Formatting can use regular expressions, making the mechanism useful for both simple formatting and more advanced text transformations.

For example:

(\d)(?=(\d{3})+$)

can be used to transform a numeric string into a thousands-separated representation.

This removes the need for repetitive conditional operations for common formatting scenarios.

Arithmetic Operations

WebForms Core 2.2 also brings arithmetic operations directly into the WebForms command model.

The supported operations include:

+
-
*
/
%
//
**

These operations make it possible to perform calculations directly on values used by WebForms commands.

For example, a value can be increased, decreased, multiplied, divided, processed with modulo or integer division, or used in an exponentiation operation without requiring custom JavaScript.

This is particularly useful when arithmetic is part of a larger server-orchestrated UI operation.

Text Operations

Text operations are another significant part of WebForms Core 2.2.

Instead of requiring developers to repeatedly save intermediate values and manually manipulate strings, WebForms Core can perform common string operations directly within the WebForms execution flow.

Operations include capabilities such as:

Substring
TextBefore
TextAfter

and other string transformations.

These operations make it possible to extract and transform parts of values directly in WebForms commands.

For example, a value can be processed by extracting a specific substring, obtaining the text before or after a specified value, and then passing the result to another operation.

This creates a much more expressive data-transformation model:

Fetch
  ↓
Text Operation
  ↓
Arithmetic
  ↓
Format
  ↓
Render

The significance is not the individual string methods themselves. The important part is that data transformation becomes a native part of the WebForms execution model.

Regex-Based Tag Selection

WebForms Core 2.2 also introduces the ability to select tags using regular expressions against their HTML representation.

This provides another mechanism for locating elements when conventional selectors are not sufficient.

A developer can work with the HTML representation of elements and use a regular expression to identify matching tags for further operations.

This extends the selection capabilities of WebForms Core beyond conventional CSS-oriented targeting.

Comments and Debugging

A Comment capability has also been introduced.

It allows developers to place comments within the generated WebForms command structure.

This is useful when inspecting generated Action Controls and understanding why a particular sequence of commands exists.

For complex WebForms classes, comments can make the generated command structure easier to understand and debug.

The feature is intentionally simple, but it becomes increasingly useful as WebForms classes contain more sophisticated rendering and transformation logic.

Middleware

WebForms Core 2.2 is also moving toward a middleware-based extension mechanism.

The purpose is to allow developers to add specialized JavaScript capabilities without modifying the WebFormsJS core.

For example:

form.UseMiddleware("/js/image-quality.js");

A middleware can participate in a processing stage and modify data before it continues through the normal execution flow.

For example, an image-quality middleware could process uploaded images before they are sent:

FormData
   ↓
Image Quality Middleware
   ↓
XMLHttp.send()

This makes specialized capabilities possible as independent modules.

Image processing is only one example. Similar middleware modules could provide compression, client-side transformations, specialized controls, or other browser capabilities.

The important point is that middleware extends the existing WebForms Core architecture rather than introducing a separate execution model.

From Commands to Operations

One of the broader goals of WebForms Core 2.2 is to increase the abstraction level of the WebForms language.

A WebForms class can increasingly express operations such as:

Format
Arithmetic
Text Processing
Rendering
State Detection
Snapshot
Rollback
Middleware

rather than implementing every behavior as a collection of low-level DOM commands.

This makes the WebForms class more expressive while preserving the underlying Commander-Executor architecture.

A Server-Orchestrated Rendering Architecture

WebForms Core 2.2 continues the evolution of WebForms Core as a Server-Orchestrated UI technology.

The server remains responsible for describing UI operations through the WebForms class and generated commands.

WebFormsJS remains responsible for executing those commands against the browser's actual HTML DOM.

The architecture can therefore be represented as:

Server
   ↓
WebForms Class
   ↓
Server Commands
   ↓
WebFormsJS
   ↓
HTML DOM

The new capabilities in 2.2 add higher-level layers around this architecture:

Data
 ↓
Transformation
 ↓
Formatting
 ↓
Rendering
 ↓
State Detection
 ↓
DOM Execution

This allows WebForms Core to handle increasingly complex interactive interfaces without requiring a separate frontend application or a client-side virtual representation of the UI.

The Direction of WebForms Core 2.2

WebForms Core 2.2 is still under development, so additional capabilities and API refinements may be introduced during development.

However, the direction is already clear.

The focus is moving from individual DOM manipulation toward a more complete model for server-orchestrated rendering, data transformation, state management, and extensibility.

The objective is to make complex interactive web applications easier to build while keeping the architecture:

Server-oriented
HTML-native
Stateless at the application architecture level
RESTful
Compatible with HTTP, WebSocket, and SSE
Independent of a separate frontend framework
Extensible through WebForms and WebFormsJS

WebForms Core 2.2 is not simply another collection of commands.

It is an effort to build a more expressive foundation for Server-Orchestrated UI.

Elanat CMS Will Be Retired After Version 2.2: Introducing Gloria, a New Generation CMS

Elanat Framework — Wed, 23 Sep 2026 20:46:24 +0000

Elanat has made an important decision regarding the future of its content management system.

Elanat CMS 2.2 will be the final version of Elanat CMS. After version 2.2, Elanat CMS will be permanently retired and no new versions will be released.

This decision does not mean that Elanat is leaving the CMS space. Instead, we have decided to begin a new CMS project with a new name: Gloria.

Gloria will be a new generation CMS built from the ground up using the latest versions of .NET, the CodeBehind Framework, and WebForms Core technology.

Why Are We Retiring Elanat CMS?

Elanat CMS has become a very large software system.

The current project contains approximately:

2,894 files
1,667 folders

The size of the project is not itself a problem. In fact, this size reflects the amount of functionality and structure that has been developed in Elanat CMS over the years.

The real challenge is the cost of making fundamental architectural changes to an already large system.

Elanat CMS was originally designed around an SSR architecture with vanilla JavaScript for client-side interaction. The system also contains many structures that were appropriate for its original architecture and development period.

Changing fundamental parts of such a large system is possible. We could continue modifying Elanat CMS and gradually replace its internal structures.

However, we reached the point where continuing to modify the existing system would require increasingly complex changes.

Instead of continuously modifying an old architecture, we decided that it would be more appropriate to build a new system from the beginning.

From Elanat CMS to Gloria

The new system will be called Gloria.

Gloria will not simply be a new version of Elanat CMS.

It will be a new CMS project with a new architectural foundation.

The goal is to use the latest versions of .NET together with the latest capabilities of the CodeBehind Framework and WebForms Core.

This will allow us to redesign the internal architecture instead of carrying every historical implementation decision from Elanat CMS into the new system.

One important example is data access.

Some parts of Elanat CMS rely on structures such as Stored Procedures. In Gloria, we want to move toward modern approaches such as ORM-based data access where appropriate.

This is one of the reasons why a clean rewrite is more suitable than attempting to transform the existing system piece by piece.

Gloria Will Continue the Elanat CMS Philosophy

Although Gloria will be a new system, it will not abandon the concepts that made Elanat CMS what it is.

Some important concepts and structures will continue in Gloria.

The add-on-oriented architecture will remain an important part of the new system.

The concepts of components, add-ons, and the way different parts of the system are organized will also continue to influence Gloria.

Naming conventions and several structural ideas from Elanat CMS will be carried forward.

Therefore, Gloria should not be understood as an unrelated CMS.

It is better understood as the next generation of the Elanat CMS direction, implemented with a new technical foundation.

The Elanat Ecosystem

Elanat's ecosystem currently consists of three major technologies and products:

CodeBehind Framework
WebForms Core
Elanat CMS

CodeBehind is the modern full-stack framework developed by Elanat under ASP.NET Core. It supports multiple development patterns and provides the foundation on which Elanat CMS was built.

WebForms Core is Elanat's server-side UI manipulation technology. It introduces a server-side WebForms class and a browser-side WebFormsJS runtime for executing commands against the HTML DOM.

Elanat CMS was built on the CodeBehind Framework and developed as a large, modular CMS with an add-on-oriented architecture.

The new direction brings these technologies closer together.

Gloria will be built on the latest generation of CodeBehind and WebForms Core.

This means that the new CMS will be developed using the technologies that Elanat has been building and improving independently over recent years.

Why a New Name?

We deliberately chose a new name instead of simply calling the project "Elanat CMS 3".

There is an important reason for this.

Gloria will not be a normal major version upgrade.

It will be a new system created from the foundation up.

Calling it Elanat CMS 3 would suggest that the project is simply continuing the existing codebase with another major version.

That would not accurately describe what we are doing.

Elanat CMS 2.2 is the end of the existing Elanat CMS project. Gloria is the beginning of a new CMS project.

A Clearer Name and Identity

There was also another consideration behind the decision to introduce a new name.

The name Elanat CMS is closely associated with Elanat, the organization and technology ecosystem behind the project. Over time, this similarity sometimes created confusion between the name of the CMS itself and the name Elanat as the broader ecosystem.

Elanat is no longer limited to a single CMS. Its ecosystem now includes CodeBehind, WebForms Core, and Elanat CMS, each representing a different part of the technology stack.

For this reason, introducing a distinct name for the next-generation CMS will also provide a clearer identity for the product.

The new name, Gloria, separates the identity of the CMS from the identity of the Elanat ecosystem while preserving the project's connection to its history.

Gloria will therefore have its own product name, while remaining part of the Elanat ecosystem.

The Elanat Logo Will Continue

Although Gloria will have a new name, the project will retain the Elanat CMS logo.

The logo is part of the visual identity and history of the project, and we want that connection to remain visible.

Gloria therefore represents a new technical beginning while preserving part of the identity that came from Elanat CMS.

In this sense, the relationship is simple:

Elanat CMS → Gloria

The name changes.

The architecture evolves.

The experience gained from Elanat CMS remains.

And the development continues under the Elanat ecosystem.

What Happens to Elanat CMS 2.2?

Elanat CMS 2.2 is the final version.

There will be no Elanat CMS 2.3.

There will be no Elanat CMS 3.

After version 2.2, the Elanat CMS project will be considered retired.

The existing project will remain part of Elanat's open-source history, but active development will move to Gloria.

The decision also means that we will not attempt to transform the existing Elanat CMS codebase into Gloria through an endless series of migrations.

Instead, Gloria will start from a clean foundation.

A New Beginning

Large software projects accumulate history.

That history can be valuable because it contains years of development experience, architectural experiments, solutions to real problems, and ideas that have proven useful.

But history can also make fundamental redesign increasingly difficult.

Elanat CMS has reached a point where we believe a new beginning is the more appropriate engineering decision.

We could continue modifying the existing system.

Instead, we chose to build something new.

Gloria will take the lessons, concepts, structures, and experience of Elanat CMS and combine them with the modern technologies developed by Elanat.

The target is a CMS that is substantially more modern, easier to evolve, and better aligned with the current Elanat technology stack.

Repository Transition

The transition to Gloria also includes a change in the project's repository structure.

The new Gloria project is being developed in a separate repository:

Gloria on GitHub

The existing Elanat CMS repository will be archived:

Elanat CMS on GitHub

Archiving the repository does not mean that the history of Elanat CMS will be removed. The repository will remain available as an archived record of the project and its development history, while active CMS development moves to Gloria.

This separation is intentional.

Elanat CMS represents the previous generation of the CMS, while Gloria represents a new implementation built around the current Elanat technology stack.

Elanat CMS 2.2 is the final release. The Elanat repository will be archived, and active CMS development will continue in the Gloria repository.

From the Past to the Next Generation

Elanat CMS was an important part of the development of the Elanat ecosystem.

It helped establish concepts such as an add-on-oriented architecture, modular system design, components, and a CMS structure capable of supporting a wide range of functionality.

Today, the ecosystem has evolved.

CodeBehind has become a modern ASP.NET Core framework.

WebForms Core is a server-side UI manipulation technology for working with HTML through server-generated commands.

The next step is to bring these technologies together in a new CMS.

That CMS will be Gloria.

Elanat CMS 2.2 marks the end of one chapter.

Gloria will begin the next one.

DEV Community: Elanat Framework

Building a Bubble Popping Game with WebForms Core + Online Demo

1. Defining the Game Interface

Styling the bubbles

2. Initializing WebForms Core

3. Starting a New Game

4. Creating Bubbles Dynamically

5. Moving the Bubble

6. Popping a Bubble and Updating the Score

7. Ending the Game

8. Exporting the Commands

Conclusion

CSRF Protection in WebForms Core Using CodeBehind

1. Introduction to CSRF Protection in WebForms Core

2. CodeBehind as the Backend

3. Generating a Secure CSRF Token

4. Storing the Token in Session

5. Adding the Token to the HTML Form with WebForms Core

6. Validating CSRF Tokens on POST Requests

7. Handling Validation Results with WebForms Core

8. Additional Security Layers and Conclusion

Related links

Drag and Drop Without Writing JavaScript with WFC + Online Demo

The Example

Defining the Drag Events

Saving the Dragged Element

Highlighting the Drop Zone

Moving the Item

Supporting the Reverse Direction

Touch Interaction Without JavaScript

One Server-Side Definition, Multiple Client Behaviors

Why This Is Different

No Custom JavaScript Required

Conclusion

Related links

No React, No Vue, No Angular: Explore the WebForms Core Demo Website in Action

Have You Used WebForms Core? Share Your Experience

WebForms Core 2.2 Released: Render, a New Approach to UI Rendering

Render

Render and Transient DOM

Snapshot and Rollback

GetTagHash

Formatting Values with Regex

Arithmetic Operations

Text Operations

Regex-Based Element Selection

JavaScript Objects from WebForms

Try and Catch

LockQueue

Native HTML Validation from the Server

Stable WebAssembly Support

WebForms Classes Across 18 Programming Languages

Why WebForms Core Did Not Add Middleware

Other Changes

Reflection renamed to Reflect

Debugger numbering

JavaScript Object escaping

WebForms Core 2.1.1 and 2.1.2

Final Thoughts

Related links

Java WebAssembly Meets WebForms Core 2.2

Java WebAssembly with TeaVM

Compiling Java to WebAssembly

Using Java WebAssembly from CodeBehind

HTML

What about Bytecoder?

What about CheerpJ?

Why TeaVM?

Conclusion

Related links

CodeBehind 4.8 Released

CodeBehind

What's New in CodeBehind 4.8

The Control Method Has Been Removed

Why Was the Control Method Removed?

How to Update CodeBehind on Active Systems

Development Configuration

Installation and Requirements

Related Links

C/C++ Experience with WebForms Core from Elanat

The `Control` Method Has Been Removed

Why Was the `Control` Method Removed?