DEV Community: Elanat Framework

A New Approach to Form Data Handling in CodeBehind 4.7

Elanat Framework — Sat, 05 Sep 2026 20:05:56 +0000

CodeBehind 4.7 introduces an important improvement to the way Form data is handled in incoming requests.

From this version onward, Form data should no longer be accessed directly through context.Request.Form. The internal structure responsible for injecting Form data into every request has been removed from the CodeBehind core.

Previously, developers could use conditions such as:

if (context.Request.Form["Button"].Has())
    Button_Click(context);

However, this approach is no longer supported. If a request does not contain Form content, attempting to access context.Request.Form will cause an error. For example, if the incoming request is a GET request, the condition above attempts to read Form data from a request that does not contain Form content.

To prevent this issue, Form data should only be accessed after verifying that the request contains Form content through HasFormContentType.

CodeBehind 4.7 also provides the IfForm extension method as a simpler and safer solution. It allows developers to conditionally access Form data without directly attempting to read Form values from requests that do not contain Form content.

The previous code can therefore be replaced with:

if (context.Request.IfForm()["Button"].Has())
    Button_Click(context);

The IfForm extension method provides a safer way to work with Form data and prevents unnecessary attempts to read Form values from requests that do not contain Form content.

This improvement also reduces unnecessary processing inside the CodeBehind core. Since the Form data injection structure has been removed from the CodeBehind core, requests that do not require Form processing, such as GET requests, are no longer subject to unnecessary Form-related processing.

This approach is particularly important because CodeBehind is designed around processing incoming requests through the PageLoad method in the controller. In the recommended CodeBehind development pattern, submitted Form data is examined to identify the type of request, and the appropriate operation or event is executed based on the available data.

For this reason, using conditions based on Form data is one of the primary approaches for handling different requests within a controller. With IfForm, these checks can be performed safely, allowing requests such as GET requests, which do not contain Form content, to be processed without causing an error.

For example, the PageLoad method can handle requests associated with different controls based on their Form data:

public void PageLoad(HttpContext context)
{       
    if (context.Request.IfForm()["run_test1"].Has())
    {
        Button1_Click(context);
        return;
    }

    if (context.Request.IfForm()["run_test2"].Has())
    {
        Button2_Click(context);
        return;
    }

    if (context.Request.IfForm()["run_test3"].Has())
    {
        Button3_Click(context);
        return;
    }

    WebForms form = new WebForms();

    form.SetBackgroundColor("<main>", "lightblue");
    form.AddText("<main>", Fetch.LoadUrl("/contact"));

    Write(form.ExportToHtmlComment());
}

In this structure, Form requests are checked first. If the request contains the data associated with one of the operations, the corresponding method is executed and request processing ends. If the request does not correspond to any of these operations, execution continues through the PageLoad method and the normal page content is processed.

This pattern provides a simple, clear, and controlled structure for handling different types of requests within a single controller.

The new approach provides a cleaner and more controlled way to process incoming requests while making Form data access safer and simpler for developers.

WebForms.php 2.1 Released - DeepSeek Converted and Qwen Evaluated

Elanat Framework — Sat, 05 Sep 2026 18:18:20 +0000

WebForms.php 2.1 has been released as the PHP back-end implementation of WebForms Core 2.1.

This release is different from a typical porting story.

The PHP implementation was converted from the C# implementation of WebForms Core using DeepSeek, and then independently evaluated with Qwen.

The process was not simply:

C# → PHP

It was:

C# → DeepSeek conversion → manual review → Qwen evaluation → corrections → testing → release

This article explains that process and some of the interesting problems that appeared during the conversion.

What is WebForms.php?

WebForms.php is the PHP back-end part of WebForms Core.

WebForms Core is a server-driven web technology based on the Commander–Executor concept.

The server generates commands that describe UI operations and execution flow. WebFormsJS, running in the browser, interprets and executes those commands.

The WebForms class itself does not manipulate the browser DOM directly.

It generates the WebForms Core command structure.

This makes the WebForms class particularly suitable for implementation in multiple programming languages.

The PHP implementation provides the same WebForms Core programming model for PHP applications.

Why Convert the C# Implementation?

WebForms Core already has implementations for multiple programming languages.

The C# implementation is the primary reference implementation and contains a large number of methods for:

DOM manipulation
event management
Fetch operations
conditions
loops
state management
storage
browser history
WebSockets
SSE
templates
selectors
Action Controls
and other WebForms Core operations

The WebForms class mainly generates command strings.

Because of this architecture, the fundamental logic does not need to be redesigned for every language.

The objective of the PHP implementation was therefore to preserve the behavior and output of the C# implementation while adapting the code to PHP conventions and language capabilities.

DeepSeek Conversion

I provided the C# implementation and related helper classes to DeepSeek.

The instructions were intentionally strict.

DeepSeek was asked to first analyze the structure and explain the conversion approach.

The important requirement was that the conversion should preserve the behavior of the C# implementation.

However, the PHP implementation should not simply look like C# code written with PHP syntax.

The destination language's conventions were explicitly required.

For example, PHP naming conventions should be used where appropriate.

A C# method such as:

SetWidth(...)

should become:

setWidth(...)

and parameters should follow PHP naming conventions:

$inputPlace
$width

rather than preserving C#-style parameter names such as:

$InputPlace
$Width

The same principle applied to language features.

If C# used a feature that did not exist in PHP, the conversion needed to use an appropriate PHP equivalent rather than attempting to reproduce the syntax literally.

Overloading Was One of the Interesting Problems

C# supports method overloading.

PHP does not support traditional method overloading based on parameter signatures in the same way.

Therefore, overloaded C# methods needed to be represented using PHP language features where possible.

For example, instead of creating unnecessary methods for different parameter types, PHP Union Types can be used.

A method can accept:

string|int

and determine the appropriate behavior internally.

For example:

public function setWidth(string $inputPlace, string|int $width): void
{
    if (is_int($width)) {
        $width .= 'px';
    }

    $this->add('sw' . $inputPlace, $width);
}

This keeps the public API compact while preserving the behavior expected from the overloaded C# methods.

Nullable parameters were also handled using PHP's nullable types and default values.

For example:

?int $second = null

can represent an optional second argument when converting an overloaded method such as a random-number operation.

The important point is that the goal was not to reproduce the C# method signatures.

The goal was to preserve their behavior using the capabilities of PHP.

The First Review

After the DeepSeek conversion, the generated code was reviewed manually.

This was necessary because syntactically valid PHP does not necessarily mean behaviorally compatible PHP.

The two languages have important differences in:

type conversion
null handling
method overloading
string conversion
arrays
optional parameters
naming conventions
object handling

A port can therefore compile and run while still producing a different WebForms Core command.

This is particularly important for WebForms Core because the generated command is effectively part of the protocol between the WebForms class and WebFormsJS.

A small difference in generated output can therefore become a functional difference.

Qwen Evaluation

After the initial conversion, I gave the PHP implementation to Qwen for an independent evaluation.

The purpose was not to ask Qwen to rewrite the entire implementation.

It was asked to evaluate the conversion and look for incompatibilities between the PHP implementation and the original C# behavior.

This produced several useful findings.

Two of them were particularly important.

Issue 1: `implode()` and Mixed-Type Arguments

The C# implementation could use:

string.Join(US, Args)

where Args could contain objects or values of different types.

C# converts the values to their string representation when joining them.

The corresponding PHP implementation initially used:

implode(self::US, $Args)

This is not equivalent for arbitrary mixed values.

PHP's behavior around non-string values passed to implode() is different, particularly with newer PHP versions.

Qwen therefore identified the need to explicitly convert the values:

implode(
    self::US,
    array_map('strval', $Args)
)

This makes the intended conversion explicit and avoids relying on PHP's implicit behavior.

The important lesson was that a direct API-to-API translation is not always a semantic translation.

The C# expression and the PHP expression may look equivalent while behaving differently with real input types.

Issue 2: `null` and Empty String Behavior

Another issue involved the internal add() method.

The C# implementation uses StringBuilder.Append().

Appending a null value does not insert the four characters "null" and does not remove the preceding structure. It effectively contributes an empty string.

This distinction matters when generating WebForms Core commands.

The PHP implementation initially treated a null value differently.

For methods such as:

deleteState(?string $path = null)

the generated command could therefore differ from the C# implementation.

Qwen identified this difference and suggested explicitly normalizing the null value:

$this->add('DS', $path ?? '');

The result preserves the command structure expected from the C# implementation.

This was not a syntax error.

Both versions were valid PHP.

It was a cross-language semantic difference.

Other Findings

Qwen also identified several other areas that required attention during the conversion.

These included handling overloaded methods using PHP Union Types, optional and nullable parameters, and type-based routing in helper methods.

For example, the InputPlace::attribute implementation can use the PHP type system to distinguish different forms of the original overloaded API.

Qwen also identified corrections related to specific converted values, including the CPP value in WasmLanguage and the prefix generated by SetMaxLength.

These findings were reviewed against the intended WebForms Core behavior before being incorporated.

The purpose of this process was not to assume that every suggestion from an AI evaluator was automatically correct.

Each finding still had to be compared with the original implementation and the intended protocol.

AI Did Not Replace Testing

This is probably the most important part of this release.

DeepSeek was useful for producing the initial PHP implementation.

Qwen was useful as an independent reviewer.

But neither replaced testing.

The final implementation was reviewed against the original C# implementation and tested for compatibility with WebFormsJS.

This distinction matters.

AI can identify a large number of repetitive transformations very quickly.

It can also identify subtle differences that are easy to miss during manual review.

However, the final authority is still the actual behavior of the software.

The workflow therefore became:

C# Reference Implementation
          ↓
      DeepSeek
          ↓
   PHP Conversion
          ↓
    Manual Review
          ↓
        Qwen
          ↓
 Semantic Corrections
          ↓
       Testing
          ↓
   WebForms.php 2.1

PHP Conventions

One of the goals of the conversion was to make WebForms.php feel like PHP code rather than C# code translated into PHP syntax.

This includes method naming, parameter naming, type declarations, nullable parameters, Union Types, arrays, and other language-specific constructs.

For example, PHP should use:

$inputPlace
$width
$maxValue

rather than carrying C# naming conventions into the PHP API.

At the same time, the generated WebForms Core commands must remain compatible with the existing WebFormsJS runtime.

This creates an important separation:

The implementation follows PHP conventions.

The generated protocol follows WebForms Core conventions.

That separation is fundamental to a multi-language implementation.

Using WebForms.php

WebForms.php can be used directly by including the PHP class:

<?php

include 'WebForms.php';

use WebFormsCore\WebForms;
use WebFormsCore\Fetch;

$form = new WebForms();

$form->setText("message", "Hello from PHP!");

echo $form->response();

It can also be installed as a Composer package.

After installing the package, the Composer autoloader can be included:

require __DIR__ . '/vendor/autoload.php';

and the WebForms Core classes can be used normally.

A Small PHP Example

A simple example can use WebForms.php to create an interactive game without writing JavaScript business logic.

For example, a small "Flower or Empty" game can be implemented with HTML containing only the interface:

<button value="0" win-with="1">
    🌹 Flower
</button>

<button value="1" win-with="0">
    ✊ Empty
</button>

<p id="computer">
    Computer choice:<span></span>
</p>

<p id="result"></p>

The PHP code then defines the behavior:

<?php

require __DIR__ . '/vendor/autoload.php';

use WebFormsCore\WebForms;
use WebFormsCore\Fetch;
?>

<!DOCTYPE html>
<html>
<head>
    <title>Gol Ya Pooch - WebForms Core</title>
    <script type="module" src="/script/web-forms.js"></script>
</head>

<body>
    <h1>🌹 Gol Ya Pooch ✊</h1>

    <p>Choose one:</p>
    <button value="0" win-with="1" id="flower">
        🌹 Flower
    </button>
    <button value="1" win-with="0" id="empty">
        ✊ Empty
    </button>

    <p id="computer">
        Computer choice:<span></span>
    </p>

    <p id="result"></p>
    <p>
        Games:
        <span id="counter">0</span>
    </p>
    <p>
        Wins:
        <span id="win-counter">0</span>
    </p>
</body>
</html>

<?php

$form = new WebForms();

$form->setCommentEvent("<button>*", "onclick", "play");
$form->setFontSize("<button>*?.<p>*", 40);

$form->startIndex("play");

// Increase game counter
$form->increase("counter", 1);

// Generate and save computer choice
// 0 = Flower, 1 = Empty hand
$form->addSaveValue("random", Fetch::random(0, 2));

// Player wins
$form->isEqualTo(Fetch::getAttribute("$", "win-with"), Fetch::save("random"));
$form->startBracket();
$form->setText("result", "😀 You win!");
$form->increase("win-counter", 1);
$form->endBracket();
$form->else(); // Equal
$form->setText("result", "😢 You lose!");

// Show computer choice
$form->isEqualTo("0", Fetch::save("random"));
$form->setText("computer|<>", "🌹 Flower");
$form->else();
$form->setText("computer|<>", "✊ Empty");

echo $form->exportToHtmlComment();

?>

The example demonstrates an important property of WebForms Core.

The PHP code describes the behavior.

The browser executes the resulting WebForms Core commands through WebFormsJS.

No JavaScript business logic is required for the game.

Game screenshot

WebForms.php 2.1 and WebFormsJS 2.1

WebForms.php 2.1 is designed for WebFormsJS 2.1.

The two components work together as the server-side command generator and client-side executor.

WebForms Core 2.1 introduced a large number of new capabilities, including nested conditions, Then, Repeat, ForEach, advanced element selection, WPC criteria, State improvements, template rendering, debugging, improved history management, and other runtime improvements.

The PHP implementation exposes the corresponding server-side API for PHP applications.

WebForms Core 2.1 was also extensively tested for compatibility between its WebForms classes and WebFormsJS. The main 2.1 release went through more than three months of compatibility testing and reported a greater than 99% test success rate.

Package Distribution

WebForms.php is distributed as a Composer package.

The package name is:

webforms-core/php

It can be installed with:

composer require webforms-core/php

The package uses Composer autoloading so that the WebForms.php implementation is loaded through:

require __DIR__ . '/vendor/autoload.php';

This makes WebForms.php available through the standard PHP package ecosystem.

Conclusion

WebForms.php 2.1 is not simply a translation of C# code into PHP syntax.

It is a PHP implementation of the WebForms Core 2.1 server-side programming model.

The development process was also an experiment in AI-assisted multi-language development.

DeepSeek performed the initial conversion.

Manual review identified language-specific differences.

Qwen independently evaluated the result and identified semantic compatibility problems that were not obvious from the syntax alone.

The final implementation was then corrected and tested.

The experience demonstrated something important about using AI for software porting:

AI can significantly accelerate a language conversion, but successful porting requires more than generating syntactically valid code.

The difficult part is preserving behavior across languages.

C# and PHP have different type systems, different conventions, different overload mechanisms, and different runtime behavior.

A reliable port therefore needs to preserve the protocol and semantics while allowing the implementation to become native to its destination language.

You can use the PHP version with complete confidence. If there is any problem, it will be fixed very soon by Elanat.

That is the approach used for WebForms.php 2.1.

DeepSeek converted it.
Qwen evaluated it.
Testing validated it.
WebForms.php 2.1 is now released.

Elanat WebForms Core 2.1 Released with a Major Update

Elanat Framework — Fri, 04 Sep 2026 18:33:24 +0000

WebForms Core, or WFC, is a new technology based on the Commander-Executor concept, developed by Elanat.

WebForms Core Organizations in GitHub

WebForms Core is a DSL for defining commands for creating, modifying, and controlling the DOM and the execution flow of the user interface, running alongside a client-side Runtime. This DSL enables declarative and Model-driven abstractions, allowing data flow, UI generation and modification, user interactions, and operation ordering to be defined without directly implementing DOM-related logic on the client side. The Runtime then interprets and executes these commands and applies the requested changes to the user interface.

WebForms Core is not designed only for forms and CRUD operations. It can even be extended to the creation of an interactive browser game.

Version 2.1 introduces high-level declarative capabilities. This version provides a higher abstraction over the WFC core, combining the advantages of declarative development through advanced methods and mechanisms with imperative development.

WebForms Core 2.1 supports JavaScript ES2020 and modern browsers based on common web standards from 2020–2021 and later versions. The previous version (2) supported ES2022, and in this version we committed to supporting some older browsers as well.

Therefore, this version is fully compatible with up-to-date browsers on Windows 7 and mobile devices released from 2015 onward, including Android 6.0 (with the latest Chrome version available for it, Chrome 106 in 2022) and iOS 15 (with Safari 15 in 2021).

Structure-centric UI Generation

In WebForms Core, it is possible to go beyond the Component level and focus on automatically generating UI structures instead of manually constructing individual UI components.

In this approach, rather than defining every Input, Label, form, and table individually, the developer defines rules and data structures, and the system creates the UI based on them.

For example, a Model or database table structure can be used as the basis for automatically generating Add and Edit forms, input fields, and even data presentation structures.

The developer is therefore primarily specifying "what data exists and what structure should be generated", rather than "how every HTML element should be constructed."

Compared with Blazor:

Blazor primarily provides a Component-centric UI Model, while WebForms Core can provide, in addition to reusable Components and structures, a Structure-centric or Metadata-driven UI Generation Model.

Other systems can also build such generators, and this is not an exclusive technological advantage. The important point is that the architecture and tools of WebForms Core are highly suitable for building systems that automatically generate DOM/UI structures.

Compared with React

React is essentially a component and state-based UI library.
WebForms Core offers something different: a DSL + Runtime to define and implement UI flow, Data Flow, and Execution Flow.

Compatibility Between WebForms and WebFormsJS

For example, WebFormsJS version 2.0.1 remains compatible with the WebForms class version 2.0 and 2.0.9.

Likewise, the WebForms class version 2.0.1 remains compatible with WebFormsJS version 2.0 and 2.0.9.

WFC is a continuously evolving technology, and using the latest versions of the technology is recommended.

WebForms Core 2.1

Version 2.1 is another major update, just like the previous two versions.

We spent more than three months writing tests for compatibility between the WebForms classes and the WebFormsJS library.

At Elanat, WFC 2.1 achieved a more than 99% quality assurance rate for WFC 2.1.

This percentage represents the success rate of our tests: we continued testing until we could no longer find problems.

The WebForms class is currently very stable. If a problem is reported in WebFormsJS in the coming days, we will fix it immediately and release version 2.1.1 and later. These patch versions remain fully compatible with the WebForms class version 2.1.

Creating HTML Comments for WebForms Responses

WebForms Core uses HTML comments as one of its mechanisms for storing and executing WebForms Action Controls.

When an HTML response contains the WebForms comment structure:

<!--[web-forms]
...
-->

the WebForms response comment can be handled automatically.

However, the following structure:

[web-forms]
...

is not automatically converted into an HTML comment.

WebForms Core 2.1 provides the following option for this purpose:

WebFormsOptions.CreateCommentForWebFormsResponse = false;

When enabled, WebFormsJS can create the required HTML comment structure for WebForms responses that use the [web-forms] format.

This provides additional flexibility when handling WebForms responses.

Security Improvements

To improve security, any spaces in the HTML comment are ignored.
Therefore, Action Controls must be placed directly after the string <!--

Acceptable Example

<!--[web-forms]
bc<main>=green-->

Ignored Examples

<!-- [web-forms]
bc<main>=green-->

<!--
[web-forms]
bc<main>=green-->

The location of the response has been improved in the settings.

A new StateBodyLocation option has been added for storing the State body instead of using ResponseLocation.

StateBodyLocation specifies where State changes are stored. By default, it is the <body> element.

ResponseLocation specifies where a server response should be inserted when the response is not only an Action Control—for example, when the server returns an HTML section. Its default is also <body>, but using <main> is recommended:

WebFormsOptions.ResponseLocation = "<main>";

Both StateBodyLocation and ResponseLocation use the WebForms Place Criteria (WPC) DSL for their values.

External URL Security

New security options have also been added for external URLs:

WebFormsOptions.DisableLoadExternalHost = false;
WebFormsOptions.UseLoadExternalHostOnlyInAcceptedList = false;
WebFormsOptions.LoadExternalHostOnlyInAcceptedList = ["example.com"];

URLs are filtered using a list and wildcard rules.

This restriction applies to external URL requests outside the current and primary server domain.

Additional Security Control with DisablePassObject

WebForms Core 2.1 also includes the following security-related option:

WebFormsOptions.DisablePassObject = false;

This option provides additional control over object passing behavior inside the WebFormsJS runtime.

Like other WebFormsJS security options, it can be configured depending on the requirements and security model of the application.

Action Control Values Are Now Arrays

In this version, the string-based structure of Action Control values has been changed to an array-based structure.

This provides complete control over Fetch results and value types.

For example, when the result of a Fetch operation is an object, it is no longer automatically converted to a string.

This allows Action Controls to work more naturally with different types of values, including numeric values and objects.

Form Submit Check Validity

In this version, the ability to fully validate HTML forms in WebFormsJS has been added, and it is possible to change the Validation warning text for HTML inputs in the settings section.

An option in the settings called CheckValidityForFormSubmit has also been added, which is enabled by default.

We will explain this section soon in a new article with an example.

Append and Replace for Stored Data

New capabilities have been added for appending to and replacing temporarily and permanently stored data.

The following methods have been added:

AppendCacheValue
ReplaceCacheValue
AppendSaveValue
ReplaceSaveValue

Cache refers to localStorage, while Save refers to sessionStorage.

URL Hash and Segment

A new capability has been added to SetMasterPage.

It is now possible to access the URL after #, including its hash and Segment information.

Segment

A new Segment mechanism has been introduced for URLs and hashes.

A ~ character can be used after #. Everything after ~ is treated as a URL path/Segment.

For example, a URL can contain a structure such as:

#~admin/users/edit

This mechanism makes it possible to build more powerful SPA systems.

The mechanism is also automatically enabled for internal links.

The Fetch helper class can now access Segments in the URL.

Negative indexes are supported as well:

form.message(Fetch.HashSegment(-1));

means the last Segment.

Query access in the Fetch helper has also been converted into a method, allowing a value to be retrieved from the query by its name.

form.message(Fetch.Query("name"));

Separator Changes

Version 2.1 contains a fundamental change to the internal separators.

In version 2.1, the separators previously represented by the | and , characters have been replaced with ASCII control characters 28, 29, 30, and 31.

Previously, the structure was effectively based on multiple character-level separators. For example, | was used as a separator while , was also used by Fetch. This could cause conflicts when a Fetch operation itself contained a list of arguments.

The new structure eliminates these conflicts.

There is now no longer even the smallest conflict caused by those common characters.

Template Engine

A new template rendering engine has been added to replace repeated manual Replace operations.

The main method is:

BindTemplate(...)

This performs a general replacement based on NameValue data from INI, JSON, and XML sources.

The data is automatically inserted into the template according to the specified pattern.

For example:

form.BindXMLToTemplate(
    "XMLTag",
    Fetch.LoadUrl("/api/xml_data.xml"),
    "contact",
    "{{value}}"
);

form.BindINIToTemplate(
    "INITag",
    Fetch.LoadUrl("/api/ini_data.ini"),
    "contact",
    "{{value}}"
);

An XML source can be:

<?xml version="1.0" encoding="UTF-8"?>
<contact>
    <name>John Doe</name>
    <phone>+1-555-123-4567</phone>
    <email>john.doe@example.com</email>
    <address>123 Main Street, Springfield, IL 62701, USA</address>
    <postalCode>62701</postalCode>
    <birthDate>1990-05-15</birthDate>
</contact>

And an INI source can be:

[contact]
name=Emma Wilson
phone=+44-7700-900-123
email=emma.wilson@example.co.uk
address=45 Baker Street, London, UK
postalCode=NW1 6XE
birthDate=1988-12-03

The template engine can then use the same structure to generate the required UI.

HTML Before BindTemplate

<h2>BindXMLToTemplate</h2>
<address id="XMLTag" class="contact-info">
  <p><strong>Name:</strong> {{name}}</p>
  <p>
    <strong>Phone:</strong> 
    <a href="tel:{{phone}}">{{phone}}</a>
  </p>
  <p>
    <strong>Email:</strong> 
    <a href="mailto:{{email}}">{{email}}</a>
  </p>
  <p><strong>Address:</strong> {{address}}</p>
  <p><strong>Postal Code</strong> {{postalcode}}</p>
  <p><strong>Birth Date:</strong> {{birthdate}}</p>
</address>

<h2>BindINIToTemplate</h2>
<address id="INITag" class="contact-info">
  <hr>
  <p><b>Name:</b> {{name}}</p>
  <br>
  <p><b>Phone:</b> <a href="tel:{{phone}}">{{phone}}</a></p>
  <br>
  <p><b>Email:</b> <a href="mailto:{{email}}">{{email}}</a></p>
  <br>
  <p><b>Address:</b> {{address}}</p>
  <br>
  <p><b>Postal Code:</b> {{postalCode}}</p>
  <br>
  <p><b>Birth Date:</b> {{birthDate}}</p>
  <hr>
</address>

HTML After BindTemplate

<div><h2>BindXMLToTemplate</h2>
<address id="XMLTag" class="contact-info">
  <p><strong>Name:</strong> John Doe</p>
  <p>
    <strong>Phone:</strong> 
    <a href="tel:+1-555-123-4567">+1-555-123-4567</a>
  </p>
  <p>
    <strong>Email:</strong> 
    <a href="mailto:john.doe@example.com">john.doe@example.com</a>
  </p>
  <p><strong>Address:</strong> 123 Main Street, Springfield, IL 62701, USA</p>
  <p><strong>Postal Code</strong> 62701</p>
  <p><strong>Birth Date:</strong> 1990-05-15</p>
</address>

<h2>BindINIToTemplate</h2>
<address id="INITag" class="contact-info">
  <hr>
  <p><b>Name:</b> Emma Wilson</p>
  <br>
  <p><b>Phone:</b> <a href="tel:+44-7700-900-123">+44-7700-900-123</a></p>
  <br>
  <p><b>Email:</b> <a href="mailto:emma.wilson@example.co.uk">emma.wilson@example.co.uk</a></p>
  <br>
  <p><b>Address:</b> 45 Baker Street, London, UK</p>
  <br>
  <p><b>Postal Code:</b> NW1 6XE</p>
  <br>
  <p><b>Birth Date:</b> 1988-12-03</p>
  <hr>
</address>

New Replace Capabilities

Several new Replace mechanisms have been added.

ReplaceActionControl

ReplaceActionControl replaces all Action Controls when executed.

For example:

form.ReplaceActionControl("{{segment}}", Fetch.Segment(2));

form.SetAttribute("<form>", "action", "/admin/update");
form.SetAttribute("-", "method", "put");
form.AddHidden("-", "id", Fetch.FormatStoreByJSONQuery("fs_json", "[{{segment}}].id"));
form.SetValue("(add)", "Click to update content");
form.SetName("-", "update");

AssignReplace

AssignReplace replaces a value only in one line of Action Controls.

Its default index is -1, and it is usually written immediately after the Action Control that should be modified.

form.Message("My Message: Page Title is {{Value}}");
form.AssignReplace(
    "{{Value}}",
    Fetch.GetText(InputPlace.Head.Child("<title>"))
);

AppendFetchReplace

AppendFetchReplace operates directly on Fetch.

form.Message(
        Fetch.GetText(
                InputPlace.Head.Child("{{Value}}")
    ).AppendFetchReplace("{{Value}}", "<title>")
);

These mechanisms make it possible to dynamically modify Action Controls and Fetch results without manually reconstructing the entire command structure.

Debugger

WebForms Core 2.1 introduces a new Debugger.

The Debugger allows developers to control the execution of Action Controls with operations such as:

Go
Pause
Stop
Step
Close

A simple server-side example:

using CodeBehind;

public partial class DebugerController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        if (context.Request.Query.ContainsKey("many-action-controls"))
        {
            Button_Click();
            return;
        }

        WebForms form = new WebForms();

        form.SetCommentEvent("StartDebuger", HtmlEvent.OnClick, "start-debuger");
        form.SetGetEvent("Button", HtmlEvent.OnClick, "?many-action-controls");
        form.StartIndex("start-debuger");
        form.CreateDebugger();

        Write(form.ExportToHtmlComment());
    }

    public void Button_Click()
    {
        var form = new WebForms();

        form.Message("Message 1", "success");
        form.Message("Message 2", "help");
        form.SetBackgroundColor("<main>", "lightgreen");
        form.ElementExists("<main>");
        form.Message("<main> element is exist");
        form.Else();
        form.Message("<main> element is not exist");
        form.Message("Continue Action Control", "help");

        IgnoreAll();
        Write(form.Response());
    }
}

If you want CreateDebugger() to immediately pause code interpretation, pass true:

form.CreateDebugger(true);

This starts the Debugger in the paused state.

The Debugger is implemented inside WebFormsJS and provides a client-side control panel for controlling execution.

Debugger screenshot

Repeat

Repeat is an extension over the GoTo command.

It provides a higher-level mechanism for repeating a group of Action Controls.

For example:

public WebForms Repeat(WebForms newForm, int repeat)
{
    if (newForm == null)
        return this;

    string bodyData = newForm.GetWebFormsData();

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

    int startLine = bodyData.Split('\n').Length * -1;

    AppendForm(newForm);
    GoTo(startLine, repeat - 1);

    return this;
}

There are also overloads that allow an index to be specified:

form.Repeat(f =>
{
    f.Message("Processing...");
    f.SetText("<main>", "Updated");
}, 5);

Instead of explicitly working with GoTo, developers can use Repeat as a higher-level abstraction.

Then

The Then method was added to the Condition section.

It allows conditional commands to be continued without requiring StartBracket().

For example:

form.ElementExists("<main>")
    .Then(f =>
    {
        f.Message("The main element exists.");
        f.SetText("<main>", "Updated");
    });

This makes conditional code easier to compose.

Conditions and Nested Execution

Conditions and loops must be able to execute in a nested manner.

In WebForms Core 2.1, the condition system has been completely rewritten in WebFormsJS.

else support has also been added to conditions.

This allows structures such as:

form.ElementExists("<main>");
form.Message("Main exists");

form.Else();
form.Message("Main does not exist");

The new architecture allows conditions and loops to be nested and combined.

Repeat and Then were added to the server-side WebForms class, while the underlying condition execution has been completely rewritten in WebFormsJS.

Unfortunately, due to the length of the article, we cannot cover nested conditions in this article. However, we will introduce nested conditions in a new article soon.

ForEach

ForEach is a new feature introduced in WebForms Core 2.1.

It provides a declarative way to iterate over stored data and execute a set of Action Controls for each item.

For example:

WebForms form = new();

form.NotExist(Fetch.Cache("series-data"));
form.AddCacheValue("series-data", Fetch.LoadUrl("/api/series-data"));

form.ForEach("[0]", Fetch.Cache("series-data"), "foreach-data")
.Then(f =>
{
    f.AddText("{series-container}", Fetch.LoadHtml("/api/template.html", "SeriesAdmin"));

    f.BindJSONToTemplate("{series-card}-1", Fetch.FormatStore("foreach-data"), "[0]", "{{value}}");

    f.SetDeleteEvent("{delete}-1", HtmlEvent.OnClick, Fetch.GetAttribute("{delete}-1", "path"));
});

Write(form.ExportToHtmlComment());

Because conditions and loops can now be nested, ForEach can be combined with conditional logic and other execution mechanisms.

This makes it possible to construct more complex server-defined UI workflows without manually implementing the corresponding client-side loop.

If you leave the selection name blank, a point (.) is chosen as the selection name. It is recommended to assign a unique identifier called ForEach to avoid conflicts.

The loop count is also added to the selection name as the character i.

Fetch.FormatStore("foreach-datai")

JSON Path Improvements

The Add, Read, Delete, and Edit operations for JSON have been improved.

Advanced JSON path operations are now possible using conditional queries and negative indexing.

For example, negative indexes can be used to address items relative to the end of an array.

This provides more flexibility when working with JSON data stored inside WebForms Core.

This section will also be reviewed in detail soon as a new article.

WebForms Place Criteria (WPC)

WebForms Place Criteria is a lightweight query language for locating and filtering web contexts, including DOM elements, document objects, browser windows, and other client-side objects.

WPC has been significantly expanded in this version.

HTML Tag Selection in InputPlace

An HTML tag can now be selected in InputPlace using the . character.

Attribute-based selection has also been added, allowing elements to be selected according to both an attribute name and its value.

For example, attribute conditions can use operators such as:

^
$
*
~

These correspond to operations such as starts-with, ends-with, contains, and word matching.

Child Selection

A powerful child selector has been added.

For example:

form.SetText("UserBox|<>0", "Hello");

<>0 means the first child.

The developer no longer needs to know the name of the first child.

For example, instead of having to know whether the first child is a <p>:

<p>0

the generic child selector can be used:

<>0

This is also available as part of the WebForms class.

All Selection

All tags can be selected using the All property or *:

InputPlace.All

or:

The DSL also supports selecting all matching names, tags, classes, attributes, and children.

Criteria

A new and powerful criteria mechanism has been added.

For example, elements can be filtered by inner text:

{my-class}*?t=abc

or by attributes:

"data-id'*abc"

Criteria can be chained together, allowing multiple filters and operations to be applied to the same result.

The criteria system supports operations for:

Inner text
All inner text
Attribute values
Tag names
Visibility
Enabled state
Checked state
Direct children
Descendants
Ranges
Next siblings
Previous siblings
Intersection
Union
Difference

For example, visibility can be tested using:

?v

and enabled or checked elements can be filtered using:

?e
?c

Ranges also support negative indexes.

The criteria engine is implemented in WebFormsJS and provides a lightweight query language on top of the WFC element-selection system.

The criteria section will be reviewed in detail soon as part of a new article.

State Improvements

SPA links now manage State and browser history more reliably.

Synchronizing State with the browser's Back and Forward buttons was particularly complex when the user pressed these buttons before the configured State registration delay had elapsed.

The default delay is 500 milliseconds and can be changed through configuration.

The SPALink system now handles State much more closely to the behavior of normal browser history.

StartState

The StartState method has been added:

public void StartState() => StartIndex("$");

WebForms Core interprets Action Controls line by line until it reaches a # character.

The # represents an index.

For example:

form.SetCommentEvent(
    "RunMessage",
    HtmlEvent.OnClick,
    "run-message"
);

form.SetGetEvent(
    "Button",
    HtmlEvent.OnClick,
    "?get-server-value"
);

form.StartIndex("run-message");
form.Message("Hello World!");

The first two lines are executed normally.

When the RunMessage button (any tags with RunMessage ID) is clicked, the run-message index is executed, causing the Action Control associated with Message() to run.

StartState is a special index that is executed when returning to a previously registered State, such as when the user navigates using the browser's Back or Forward buttons.

LoadState and HasState

A new LoadState method has been added.

The Fetch helper also now includes:

Fetch.HasState("/contact");

which can be used to determine whether a State exists.

More Control Over Browser History and DOM Event Listeners

WebForms Core 2.1 includes additional options for controlling SPA navigation and browser history behavior.

WebFormsOptions.IgnoreQueryAndHashInSPALink = false;
WebFormsOptions.ReloadOnMissingHistory = true;
WebFormsOptions.CloseAllFixedFeaturesAfterHistoryReview = true;
WebFormsOptions.RestoreListenersAfterHistoryReview = true;

The previous sections discussed the improvements made to State management and the synchronization of WebForms Core with the browser's Back and Forward buttons.

Version 2.1 also adds more control over situations that occur during history review.

One particularly important option is:

WebFormsOptions.RestoreListenersAfterHistoryReview = true;

DOM replacement can create a common problem in SPA-style applications: elements may be replaced and previously attached event listeners may no longer be available.

WebFormsJS 2.1 improves this process through the following runtime functionality:

cb_RestoreListenersAfterDOMReplace

This helps WebFormsJS restore the required listeners after DOM replacement and during history-related operations.

The new history options also provide additional control when a requested browser history state is missing and when fixed UI features need to be reviewed or closed during history navigation.

Initial State Loader

A Loader has been added for registering the initial State.

The new WebFormsOptions.UseLoaderForFirstPageLoad option enables an animation Loader during the initial page load.

The Loader is displayed while the initial data is being registered, preventing the user from interacting with the page before the initial State is ready.

The default delay is 500 milliseconds and can be configured.

Dynamically Changing WebFormsJS Options

WebForms Core 2.1 also introduces the ability to dynamically change WebFormsJS options through Action Controls.

This allows configuration to be changed during runtime instead of requiring all options to remain static.

The ChangeOption method allows an individual WebFormsJS option to be changed during execution:

form.ChangeOption("QueueDebounceDelay", "500");

In this example, the QueueDebounceDelay option is dynamically set to 500.

If the developer later wants to restore the original value of that specific option, the ResetOption method can be used:

form.ResetOption("QueueDebounceDelay");

It is also possible to reset all dynamically changed WebFormsJS options at once:

form.ResetOption(); // Reset all WebFormsJS options

This makes WebFormsJS configuration more flexible. Instead of treating options as static configuration that must remain unchanged after the page loads, WebForms Core can modify individual runtime behaviors dynamically and later restore either a specific option or the entire configuration to its original state.

Better SSE and WebSocket Connection Management

WebForms Core 2.1 provides more control over persistent connections and adds more methods for better SSE and WebSocket management.

Developers can configure the maximum number of reconnection attempts:

WebFormsOptions.WebSocketReconnectMaxRetries = 5;
WebFormsOptions.SSEReconnectMaxRetries = 5;

WebForms Core can also check the current connection state through the Fetch helper class.

SSE Connection State

Fetch.SSEIsConnected("/events")

The following methods are also available for managing SSE connections:

form.DisconnectSSE("/events");
form.DisconnectAllSSE();

WebSocket Connection State

Fetch.WebSocketsIsConnected("/socket")

WebSocket connections can also be explicitly removed:

form.DeleteWebSocket("/socket");

These additions provide better control over the complete lifecycle of persistent connections.

Instead of only creating SSE and WebSocket connections, applications can now more easily monitor whether connections are active, configure reconnection behavior, disconnect SSE connections individually or collectively, and remove WebSocket connections when they are no longer needed.

Retry Management for Requests

WebForms Core 2.1 provides additional control over requests that do not produce the expected result.

Developers can configure whether WebFormsJS should retry a request and define both the maximum number of retry attempts and the interval between them.

WebFormsOptions.IgnoreEmptyResult = false;

WebFormsOptions.UseRetryRequest = true;
WebFormsOptions.MaxRetryCount = 3;
WebFormsOptions.RetryRequestInterval = 3000;

In this example, WebFormsJS can retry a request up to three times, with a three-second interval between attempts.

The IgnoreEmptyResult option also provides control over how empty responses are handled.

These options provide greater flexibility when dealing with temporary connection problems or situations where a request may need to be attempted again.

Runtime Console Diagnostics

WebForms Core 2.1 provides more detailed control over diagnostic messages generated by the WebFormsJS runtime.

Developers can enable or disable general console output and individually control diagnostic messages for different parts of the runtime.

WebFormsOptions.AddConsoleMessage = true;
WebFormsOptions.UseConsoleStackTrace = false;

WebFormsOptions.AddConsoleMessageForHTTP = false;
WebFormsOptions.AddConsoleMessageForURL = true;
WebFormsOptions.AddConsoleMessageForWebSockets = true;
WebFormsOptions.AddConsoleMessageForSSE = true;
WebFormsOptions.AddConsoleMessageForModule = true;

This allows developers to control diagnostic output for:

HTTP requests
URL processing
WebSocket connections
Server-Sent Events
WebFormsJS modules

The AddConsoleMessageForHTTP feature is disabled by default. When enabled, it logs XMLHttpRequest requests to the Console.

The UseConsoleStackTrace option can also be used to control whether stack trace information is included in diagnostic output. This feature is disabled by default and when enabled, errors are displayed with additional details, such as the error line in the Console.

These options are particularly useful during development and debugging because developers can focus on specific parts of the WebFormsJS runtime instead of enabling unnecessary diagnostic output for everything.

Message, Confirm, and Alert

The message, confirm, and alert features have been rewritten.

They are now fully synchronized with the current page State.

This makes these UI interactions behave consistently with State changes and SPA navigation.

HTTP Methods

The TRACE and CONNECT methods have been removed.

The PUT method can now also send requests outside a <form> element.

This is useful because some servers may not handle the PUT method correctly with enctype="multipart/form-data" and may require POST or additional server-side configuration.

In practice, public servers have introduced non-standard limitations around this behavior.

The new PUT methods are similar to other common methods such as GET, DELETE, and PATCH.

SetPutEvent
SetPutEventListener
RemovePutEvent
RemovePutEventListener
CallPutBack

Removal of `<web-forms>`

The <web-forms> tag has been permanently removed.

Previously, this tag stored Action Control values inside the HTML itself and allowed the tag to be executed offline.

WebForms Core 2.1 removes this mechanism and retains HTML comments as the offline Action Control mechanism.

For example:

using CodeBehind;

public partial class CommentBackController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        if (context.Request.Query.ContainsKey("run_ac_in_comment"))
        {
            Button1_OnClick(context);
            return;
        }

        WebForms form = new WebForms();

        form.SetGetEventListener(
            "Button1",
            HtmlEventListener.Click,
            "?run_ac_in_comment"
        );

        form.SetCommentEvent(
            "Button2",
            HtmlEvent.OnClick,
            "1",
            "<main>"
        );

        form.SetBackgroundColor("<main>", "silver");
        form.Message("Message 1");
        form.Message("Message 2");

        form.StartIndex();
        form.Message("Message 3");
        form.Message("Message 4");

        form.StartIndex();
        form.Message("Message 5");
        form.Message("Message 6");

        form.StartIndex("Message7-8");
        form.Message("Message 7");
        form.Message("Message 8");

        Write(form.ExportToHtmlComment());
    }

    private void Button1_OnClick(HttpContext context)
    {
        WebForms form = new WebForms();

        form.CallCommentBack("Message7-8");

        IgnoreAll();
        Write(form.Response());
    }
}

The Action Controls remain inside HTML comments and can therefore be executed offline without the old <web-forms> element.

JavaScript Access with `$`

The $ character can now be used to access WebFormsJS and JavaScript data.

For example:

form.SetMethodEventListener(
    "EventListenerDblQuot",
    HtmlEventListener.Click,
    "alert",
    ["$document.getElementsByTagName('button')[1].outerHTML"]
);

The $ mechanism can be used anywhere except where an InputPlace is expected.

If $@ is used, the object itself is passed rather than its output:

form.SetMethodEvent(
    "EventDblQuot",
    HtmlEvent.OnClick,
    "alert",
    ["$@document"]
);

If you need to escape $, use two $ characters:

$$

For example, $$ represents an escaped $.

Automatic Number Conversion

In the new structure, data that can be converted to numbers is automatically added as Number.
If the output is of numeric type and you do not want it to be converted to a number, enclose the number between two single quotes (') or double quotes (").

form.SetMethodEvent("Event", HtmlEvent.OnClick, "add", ["'10'", "'24'"]);

The output of the above example is the string 1024.

Memory Management

Several improvements have been made to memory management.

A Garbage Collector-like structure has been added that now removes and manages previously allocated data more efficiently.

The new code has also been reviewed to avoid introducing memory leaks.

InputPlace and Naming Changes

The AppendPlace extension function has been renamed to:

Child

This better reflects its purpose within the InputPlace DSL.

Session, Session Cache, and Saved naming have also been removed.

From now on, only the name Save is used for sessionStorage.

Numeric Comparisons

The IsGreaterThan and IsLessThan conditions have been improved.

Numbers and strings are now correctly distinguished, allowing numerical comparisons to work properly.

For example, numeric values are no longer incorrectly compared as strings.

Query and Hash State

A new option prevents query and hash links from creating a new browser State:

WebFormsOptions.IgnoreQueryAndHashInSPALink = false;

The default value is false.

When enabled, SPA links containing query strings or hashes can be excluded from automatic State creation.

Other Features

We have already described a number of new features in version 2.1:

Added WASM Mediator support for C# programming language.

Full article:

https://dev.to/elanatframework/net-webcil-container-meets-webforms-core-21-39f5

New Morph feature.

Full article:

https://dev.to/elanatframework/morphing-feature-in-webforms-core-21-5d6o

Additional Fixes and Improvements

This release also contains many smaller improvements and fixes:

Improved performance.
Improved existing methods.
Added several new minor capabilities.
Improved Garbage Collection and data cleanup.
Fixed selection of multiple tags when only one matching tag exists.
Prevented SSE from running inside Service Workers because of an interaction conflict.
Improved IncreaseHeight.
Improved IncreaseWidth.
Fixed scrolling after clicking SPA links.
Fixed an issue where AddState could not change the title at the same time.
Fixed event registration issues in CommentBack.
Fixed changing Action Controls for InputPlace lists such as <button>*.
Fixed State support for attributes of selected tags.
Fixed State support for input, select, and textarea values.
Fixed additional requests being generated in conditional states.
Support for PATCH and DELETE when submitting a form
Better detection of browser support for compression

WebForms and WebFormsJS Patch-Version Compatibility

WebForms Core maintains compatibility across patch versions.

For example, WebForms.cs version 2.1.5 remains compatible with WebFormsJS 2.1.

The same compatibility principle applies to the other WebForms classes.

Patch versions such as 2.1.1, 2.1.2, 2.1.5, and later can contain bug fixes and improvements while remaining compatible with the WebFormsJS 2.1 core version.

It is recommended to always use the latest patch versions available.

Package Size

We used ASP.NET 10 for testing.

Because .NET 9 introduced a planned replacement of the older zlib dependency with zlib-ng, and we are using .NET 10, comparing package sizes directly with previous versions is more difficult.

The .NET team also discussed a similar issue in its official .NET 9 performance evaluation: with the compression infrastructure changing to zlib-ng, Fastest can produce noticeably larger output than the previous implementation while providing significantly faster compression. The .NET team specifically recommends reevaluating the balance between compression speed and compression ratio when using Fastest.

Therefore, while WebFormsJS 2.0 previously showed 39.59 KB with GZip + Minify under .NET 7.0 using Fastest, our new test under .NET 10 shows 47.84 KB.

CompressionLevel.SmallestSize

RAW:             411.73 kB
RAW + GZip:       63.22 kB
Minify:          179.24 kB
Minify + GZip:    43.37 kB

CompressionLevel.Fastest

RAW:             411.73 kB
RAW + GZip:      101.14 kB
Minify:          179.24 kB
Minify + GZip:    61.26 kB

As you can see, WebFormsJS 2.1 is approximately 60 KB under the ideal server-side compression configuration.

There is still a long way to go before reaching 100 KB! 😄

The Settings section is intentionally left readable.

Please note that starting with version 2.1, the Settings section is not included in Minify.

This is intentional so that developers can configure the settings more easily and have an easier time transferring and applying their configuration when upgrading to newer versions.

Conclusion

WebForms Core 2.1 is a major expansion of the technology's declarative capabilities.

The new version goes beyond basic server-driven DOM manipulation by introducing higher-level mechanisms for:

Declarative UI generation
Template rendering
URL Segments
Advanced State management
Nested conditions
Then
Repeat
ForEach
WPC criteria
Advanced element selection
Runtime option management
Debugging
Improved JSON path operations
Dynamic Action Control replacement
Improved JavaScript interoperability
Better browser history integration
Improved memory management

The goal is not to eliminate imperative development.

Instead, WebForms Core 2.1 provides higher-level abstractions where they are useful while preserving the direct, imperative capabilities of the WFC core.

This makes it possible to move between low-level DOM instructions, reusable Components, declarative conditions and loops, metadata-driven UI generation, and more advanced server-driven application architectures—all within the same technology.

CodeBehind 4.7 Released

Elanat Framework — Thu, 03 Sep 2026 18:45:37 +0000

After continued development and a strong focus on improving the integration between CodeBehind and WebForms Core, Elanat has released CodeBehind version 4.7.

This release introduces several important architectural and structural improvements designed to provide better support for WebForms Core technology, simplify MVC development, improve request processing, and increase overall framework stability.

CodeBehind 4.7 also includes an upgrade to WebForms Core version 2.1. WebForms Core 2.1 is a major update that introduces high-level capabilities and advanced features, representing another important step in the evolution of WebForms Core technology.

Features of Version 4.7

CodeBehindConstructor Merged into the PageLoad Method

In CodeBehind version 4.7, the CodeBehindConstructor method has been completely removed and its functionality has been integrated into the PageLoad method.

This change has been made to simplify the MVC development pattern and provide a more unified structure for Controllers and Models.

With the new structure, a standard Controller uses PageLoad without parentheses when it is invoked with the context.

For Models, when the Abstract option is enabled, omitting parentheses after the Model name automatically causes the context to be passed to the Model.

For non-Abstract Models defined inside triple braces, parentheses are taken into consideration when determining the method invocation. If parentheses are not specified, the PageLoad method will not be executed.

This change simplifies the MVC structure and makes initialization behavior more consistent across Controllers and Models.

Write Output Added After the View

Starting with CodeBehind version 4.7, data added to the response through the Write method in Controllers and Models is placed after the View output.

This change has been introduced to improve compliance with HTML standards. A standard HTML document begins with the <!DOCTYPE html> declaration, and placing additional output before the View can result in content being written before the expected HTML document structure.

The new behavior also provides better compatibility with WebForms Core in situations where HTML is sent together with Action Control data.

By placing Write output after the View, CodeBehind provides a cleaner response structure and better coordination between View rendering and WebForms Core processing.

Automatic Content-Type for PostBack Requests

A new configuration option named SetTextHtmlContentTypeForPostBack has been introduced to automatically set the response Content-Type header for PostBack requests.

When enabled, the response Content-Type is set to:

text/html; charset=utf-8

This provides more consistent response handling for PostBack requests and improves compatibility with WebForms Core responses that contain HTML content.

The corresponding configuration option is:

set_text_html_content_type_for_post_back=true

Separate DLL and View Paths

CodeBehind 4.7 introduces a new structure that separates the path used for DLL files from the path used for View files.

DLL files can now be stored in a location independent of the View directory. This provides greater flexibility when organizing application files and makes it possible to keep View files inside the wwwroot directory while storing compiled DLL files in a separate and more secure location.

Two new configuration options have been added to manage DLL paths.

The dll_path option specifies the directory used for DLL files.

The move_dll_from_wwwroot_bin option determines whether DLL files generated in the wwwroot/bin directory should automatically be moved to the configured DLL directory after View files are recompiled.

This separation improves application structure and provides a better distinction between publicly accessible web resources and compiled application components.

Fixed Concurrent Initial View Compilation Requests

An issue related to concurrent initial requests during the creation and compilation of View files has been resolved.

Previously, multiple requests arriving while View files were being created or compiled could result in concurrency-related problems.

The internal handling of this process has been improved to provide more reliable behavior when multiple requests reach the application during initial View compilation.

Improved Form Data Handling

CodeBehind 4.7 introduces an improvement to the way Form data is accessed from incoming requests.

Form data should now be accessed only after verifying that the request contains Form content through HasFormContentType.

This change improves request processing and prevents unnecessary attempts to read Form data from requests that do not contain Form content.

For easier and safer access, CodeBehind also provides the IfForm extension method, allowing Form data to be conditionally accessed through a simplified structure.

This provides a more convenient approach for applications that need to handle different types of incoming requests.

Improved Request Management and Framework Stability

The request management system has been improved through the use of more advanced internal mechanisms designed to prevent unexpected framework failures.

These improvements strengthen the handling of concurrent and complex requests and reduce the possibility of framework crashes caused by problematic request conditions.

The changes provide a more stable execution environment and improve the overall reliability of CodeBehind applications.

Complete Rewrite of WebSocket and SSE Middleware

The middleware and related classes responsible for WebSocket and Server-Sent Events (SSE) have been completely rewritten.

This is a significant internal improvement to the real-time communication infrastructure of CodeBehind.

The rewritten implementation provides better internal coordination, improved request and connection management, and a stronger foundation for WebSocket and SSE communication.

This change also improves the compatibility and integration of real-time communication with the latest WebForms Core architecture.

WebForms Core Technology Upgraded to Version 2.1

CodeBehind 4.7 includes an upgrade to WebForms Core version 2.1.

WebForms Core 2.1 is a major update that introduces advanced capabilities and high-level features, continuing the architectural evolution introduced with WebForms Core version 2.

This upgrade provides closer coordination between CodeBehind and WebForms Core and expands the capabilities available when building applications using the two technologies together.

WebForms Core 2.1 further develops the client-side execution architecture and provides new capabilities for building complex interactive web applications while maintaining the command-driven approach of WebForms Core.

Additional information about the features and capabilities introduced in WebForms Core version 2.1 will be published separately.

Other Improvements

CodeBehind 4.7 also includes several additional internal improvements focused on performance, stability, request processing, and compatibility with WebForms Core.

Together, these changes improve the overall architecture of the framework and provide a more reliable foundation for applications built with CodeBehind.

CodeBehind 4.7 represents an important step in the continued development of the framework, with a particular focus on simplifying MVC development, improving HTML standards compliance, strengthening request handling, separating application components, and providing deeper integration with WebForms Core.

storage_size.js Module in WebForms Core

Elanat Framework — Fri, 28 Aug 2026 14:27:36 +0000

What is WebForms Core?

WebForms Core is a modern technology from Elanat, introduced in 2024, that provides a two-way communication model between server-side code and the client-side WebFormsJS library. Its main purpose is to allow the server to control HTML elements and execute client-side operations without requiring extensive frontend code.

In this architecture, instead of sending large amounts of data or complete page structures, the server sends compact commands to the client. WebFormsJS executes these commands in the browser and can also return the result of client-side operations back to the server.

One of the important capabilities of WebForms Core is its support for JavaScript modules. Server-side code can dynamically load a JavaScript module, call its exported methods, and retrieve their return values.

This article demonstrates this capability using the storage_size.js module.

How to use WebForms Core technology?

Two steps are required.

1. On the client side

Add WebFormsJS to the page:

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

WebFormsJS is responsible for receiving WebForms Core commands and executing them in the browser.

2. On the server side

Import the WebForms class for your server-side programming language.

For this example, we use C# with the CodeBehind framework.

Server-side JavaScript Module Loading

WebForms Core allows server-side code to dynamically load JavaScript modules on the client.

The server can use:

form.LoadModule(
    "/script/module/storage_size.js",
    ["sz_GetStorageSize"]
);

This command loads the storage_size.js module and makes the sz_GetStorageSize method available for server-side invocation.

After loading the module, the server can call the method using:

Fetch.ModuleMethod(...)

This makes it possible to request information from browser APIs and return the result to the server.

Introducing the Storage Size Module

The storage_size.js module provides a simple interface for obtaining the size of different browser storage mechanisms.

The module exposes the following method:

sz_GetStorageSize(type, unit)

The first parameter specifies the storage type:

cache
cookie
indexeddb
localstorage
sessionstorage
origin

The second parameter specifies the output unit.

For example:

B
KB
MB
GB
TB

If no unit is specified, the result is returned in bytes.

For example:

sz_GetStorageSize("cache")

returns the size in bytes.

While:

sz_GetStorageSize("origin", "MB")

returns the result in megabytes.

Storage Types

The module supports several browser storage mechanisms.

Cache

The cache option calculates the size of responses stored through the Cache Storage API.

Cookie

The cookie option calculates the size of the cookies accessible through JavaScript.

IndexedDB

The indexeddb option calculates an approximate logical size of the data stored in IndexedDB.

Because browsers do not provide a standard API for obtaining the exact physical disk usage of IndexedDB, this value is an estimation based on the stored records.

Local Storage

The localstorage option calculates the size of the key/value data stored in localStorage.

Session Storage

The sessionstorage option calculates the size of the key/value data stored in sessionStorage.

Origin

The origin option uses the browser's Storage API to obtain the storage usage reported for the current Origin.

This value represents the browser-reported storage usage for the Origin and should not be considered the sum of the individual values returned by the other options.

Example Project

The example project contains the following structure:

Project Root
├── WebForms.cs
├── Controller.cs
└── wwwroot
    ├── page.aspx
    ├── layout.aspx
    ├── script
    │   ├── web-forms.js
    │   └── module
    │       └── storage_size.js

View (`page.aspx`)

The page contains a button that triggers the server-side operation:

@page
@controller ModuleStorageSizeController
@layout "/layout.aspx"
@{
    ViewData.Add("title", "Module Storage Size");
}

<h1>WebForms Core - Storage Size Module</h1>

<button id="Button1">Click me!</button>

When the button is clicked, a request is sent to the server and the server executes the module-related operation.

Server-side Controller (`Controller.cs`)

The controller contains the following code:

using CodeBehind;

public partial class ModuleStorageSizeController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        if (context.Request.Query.ContainsKey("load"))
        {
            Button1_OnClick(context);
            return;
        }

        WebForms form = new WebForms();

        form.SetGetEvent(
            "Button1",
            HtmlEvent.OnClick,
            "?load"
        );

        Write(form.ExportToHtmlComment());
    }

    private void Button1_OnClick(HttpContext context)
    {
        WebForms form = new WebForms();

        form.SetCookie(
            "test",
            "0123456789",
            3600
        );

        form.CreateFormatStorage(
            "test",
            "0123456789"
        );

        form.AddCacheValue(
            "test",
            "0123456789"
        );

        form.AddSaveValue(
            "test",
            "0123456789"
        );

        form.LoadModule(
            "/script/module/storage_size.js",
            ["sz_GetStorageSize"]
        );

        form.Message(
            "@: Cache: " +
            form.Inject(
                Fetch.ModuleMethod(
                    "sz_GetStorageSize",
                    ["cache"]
                )
            ) +
            "B"
        );

        form.Message(
            "@: Cookie: " +
            form.Inject(
                Fetch.ModuleMethod(
                    "sz_GetStorageSize",
                    ["cookie"]
                )
            ) +
            "B"
        );

        form.Message(
            "@: Indexed DB: " +
            form.Inject(
                Fetch.ModuleMethod(
                    "sz_GetStorageSize",
                    ["indexeddb"]
                )
            ) +
            "B"
        );

        form.Message(
            "@: Local Storage: " +
            form.Inject(
                Fetch.ModuleMethod(
                    "sz_GetStorageSize",
                    ["localstorage"]
                )
            ) +
            "B"
        );

        form.Message(
            "@: Session Storage: " +
            form.Inject(
                Fetch.ModuleMethod(
                    "sz_GetStorageSize",
                    ["sessionstorage"]
                )
            ) +
            "B"
        );

        form.Message(
            "@: Origin: " +
            form.Inject(
                Fetch.ModuleMethod(
                    "sz_GetStorageSize",
                    ["origin", "MB"]
                )
            ) +
            "MB"
        );

        IgnoreAll();

        Write(form.Response());
    }
}

Page Request

When page.aspx is initially requested, a new instance of ModuleStorageSizeController is created and the PageLoad method is executed.

The controller first checks whether the load query exists:

if (context.Request.Query.ContainsKey("load"))
{
    Button1_OnClick(context);
    return;
}

If the query does not exist, the server registers a GET event for the button:

form.SetGetEvent(
    "Button1",
    HtmlEvent.OnClick,
    "?load"
);

The resulting WebForms Core command is added to the page:

<!--[web-forms
EgButton1=onclick|?load
]-->

Therefore, clicking the button causes a request to the server with the load query.

`Button1_OnClick` Method

The Button1_OnClick method performs the main operation.

Its purpose is to create some browser-side storage data, load the JavaScript module, request storage sizes from the client, and display the results.

1. Create a WebForms Object

WebForms form = new WebForms();

The WebForms object is used to create the commands that will be sent between the server and client.

2. Create Test Storage Data

The example first creates data in several storage mechanisms.

Cookie

form.SetCookie(
    "test",
    "0123456789",
    3600
);

This creates a cookie containing the value:

0123456789

with a lifetime of 3600 seconds.

IndexedDB

form.CreateFormatStorage(
    "test",
    "0123456789"
);

This creates test data in the Format Storage implementation backed by IndexedDB.

Local Storage

form.AddCacheValue(
    "test",
    "0123456789"
);

This creates a value in Local Storage.

Session Storage

form.AddSaveValue(
    "test",
    "0123456789"
);

This creates a value in Session Storage.

These operations provide sample data so that the storage size module has data to inspect.

3. Load the JavaScript Module

The module is loaded using:

form.LoadModule(
    "/script/module/storage_size.js",
    ["sz_GetStorageSize"]
);

This tells WebForms Core to load:

/script/module/storage_size.js

and expose its:

sz_GetStorageSize

method.

The important point is that the server does not need to implement browser storage APIs itself. Instead, it requests the browser to execute the JavaScript module.

4. Call the Module Method

The server calls:

Fetch.ModuleMethod(
    "sz_GetStorageSize",
    ["cache"]
)

The first parameter is the module method name.

The second parameter contains the arguments that will be passed to the JavaScript method.

For example:

Fetch.ModuleMethod(
    "sz_GetStorageSize",
    ["localstorage"]
)

corresponds conceptually to:

sz_GetStorageSize("localstorage")

on the client.

5. Injecting the Module Method Result

The Fetch.ModuleMethod() function creates a command for executing a method of the loaded JavaScript module on the client side.

For example:

Fetch.ModuleMethod(
    "sz_GetStorageSize",
    ["cache"]
)

corresponds to calling:

sz_GetStorageSize("cache")

in the browser.

The Inject() method can be used together with Fetch.ModuleMethod() to insert the result of the client-side method execution into the generated WebForms Core command.

For example:

form.Message(
    "@: Cache: " +
    form.Inject(
        Fetch.ModuleMethod(
            "sz_GetStorageSize",
            ["cache"]
        )
    ) +
    "B"
);

In this example, the storage size is calculated on the client side by storage_size.js. The result is then injected into the client-side command generated by WebForms Core and used as part of the message displayed by WebFormsJS.

Therefore, no value is sent back to the server. The server only defines the module method call and constructs the command; the JavaScript module executes the operation in the browser and the result is used on the client side.

6. Getting Different Storage Sizes

The controller requests the size of Cache Storage:

Fetch.ModuleMethod(
    "sz_GetStorageSize",
    ["cache"]
)

Cookie:

Fetch.ModuleMethod(
    "sz_GetStorageSize",
    ["cookie"]
)

IndexedDB:

Fetch.ModuleMethod(
    "sz_GetStorageSize",
    ["indexeddb"]
)

Local Storage:

Fetch.ModuleMethod(
    "sz_GetStorageSize",
    ["localstorage"]
)

Session Storage:

Fetch.ModuleMethod(
    "sz_GetStorageSize",
    ["sessionstorage"]
)

And finally, the total Origin storage usage is requested in megabytes:

Fetch.ModuleMethod(
    "sz_GetStorageSize",
    ["origin", "MB"]
)

The second argument changes the unit returned by the module.

7. Sending the Response

The example uses:

IgnoreAll();

Write(form.Response());

IgnoreAll() prevents the View and Layout from being sent again.

Only the generated WebForms Core response is returned to the client.

The response contains the commands required to execute the module method calls and display their results.

Final Output

After clicking the button, the browser executes the requested module methods and the resulting values are displayed as messages.

The output is conceptually similar to:

Cache: 10B
Cookie: 14B
Indexed DB: 10B
Local Storage: 14B
Session Storage: 14B
Origin: 0.01MB

The exact values depend on the browser and the storage implementation.

In particular, the IndexedDB value is an approximation, while the Origin value is reported by the browser's Storage API.

Execution Flow

The complete execution flow can be summarized as:

Browser
   │
   │ Click Button
   ▼
Server
   │
   │ LoadModule()
   │ Fetch.ModuleMethod()
   │ Inject()
   ▼
WebForms Core Response
   │
   │ Sends module commands
   ▼
WebFormsJS
   │
   │ Load storage_size.js
   │
   │ Execute sz_GetStorageSize()
   ▼
Browser Storage APIs
   │
   │ Calculate storage size
   ▼
WebFormsJS
   │
   │ Use the returned value
   │ │
   │ └── Display through Message
   ▼
Browser

In this flow, the storage size is calculated entirely on the client side. The server does not receive the calculated value. Instead, the server creates the WebForms Core commands using LoadModule(), Fetch.ModuleMethod(), and Inject(). These commands are sent to WebFormsJS, which loads the module, executes sz_GetStorageSize(), obtains the value from the browser's storage APIs, and uses the returned value directly on the client side.

This demonstrates that a WebForms Core module method can perform a client-side operation and use its return value within the client-side execution of the generated WebForms Core commands, without requiring another request to the server.

Summary

The storage_size.js module demonstrates how WebForms Core can use reusable JavaScript modules to perform browser-side operations under server-side control.

The server dynamically loads the module with LoadModule() and defines calls to sz_GetStorageSize() using Fetch.ModuleMethod(). When the WebForms Core response is processed by WebFormsJS, the module is loaded in the browser and the requested method is executed using the browser's Storage APIs.

The result of the module method is used directly on the client side through the generated WebForms Core commands. No additional request is required to send the calculated storage size back to the server.

This architecture allows browser-specific functionality to remain inside reusable JavaScript modules while the server controls when the module is loaded, which methods are invoked, and how their results are used in the client-side response.

The storage_size.js example demonstrates how this approach can be used to work with Cache Storage, Cookies, IndexedDB, Local Storage, Session Storage, and Origin storage usage without requiring a large client-side framework.

Morphing Feature in WebForms Core 2.1

Elanat Framework — Wed, 26 Aug 2026 18:31:27 +0000

WebForms Core 2.1 is coming soon from Elanat. The new version introduces a collection of capabilities designed to further expand the server-driven approach of WebForms Core. One of these new capabilities is Morphing.

Morphing provides a way to synchronize an existing DOM element with a new HTML structure without necessarily replacing the existing element itself.

This makes it possible to update HTML structures while preserving the identity of existing DOM elements.

Morphing

Morphing is a DOM synchronization mechanism that compares an existing HTML element with a new HTML structure and applies the required changes to the existing DOM.

Unlike a traditional replacement operation such as:

element.outerHTML = html;

Morphing does not simply discard the existing element and create another one.

Instead, it analyzes the existing element and the new element and performs the necessary operations:

Add new attributes
Update existing attributes
Remove attributes that no longer exist
Add new child elements
Update existing child elements
Remove obsolete child elements
Match elements using id and cb-data-id
Preserve existing DOM element identity whenever possible
Preserve registered event listeners when new Nodes have to be created

The goal is to make the smallest necessary changes to the DOM.

Reflection vs Morphing

WebForms Core 2.1 contains both Reflection and Morphing, but they serve different purposes.

Reflection is primarily a merge operation.

For example, if the target contains:

<div id="userCard">
    <h3>User</h3>
</div>

and the source contains:

<div class="premium">
    <button>VIP</button>
</div>

Reflection can merge the source into the target, adding the class and child without treating the source as a complete replacement definition.

Morphing has a different philosophy.

The source represents the desired structure.

If the source does not contain an element or attribute that exists in the target, Morphing can remove it.

Therefore:

Reflection
    Target + Source
         ↓
       Merge

Morphing
    Target → Source
         ↓
      Synchronize

This distinction makes both mechanisms useful for different types of server-driven UI operations.

The WebForms Core API

Morphing can be invoked from the WebForms class.

The first method accepts HTML directly:

SetMorph(string InputPlace, string Tag)

The second method uses an existing element as the source:

SetMorphByOutputPlace(string InputPlace, string OutputPlace)

For example:

form.SetMorphByOutputPlace(
    "userCard",
    "userCardTemplate"
);

Here:

userCard is the destination element.
userCardTemplate is the source element.

The developer does not need to manually write JavaScript to perform the DOM synchronization.

A Complete Example

Consider the following page.

Initially, the page contains a user card:

<div id="userCard"
     class="card"
     data-user="123"
     style="border: 1px solid #ccc; padding: 10px;">

    <h3>User</h3>

    <p id="userEmail">
        Email: user@example.com
    </p>

    <button id="editButton"
            class="btn-edit"
            onclick="editUser()">
        Edit
    </button>

    <span id="oldTag">
        Old tag
    </span>

</div>

A template describes the new state of this element:

<template id="userCardTemplate">

    <div id="userCard"
         class="card premium"
         data-user="456"
         data-role="admin"
         style="background-color: #f0f8ff; border: 2px solid blue; margin: 5px;">

        <h3>User</h3>

        <button id="editButton"
                class="btn-vip"
                onclick="VIP()">
            VIP
        </button>

        <span id="newTag">
            New tag
        </span>

    </div>

</template>

The controller can perform the Morph operation with:

using CodeBehind;

public partial class MorphController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        // Checking "Post-Back" in Request Headers for Maintain Interactive mode when Refreshing the Page in the Browser.
        if (context.Request.Query.ContainsKey("set-morph") && context.Request.Headers.ContainsKey("Post-Back"))
        {
            SetMorph_OnClick(context);
            return;
        }
    }

    private void SetMorph_OnClick(HttpContext context)
    {
        WebForms form = new WebForms();

        form.SetMorphByOutputPlace("userCard", "userCardTemplate");

        IgnoreAll();
        Write(form.Response());
    }
}

The page can trigger the operation with a normal WebForms Core request:

<a href="?set-morph">Click to Link for Morph</a>

What happens during Morphing?

Before Morphing, the target is:

<div id="userCard"
     class="card"
     data-user="123"
     style="border: 1px solid #ccc; padding: 10px;">

    <h3>User</h3>

    <p id="userEmail">
        Email: user@example.com
    </p>

    <button id="editButton"
            class="btn-edit"
            onclick="editUser()">
        Edit
    </button>

    <span id="oldTag">
        Old tag
    </span>

</div>

The source describes:

<div id="userCard"
     class="card premium"
     data-user="456"
     data-role="admin"
     style="background-color: #f0f8ff; border: 2px solid blue; margin: 5px;">

    <h3>User</h3>

    <button id="editButton"
            class="btn-vip"
            onclick="VIP()">
        VIP
    </button>

    <span id="newTag">
        New tag
    </span>

</div>

Morphing compares these two structures and applies the necessary changes.

The resulting DOM becomes:

<div id="userCard"
     class="card premium"
     data-user="456"
     style="background-color: #f0f8ff; border: 2px solid blue; margin: 5px;"
     data-role="admin">

    <h3>User</h3>

    <button id="editButton"
            class="btn-vip"
            onclick="VIP()">
        VIP
    </button>

    <span id="newTag">
        New tag
    </span>

</div>

Attribute Morphing

Attributes are synchronized between the target and source.

For example:

data-user="123"

becomes:

data-user="456"

The new attribute:

data-role="admin"

is added.

The class:

class="card"

becomes:

class="card premium"

And the style is updated according to the source.

Attributes that exist in the target but no longer exist in the source are removed.

Therefore Morphing effectively synchronizes the attribute set:

Target attributes
        ↓
     Compare
        ↓
Source attributes
        ↓
Add / Update / Remove

Child Element Morphing

Morphing also operates recursively on child Nodes.

In the example, this element:

<p id="userEmail">
    Email: user@example.com
</p>

does not exist in the new structure.

Therefore it is removed.

Likewise:

<span id="oldTag">
    Old tag
</span>

is removed.

At the same time:

<span id="newTag">
    New tag
</span>

is added.

The existing:

<h3>User</h3>

is retained and synchronized.

Element Matching

One of the important parts of Morphing is determining whether a new element corresponds to an existing element.

WebForms Core uses identifiers such as:

id="editButton"

and:

cb-data-id="..."

for this purpose.

For example, both the old and new structures contain:

<button id="editButton">

Therefore Morphing can recognize that they represent the same DOM element.

The existing Node can consequently be retained while its attributes and contents are updated.

This is different from simply deleting the old button and creating a completely new button.

Event Listeners

DOM cloning has an important limitation:

cloneNode(true)

does not copy event listeners registered through addEventListener.

WebForms Core Morphing therefore integrates with the WebForms Core event registry.

When Morphing needs to create a new Node, registered event listeners can be transferred to the new Node.

This is particularly important for applications that dynamically update their interface while maintaining interactive behavior.

The principle is:

Existing Node
      ↓
Keep Node
      ↓
Keep its event listeners

New Node
      ↓
Create Node
      ↓
Transfer registered listeners

This allows Morphing to modify the DOM without unnecessarily destroying its interactive state.

Why use `<template>`?

A <template> element is particularly convenient as the source of a Morph operation.

For example:

<template id="userCardTemplate">

    <div id="userCard">
        ...
    </div>

</template>

The template provides a declarative representation of the desired HTML structure without displaying that structure directly on the page.

This makes it possible to separate:

Visible DOM
     +
Desired DOM structure

while keeping the desired structure inside the HTML document.

WebForms Core can use the internal content of the template as the source of the Morph operation.

Morphing is not DOM Replacement

A conventional replacement might effectively perform:

element.replaceWith(newElement);

The consequence is that the original DOM element is destroyed.

Morphing instead attempts to preserve the existing element:

Replace:

OLD NODE
   ↓
destroy
   ↓
NEW NODE


Morph:

OLD NODE
   ↓
compare
   ↓
modify
   ↓
same NODE

This distinction becomes particularly useful for interactive interfaces.

An element can have:

browser state
registered event listeners
references from application code
associated DOM state

and Morphing can update its structure without necessarily discarding the element itself.

Server-Driven UI

Morphing fits naturally into the architecture of WebForms Core.

The server does not need to send an entire page.

Instead, it can describe the desired UI operation:

form.SetMorphByOutputPlace(
    "userCard",
    "userCardTemplate"
);

WebForms Core then performs the DOM synchronization on the client.

This follows the broader WebForms Core philosophy of treating communication between server and browser as an instruction stream rather than simply transferring complete HTML documents.

The server determines what operation should happen, while WebForms Core performs that operation in the browser.

Morphing vs Reflection

The two capabilities can be summarized as follows:

Feature	Reflection	Morphing
Preserve target element	Yes	Yes
Add attributes	Yes	Yes
Update attributes	Yes	Yes
Remove obsolete attributes	No, merge-oriented	Yes
Add children	Yes	Yes
Update children	Limited/merge-oriented	Yes
Remove obsolete children	No	Yes
Recursive synchronization	No/limited	Yes
Match by `id` / `cb-data-id`	—	Yes
Preserve DOM identity	Yes	Yes
Intended purpose	Merge	Synchronize

In simple terms:

Reflection merges. Morphing synchronizes.

Conclusion

Morphing in WebForms Core 2.1 provides a declarative way to transform an existing DOM structure into a new structure while minimizing unnecessary DOM replacement.

Instead of manually writing JavaScript to:

find element
→ compare attributes
→ remove attributes
→ update attributes
→ find children
→ remove children
→ create children
→ preserve events

the server can simply describe the desired operation:

form.SetMorphByOutputPlace(
    "userCard",
    "userCardTemplate"
);

WebForms Core performs the synchronization on the client.

With Reflection for merging and Morphing for structural synchronization, WebForms Core 2.1 adds two complementary mechanisms for declaratively manipulating the DOM from server-side code—without requiring a conventional front-end framework.

.NET WebCIL Container Meets WebForms Core 2.1

Elanat Framework — Wed, 26 Aug 2026 14:02:10 +0000

What is WebForms Core?

WebForms Core is a modern multi-platform web technology from Elanat designed to build interactive web applications without requiring traditional client-side business logic.

WebForms Core uses a server-centric architecture in which the server defines UI behavior through commands, while a lightweight client engine executes those commands in the browser.

With the upcoming WebForms Core 2.1 (WFC), this architecture is being extended with another interesting capability: C# code running inside a .NET WebAssembly environment can use WebForms Core itself to generate UI commands.

This makes it possible to combine:

C#
.NET WebAssembly
WebForms Core
WebForms Core's declarative UI commands

inside the same WebAssembly application.

.NET WebCIL Container

One of the new possibilities demonstrated with WFC 2.1 is the use of a .NET WebCIL Container.

Instead of compiling C# into a standalone native-style WASM function such as:

add(10000, 3)

the application can load the .NET WebAssembly runtime and execute exported C# methods through dotnet.js.

For example:

using System.Runtime.InteropServices.JavaScript;
using WebFormsCore;

public partial 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>";
    }
}

public class Program
{
    public static void Main()
    {
    }
}

The important part is that WebForms.cs from WebForms Core is included in the WebAssembly project.

Therefore, C# code running inside the WebAssembly environment can directly create WebForms Core commands.

Creating the .NET WebCIL Project

Create a new .NET 10 WebAssembly console project:

dotnet new wasmconsole -n NativeWasmModule -f net10.0

Then enter the project:

cd NativeWasmModule

The project can use the following configuration:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <WasmEnableExceptionHandling>false</WasmEnableExceptionHandling>
    <RuntimeIdentifier>browser-wasm</RuntimeIdentifier>
    <OutputType>Exe</OutputType>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <WasmMainJSPath>main.mjs</WasmMainJSPath>
  </PropertyGroup>

</Project>

The project targets:

<TargetFramework>net10.0</TargetFramework>

and uses:

<RuntimeIdentifier>browser-wasm</RuntimeIdentifier>

The main.mjs file is specified as the JavaScript entry point:

<WasmMainJSPath>main.mjs</WasmMainJSPath>

Adding WebForms Core

The WebForms.cs class from WebForms Core is added to this project.

This is important because the WebAssembly C# code is now capable of using WebForms Core's API.

For example:

WebForms form = new WebForms();

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

return form.Response();

The C# method doesn't directly manipulate the browser DOM.

Instead, it generates a WebForms Core response.

This keeps the same philosophy used throughout WebForms Core.

Exporting C# Methods

Methods that should be accessible from JavaScript are marked with:

[JSExport]

For example:

[JSExport]
public static int Add(int a, int b)
{
    return a + b;
}

The method can then be accessed through the .NET WebAssembly runtime.

A method can also return a WebForms Core response:

[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();
}

This is where the combination becomes particularly interesting.

The WASM code isn't merely calculating a value.

It can generate WebForms Core UI behavior.

Using C# WebAssembly from WebForms Core

A WebForms Core controller can invoke the C# WebAssembly runtime:

using CodeBehind;

public partial class CsharpMediatorWasmController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {
        string WasmPath = "/web-assembly/csharp-publish/_framework/dotnet.js";

        WebForms form = new WebForms();

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

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

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

        Write(form.ExportToHtmlComment());
    }
}

Notice the method names:

MyClass.Add
MyClass.SetData
MyClass.GetHtml

The class name can be specified before the method name.

This makes it possible to address exported methods belonging to different C# types.

HTML

The HTML remains simple:

@page
@controller CsharpMediatorWasmController
@layout "/layout.aspx"

@{
    ViewData.Add("title", "C# Mediator Wasm");
}

<h3>.NET WebCIL Container</h3>

<b>C# Mediator 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 custom WebAssembly element.

There is no special DOM component.

There is no C# component syntax.

The HTML remains standard HTML.

The Interesting Part

Consider this:

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

The server declares:

When this button is clicked, execute MyClass.SetData inside the C# WebAssembly runtime.

The method executes:

WebForms form = new WebForms();

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

return form.Response();

The result is then handled by WebForms Core.

The C# WebAssembly method therefore becomes another source of WebForms Core commands.

WASM Event With Output

The same mechanism can return HTML:

[JSExport]
public static string GetHtml()
{
    return "<marquee>Tag From Wasm!</marquee>";
}

and:

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

The returned value is placed into:

<p id="WasmHtmlOutput"></p>

This demonstrates that the WASM method can be used not only for calculations, but also as a source of dynamic UI output.

The screenshot below shows the HTML page after clicking the buttons.

What Makes This Different?

This is not simply:

"Run C# in the browser."

That capability already exists.

The interesting part is the combination of C# WebAssembly and WebForms Core.

A C# method running inside WebAssembly can use:

WebForms

and produce WebForms Core commands.

That creates a pipeline like this:

C# WebAssembly
      ↓
  WebForms.cs
      ↓
WebForms Core Response
      ↓
WebForms Core Client Engine
      ↓
     DOM

The WebAssembly code does not need to know how the browser DOM is implemented.

It can describe the desired UI behavior through WebForms Core.

Native WASM and .NET WebCIL Are Different

WebForms Core can work with different types of WebAssembly environments.

For example, a native WASM module may expose a function such as:

add

and can be loaded directly as a .wasm module.

The .NET approach is different.

With the .NET WebCIL environment, the entry point is:

dotnet.js

and the .NET runtime loads the necessary WebAssembly components.

Therefore:

Native WASM
     ↓
module.wasm
     ↓
WebAssembly.instantiate()

is conceptually different from:

.NET WebAssembly
     ↓
dotnet.js
     ↓
.NET runtime
     ↓
C# exported method

WebForms Core can provide an abstraction over these different execution models.

No JavaScript Business Logic

One of the most interesting properties of this example is that the application does not require custom JavaScript business logic.

The C# code contains:

public static string SetData(...)
{
    WebForms form = new WebForms();

    form.SetText(...);
    form.SetBackgroundColor(...);
    form.SetFontSize(...);

    return form.Response();
}

The HTML contains:

<button id="WasmEvent">
    Wasm Event
</button>

And the WebForms Core server code connects them:

form.SetWasmEvent("WasmEvent", HtmlEvent.OnClick, WasmLanguage.CSharpMediator, WasmPath, "MyClass.SetData", [...]);

The application logic remains in C#.

WebForms Core 2.1

WebForms Core 2.1, or simply WFC, is coming soon.

This release expands the possibilities of WebForms Core by allowing WebAssembly methods to participate more deeply in the WebForms Core execution model.

The .NET WebCIL scenario is particularly interesting because developers can write C# methods such as:

[JSExport]
public static string SetData(...)

and use the existing WebForms Core API inside those methods.

This means that the same WebForms Core command model can be used from:

Server-side C#
C# WebAssembly
Native WebAssembly modules
Other WASM-capable languages

while the browser continues to use the WebForms Core client engine (WebFormsJS).

Final Result

This example demonstrates a new direction for WebForms Core:

C# WebAssembly can become an execution layer for WebForms Core rather than simply a replacement for JavaScript.

The architecture can be summarized as:

              WebForms Core
                    │
        ┌───────────┴───────────┐
        │                       │
     Server                 WebAssembly
        │                       │
   WebForms.cs               C# / WASM
        │                       │
        └───────────┬───────────┘
                    ↓
          WebForms Core Commands
                    ↓
               Browser DOM

And perhaps the most interesting point is this:

WebAssembly does not have to replace the WebForms Core model. It can become another execution environment for it.

That opens the door to using high-performance compiled languages and .NET WebAssembly together with the declarative command architecture of WebForms Core.

WebForms Core 2.1 is coming soon!

WebForms Core vs Blazor WebAssembly

Compared with Blazor WebAssembly, this approach in WebForms Core is not intended to run a complete .NET application in the browser. Instead, it can invoke a specific C# method as a WASM capability and return its result to WebForms Core. In the example above, MyClass.Add, MyClass.SetData, and MyClass.GetHtml are executed only when they are actually needed. Therefore, the architecture is much closer to a WASM Function Runtime than to a WASM-based SPA. Furthermore, by using WebForms within the C# code, even UI modification logic can be defined directly inside the C# method, with its output then passed to the WebForms Core engine.

In contrast, Blazor WASM provides a complete programming model for building .NET user interfaces in the browser, with a significant portion of the application logic and required runtime running on the client. WebForms Core can take a different approach: HTML remains standard HTML, WebForms Core manages UI behavior, and WASM is used only when specific capabilities need to be executed. Therefore, the two are not necessarily direct competitors. Blazor WASM primarily focuses on running .NET applications in the browser through WebAssembly, whereas WebForms Core is not limited to WebAssembly and provides a broader architecture for developing and executing web behavior.

CodeBehind 4.7 Coming Soon

Elanat Framework — Mon, 06 Jul 2026 05:50:11 +0000

CodeBehind 4.7 will be released by Elanat in the coming days. This release introduces several important improvements that enhance support for and integration with WebForms Core (WFC). It also upgrades WebForms Core to version 2.1. WFC 2.1 is a major update that introduces many new features and improvements.

CodeBehindConstructor has been removed

In CodeBehind 4.7, the CodeBehindConstructor method has been completely removed and merged into the PageLoad method. This change simplifies the MVC programming model.

In the new syntax, when the controller name is specified without parentheses, HttpContext is automatically passed to PageLoad.

Controller Examples

Example 1

View

@page
@controller MyController

Controller

using CodeBehind;

public partial class MyController : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {

    }
}

Example 2

View

@page
@controller MyController()

Controller

using CodeBehind;

public partial class MyController : CodeBehindController
{
    public void PageLoad()
    {

    }
}

Example 3

View

@page
@controller MyController(123, "value")

Controller

using CodeBehind;

public partial class MyController : CodeBehindController
{
    public void PageLoad(int i, string s)
    {

    }
}

For abstract models, specifying the model name without parentheses automatically passes HttpContext to PageLoad. For non-abstract models declared inside curly braces ({}), PageLoad is invoked only when parentheses are specified.

Model Examples

Example 1

View

@page
@model MyModel
<h1>@Value1</h1>
<h2>@Value2</h2>

Model

using CodeBehind;

public partial class MyModel : CodeBehindModel
{
    public string Value1 { get; set; }
    public string Value2 { get; set; }

    public void PageLoad(HttpContext context)
    {

    }
}

Example 2

View

@page
@model MyModel()
<h1>@Value1</h1>
<h2>@Value2</h2>

Model

using CodeBehind;

public partial class MyModel : CodeBehindModel
{
    public string Value1 { get; set; }
    public string Value2 { get; set; }

    public void PageLoad()
    {

    }
}

Example 3

View

@page
@model MyModel("ABC")
<h1>@Value1</h1>
<h2>@Value2</h2>

Model

using CodeBehind;

public partial class MyModel : CodeBehindModel
{
    public string Value1 { get; set; }
    public string Value2 { get; set; }

    public void PageLoad(string s)
    {

    }
}

Example 4

View

@page
@model {MyModel}
<h1>@Value1</h1>
<h2>@Value2</h2>

Model

public class MyModel
{
    public string Value1 { get; set; }
    public string Value2 { get; set; }
}

Example 5

View

@page
@model {MyModel()}
<h1>@Value1</h1>
<h2>@Value2</h2>

Model

public class MyModel
{
    public string Value1 { get; set; }
    public string Value2 { get; set; }

    public void PageLoad()
    {

    }
}

Example 6

View

@page
@model {MyModel(123, 'c')}
<h1>@Value1</h1>
<h2>@Value2</h2>

Model

public class MyModel
{
    public string Value1 { get; set; }
    public string Value2 { get; set; }

    public void PageLoad(int i, char c)
    {

    }
}

Constructor Behavior

Controller Behavior

Syntax	Behavior
`@controller MyController`	Creates the controller and automatically passes `HttpContext` to `PageLoad(HttpContext context)`.
`@controller MyController()`	Creates the controller and calls `PageLoad()` with no arguments.
`@controller MyController(args)`	Creates the controller and calls `PageLoad(args)`.

Abstract Model Behavior

Syntax	Behavior
`@model MyModel`	Creates an abstract model and automatically passes `HttpContext` to `PageLoad(HttpContext context)`.
`@model MyModel()`	Creates an abstract model and calls `PageLoad()` with no arguments.
`@model MyModel(args)`	Creates an abstract model and calls `PageLoad(args)`.

Model Behavior

Syntax	Behavior
`@model {MyModel}`	Creates a plain model only. `PageLoad` is not called.
`@model {MyModel()}`	Creates a plain model and calls `PageLoad()` with no arguments.
`@model {MyModel(args)}`	Creates a plain model and calls `PageLoad(args)`.

Write Output at the End of the Page

Beginning with CodeBehind 4.7, data written by calling the Write method from the Controller or Model is appended to the end of the View instead of being inserted at the beginning.

This change ensures compliance with HTML standards, as an HTML document is expected to begin with <!DOCTYPE html>.

It also improves compatibility with WFC technology when HTML is sent together with Action Control data.

The following example shows the difference between the behavior of Write in CodeBehind 4.7 and earlier versions.

View

@page
@controller TextBoxController
<!DOCTYPE html>
<html>
<head>
    <title>CodeBehind Framework - Using WFC Technology</title>
    <script type="module" src="/script/web-forms.js" defer></script>
</head>
<body>

    <input id="TextBox1" type="text" placeholder="Write Color" />

</body>
</html>

Controller

using CodeBehind;

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

        form.SetGetEvent("TextBox1", HtmlEvent.OnKeyUp, "/keyup");

        Write(form.ExportToHtmlComment());
    }
}

HTML output in CodeBehind 4.7

<!DOCTYPE html>
<html>
<head>
    <title>CodeBehind Framework - Using WFC Technology</title>
    <script type="module" src="/script/web-forms.js" defer></script>
</head>
<body>

    <input id="TextBox1" type="text" placeholder="Write Color" />

</body>
</html>
<!--[web-forms]
EgTextBox1=onkeyup?keyup-->

HTML output in CodeBehind version 4.6 and earlier

<!--[web-forms]
EgTextBox1=onkeyup?keyup-->
<!DOCTYPE html>
<html>
<head>
    <title>CodeBehind Framework - Using WFC Technology</title>
    <script type="module" src="/script/web-forms.js" defer></script>
</head>
<body>

    <input id="TextBox1" type="text" placeholder="Write Color" />

</body>
</html>

Automatic Content-Type

A new option automatically sets the response Content-Type header to text/html; charset=utf-8 for PostBack requests.

In some cases, when the server response is not valid XML, the browser attempts to parse it as XML and logs the following error in the console:

XML Parsing Error: no root element found

This error typically occurs when the response is empty or when it does not contain a valid XML document.

To prevent this, enable the following option:

...
ignore_layout_for_post_back=false
+set_text_html_content_type_for_post_back=true
sse_interval=1000
...

When enabled, the framework sets the response Content-Type header to text/html; charset=utf-8, preventing the browser from attempting to parse the response as XML and eliminating the parsing error.

The set_text_html_content_type_for_post_back option is enabled by default.

Separate DLL Paths

DLL and View paths can now be configured independently.
This allows View files to remain under wwwroot while DLLs are stored in a secure directory.

Two new options have been added to the Options file (options.ini) to manage the DLL path.

[CodeBehind-options]
view_path=wwwroot
move_view_from_wwwroot=true
+dll_path=wwwroot/bin
+move_dll_from_wwwroot_bin=true
rewrite_aspx_file_to_directory=false
access_aspx_file_after_rewrite=false
...

When move_dll_from_wwwroot_bin is enabled, DLL files are automatically moved from wwwroot/bin to the directory specified by dll_path after the View files are recompiled.

Conclusion

CodeBehind 4.7 is a significant step forward in refining the framework. Rather than focusing solely on new features, this release improves the overall developer experience by simplifying the API, making framework behavior more consistent, introducing a cleaner MVC programming model, improving integration with WebForms Core (WFC), and providing more flexible project deployment options.

These improvements make CodeBehind more intuitive, maintainable, and better suited for building modern web applications.

WebForms Core 2.1 - Coming Soon!

Elanat Framework — Wed, 10 Jun 2026 21:56:47 +0000

Elanat Development Team

We are proud to announce that version 2.1 of the WebForms Core technology will be released soon. This is a major update, built after 4 months of hard work by the Elanat team.

Update Strategy

Updates in WebForms Core technology are performed sequentially in increments of one-tenth (0.1). We started with version 1.0, the next version was 1.1, and each time we added one-tenth to the version number. The update of the WebForms class on the server side (C# programming language) is performed simultaneously with the update of the WebFormsJS library on the client side. Currently, version 2.1 has been released for both, and they are in complete harmony.

One-hundredth updates (such as 2.0.1) are considered minor updates; these updates do not add new features that require changes in the other part, and they will remain compatible with the same major version.

Please note that the WFC technology is first released for the WebForms class in the C# programming language, and then it will be ported to popular web programming languages.

Version 2.1; Another Major Update

Version 2.1, like the previous two versions, is a major and foundational update. This release includes significant changes and improvements that elevate the development experience with WebForms Core to a higher level. Using advanced methods in this version significantly reduces the number of required instructions.

Most Important Innovations in Version 2.1

High-Level Declarative Features

This version creates a higher abstraction over the WFC core. Developers can now benefit from declarative development alongside imperative development.

New ForEach Capability

In version 2.1, the powerful ForEach feature has been added to WFC technology. There is no longer any need to use GoTo statements or manually create and delete data.

Fundamental Change in Separator

One of the most important changes in this version concerns the Separator. In version 2.1, the Vertical bar character (|) along with the comma character (,) have been removed as separators, replaced by characters number 28, 29, 30, and 31 in ASCII codes 128. From now on, there will be no conflicts or disruptions in this area.

New Template Engine

The template rendering system is a new declarative structure that replaces repetitive, imperative Replace operations. This engine automatically and intelligently places data into HTML templates.

Advanced Storage Capabilities

New capabilities have been added for managing stored JSON data, providing great flexibility in all four CRUD operations.

Significant State Management Improvements

State in version 2.1 works more stably. SPA links now automatically control browser history in a manner completely consistent with regular links. The performance of the browser's Back and Forward buttons has also been optimized.

Segment Capability for URL and Hash

A new feature that helps you create much more powerful SPA systems. This mechanism is also automatically activated for links.

Dedicated Debugger

A powerful debugging tool has been added to this release, providing step-through debugging for Action Controls code. You will experience Step, Go, Start, Stop, and Pause directly in your browser!

Advanced JSON Operations

In version 2.1, working with JSON data has become much more professional. Conditional queries and negative indexing for JSON paths are now possible.

New Replace Capabilities

Several new Replace methods have been added in this version to give you greater control over Action Controls instructions.

Security and Performance Improvements

This release includes numerous security and performance improvements. WebForms responses have been optimized, and issues related to events and Action Controls have been resolved. Additionally, the ability to display animations during initial page load has been added to the settings.

A Growing Technology

WebForms Core is a living and dynamic technology. The Elanat team is constantly improving and adding new features to this powerful technology. For this reason, it is always recommended to use the latest versions of this technology.

Version 2.1 is coming soon. Stay tuned!

Using the Segment Feature

Elanat Framework — Fri, 27 Feb 2026 21:28:20 +0000

Segment is an attribute that can be applied to ASPX pages. When this feature is enabled, all path parts that appear after the aspx file path are treated as segments and routed to the same executing page. Segment is one of the innovative ideas of the Elanat team. By enabling Segment, you gain full control over URL paths.

Enabling Segment

Razor Syntax

@page
+@segment
<!DOCTYPE html>
<html>
...

Standard ASPX Syntax

<%@ Page Segment="true" %>
<!DOCTYPE html>
<html>
...

How Segment Works

If you enable Segment on the following path:

/page/about.aspx

Any additional path parts after this address will be considered segments, and the executable file /page/about.aspx will still be executed.

Example

/page/about.aspx/segment1/segment2/.../segmentN

If Segment is enabled on a file such as:

/page/about/Default.aspx

You can still access it using both of the following formats:

/page/about/Default.aspx/segment1/segment2/.../segmentN

/page/about/segment1/segment2/.../segmentN

Accessing Segment Values

You can access Segment values in all three layers: View, Controller, and Model.

Segments are zero-based indexed.

Given the URL:

/page/about/segment1/segment2/segment3

Segment.GetValue(0) returns "segment1"
Segment.GetValue(1) returns "segment2"
Segment.GetValue(2) returns "segment3"

In general:

Segment.GetValue(n)

returns the segment at index n (starting from 0).

Example in View (Razor)

<b>segment 1 is: @Segment.GetValue(0)</b>
<b>segment 2 is: @Segment.GetValue(1)</b>

Example in View (Standard ASPX)

<b>segment 1 is: <%= Segment.GetValue(0) %></b>
<b>segment 2 is: <%= Segment.GetValue(1) %></b>

Example in Controller

using CodeBehind;

namespace YourProjectName
{
    public partial class DefaultController : CodeBehindController
    {
        public void PageLoad(HttpContext context)
        {
+           Write(Segment.GetValue(0));
+           Write(Segment.GetValue(1));
        }
    }
}

By activating Segment, you no longer need to use query strings to pass parameters through the URL.

Important Behavior

If you enable Segment on a specific path, ASPX view files located in its subdirectories will not be executed.

Example

If Segment is enabled on:

/page/about/Default.aspx

Then the following path will no longer be accessible:

/page/about/license/Default.aspx

Checking Segment Existence

You can use the Exist method to check whether a segment value exists before accessing it.

@if (!Segment.Exist(0))
{
    <b>Value does not exist</b>
}

Segment in Default MVC Configuration

In the default MVC configuration, the Segment feature is enabled automatically in controller routing.

using CodeBehind;

public partial class user : CodeBehindController
{
    public void PageLoad(HttpContext context)
    {   
        Write(Segment.GetValue(0)); // path: /user/{id}
    }
}

Rewrite ASPX Path as Directory

One of the interesting ideas introduced by the Elanat team in the CodeBehind framework is the ability to rewrite an aspx file path as a directory name.

When this option is enabled, routes leading to an aspx file without the .aspx extension will be treated as directory paths.

[CodeBehind options]; do not change order
...
rewrite_aspx_file_to_directory=true
...

Note: You can safely enable this option because this rewrite does not introduce any additional processing load.

Example

Access:

/page/contact.aspx

Using:

/page/contact

And also:

/page/contact/segment1/segment2/.../segmentN

🎬 Video - Using WebForms Core in ASP.NET MVC

Elanat Framework — Fri, 27 Feb 2026 12:47:45 +0000

In this video, we will teach you how to configure and use Elanat's WebForms Core technology in ASP.NET MVC.

Is Blazor a Replacement for WebForms?

Microsoft officially presents it as such, but the technical reality is more nuanced:

Blazor = Component-Based Framework
WebForms = Event-Driven Page Model

These two are built on fundamentally different architectural philosophies.

📌 Blazor is not a technical replacement for WebForms; it is a strategic replacement.

Blazor is designed around a component-based architecture, whereas WebForms was built on a page-centric, event-driven model. Therefore, they cannot be considered equivalent.

The WebForms Core Perspective on Modern Architecture

WebForms Core does not “destroy” the separation between front-end and back-end;
it abstracts it.

Instead of forcing developers to build and maintain two separate projects using two different languages, this architecture turns the front-end into an execution layer that is controlled entirely from the server-side language.

In this approach, user interactions remain modern, dynamic, and refresh-free, while the complexity of managing front-end code is removed or hidden from the developer.

From AJAX to WebForms Core

Technologies like AJAX in 2005 created a major shift in web development by enabling data exchange without requiring a full page refresh.

WebForms Core can be seen as the most evolved continuation of that path — a transition from:

“Interaction without page refresh”

“Interaction without direct front-end coding.”

This is not merely a tooling change;
it represents a shift in development philosophy.

ViewData in CodeBehind: Data Transfer Across MVC Components

Elanat Framework — Fri, 27 Feb 2026 09:33:28 +0000

The ViewData feature in the CodeBehind framework, developed by Elanat, is a simple and practical mechanism for transferring data between different components of the MVC architecture.

What is ViewData?

ViewData is a data list of type NameValue (Key-Value).
This structure allows you to store data with a specific key and retrieve it in other parts of the same request.

ViewData is used to transfer data between MVC components and supports both reading and writing in the following sections:

Controller
Model
View
Layout

ViewData Lifetime

An important point to consider is that the data stored in ViewData is valid only during the current HTTP request.

This means that once the request is completed and the response is sent to the client, the ViewData values are cleared and will not be available in subsequent requests.

Comparison with ASP.NET

The overall behavior of ViewData in CodeBehind is very similar to ViewData in:

ASP.NET MVC
ASP.NET Razor Pages

If you have previously worked with these technologies, using ViewData in CodeBehind will feel familiar and intuitive.

Writing Priority in ViewData

The writing priority order in ViewData is as follows:

Controller
Model
View

This reflects the execution flow of the MVC pattern.

If a new ViewData value is created inside the View, it cannot be read in the Controller, because the Controller executes before the View.

Example: Using ViewData in a View

In the following example, the title value is set inside the View:

@page
@controller CacheThemeController
@layout "/layout.aspx"
@{
  ViewData.Add("title","Cache Theme");
}

Here, the value "Cache Theme" is stored with the key "title".

Accessing ViewData in a Layout

The stored value can be retrieved inside the Layout file:

@page
@islayout
@{
    string WelcomeText = "Welcome to the CodeBehind Framework!";
}
<!DOCTYPE html>
<html>
<head>
    <title>CodeBehind Framework - @ViewData.GetValue("title")</title>

In this example, the title value defined in the View is accessed in the Layout and displayed inside the <title> tag.

Using ViewData in a Controller

You can also assign values inside a Controller:

public void PageLoad(HttpContext context)
{   
    ViewData.Add("name", "Adriano");
}

In this case, the value "Adriano" is stored in ViewData and becomes accessible in the View.

Reading ViewData in a View

@page
@controller ChangeListController

Name: @ViewData.GetValue("name")

Here, the value associated with the specified key is retrieved from ViewData and rendered in the View.

Advantages of ViewData

Using ViewData in CodeBehind offers several advantages:

Simple Key-Value structure for lightweight data transfer
No need to create additional models for small or temporary data
Accessible across Controller, Model, View, and Layout
Request-scoped lifetime, ensuring clean and predictable data handling
Lightweight and fast, with minimal overhead
Familiar pattern for developers coming from ASP.NET MVC or Razor Pages

Conclusion

ViewData in CodeBehind is a lightweight, flexible, and efficient mechanism for transferring data between MVC components within a single request.

It is especially suitable for passing small pieces of data such as page titles, UI settings, temporary messages, or configuration values—without introducing unnecessary complexity into your application architecture.

DEV Community: Elanat Framework

A New Approach to Form Data Handling in CodeBehind 4.7

WebForms.php 2.1 Released - DeepSeek Converted and Qwen Evaluated

What is WebForms.php?

Why Convert the C# Implementation?

DeepSeek Conversion

Overloading Was One of the Interesting Problems

The First Review

Qwen Evaluation

Issue 1: implode() and Mixed-Type Arguments

Issue 2: null and Empty String Behavior

Other Findings

AI Did Not Replace Testing

PHP Conventions

Using WebForms.php

A Small PHP Example

WebForms.php 2.1 and WebFormsJS 2.1

Package Distribution

Conclusion

Elanat WebForms Core 2.1 Released with a Major Update

Structure-centric UI Generation

Compatibility Between WebForms and WebFormsJS

WebForms Core 2.1

Creating HTML Comments for WebForms Responses

Security Improvements

External URL Security

Additional Security Control with DisablePassObject

Action Control Values Are Now Arrays

Form Submit Check Validity

Append and Replace for Stored Data

URL Hash and Segment

Segment

Separator Changes

Template Engine

New Replace Capabilities

ReplaceActionControl

AssignReplace

AppendFetchReplace

Debugger

Repeat

Then

Conditions and Nested Execution

ForEach

JSON Path Improvements

WebForms Place Criteria (WPC)

HTML Tag Selection in InputPlace

Child Selection

All Selection

Criteria

State Improvements

StartState

LoadState and HasState

More Control Over Browser History and DOM Event Listeners

Initial State Loader

Dynamically Changing WebFormsJS Options

Better SSE and WebSocket Connection Management

SSE Connection State

WebSocket Connection State

Retry Management for Requests

Runtime Console Diagnostics

Message, Confirm, and Alert

HTTP Methods

Removal of <web-forms>

JavaScript Access with $

Automatic Number Conversion

Memory Management

InputPlace and Naming Changes

Numeric Comparisons

Query and Hash State

Other Features

Additional Fixes and Improvements

WebForms and WebFormsJS Patch-Version Compatibility

Package Size

CompressionLevel.SmallestSize

CompressionLevel.Fastest

Conclusion

CodeBehind 4.7 Released

Features of Version 4.7

CodeBehindConstructor Merged into the PageLoad Method

Write Output Added After the View

Issue 1: `implode()` and Mixed-Type Arguments

Issue 2: `null` and Empty String Behavior

Removal of `<web-forms>`

JavaScript Access with `$`

View (`page.aspx`)

Server-side Controller (`Controller.cs`)

`Button1_OnClick` Method

Why use `<template>`?