DEV Community

Cover image for WebForms Core 2.3 Progress Update: Component Begin, WebForms Core Begin!
Elanat Framework
Elanat Framework

Posted on

WebForms Core 2.3 Progress Update: Component Begin, WebForms Core Begin!

#news #architecture #component #webformscore

WebForms Core 2.3 is getting close.

Around three to four weeks remain before the release, and a large part of the planned work has now been implemented. At this stage, development is mainly focused on completing the remaining pieces, integration, testing, and refining the new architecture.

This is a progress update rather than another roadmap announcement. The features already explained in the previous 2.3 announcement are intentionally not repeated here. Instead, this post focuses on the new implementation work that has been completed or is now reaching completion.

Component System

One of the most important developments in WebForms Core 2.3 is the implementation of the component execution boundary.

The new BeginComponent method establishes a DOM scope for a component.

For example:

BeginComponent("{component1}");
Enter fullscreen mode Exit fullscreen mode

The important part is that BeginComponent does not need to know where the component exists in the DOM.

When the event is executed on the client, WebForms Core starts from the element that triggered the event and walks upward through its parent elements until it reaches the component boundary specified by BeginComponent.

At that point, a TransientDom is created for that component area.

From then on, the Action Controls associated with that execution operate within the component's own DOM area.

This creates an important separation between component instances.

For example, if a page contains several instances of the same component, an event triggered inside one instance does not need to search or operate across the DOM of the other instances.

The mechanism also covers:

  • Buttons and their events
  • Async execution
  • Async conditions
  • Intervals
  • PreRunners
  • Action Controls executed after the component boundary is established

There is also special handling for CommentBack. When CommentBack is involved, the component's TransientDom is used so that the CommentBack operation is performed only once for that component scope.

DoComponent

DoComponent takes this one step further.

Instead of requiring the developer to manually establish every component boundary, DoComponent automatically generates the required BeginComponent instructions.

It also creates a component boundary for each generated index where necessary.

This means the component mechanism can be used both explicitly:

BeginComponent("{component1}");
Enter fullscreen mode Exit fullscreen mode

and through higher-level component generation with:

DoComponent(...);
Enter fullscreen mode Exit fullscreen mode

The result is a scoped execution model without requiring server-side UI rendering.

The component system is therefore no longer just a planned concept in WebForms Core 2.3. Its execution mechanism is now being implemented directly inside the WebForms Core command model.

Component Begin, WebForms Core Begin.

RenderList

A new declarative method called RenderList has also been added.

Previously, rendering a collection could require combining several operations such as foreach, AddText, template binding, and other related instructions.

RenderList provides a higher-level abstraction that combines these operations.

For example:

form.RenderList(
    inputPlace: InputPlace.Class("series-container"),
    template: Fetch.LoadHtml("/api/template.html", "SeriesSite"),
    pattern: "{{value}}",
    path: "[0]",
    in_: JsonSerializer.Serialize(row)
);
Enter fullscreen mode Exit fullscreen mode

The method is designed to simplify repeated template rendering while keeping the implementation declarative.

TransientDom is also handled automatically.

The goal is not to introduce another rendering engine, but to provide a simpler way to express a common WebForms Core operation.

GetFormJSON

A new GetFormJSON method has been added to the Fetch class.

It provides a direct way to retrieve the values of a form and represent them as JSON.

This gives WebForms Core a simple mechanism for moving form data into JavaScript-side processing without requiring developers to manually construct the JSON structure.

It also establishes a foundation for more advanced data handling features being developed for the new Variable system.

A New Variable System

WebForms Core 2.3 Comming Soon!

Another major area of development is the new Variable mechanism.

Instead of creating a simple mirrored-value structure, WebForms Core 2.3 is moving toward a more advanced variable system.

The idea is to allow values such as:

{{value}}
Enter fullscreen mode Exit fullscreen mode

to become actual variables within a defined scope.

The variable information can be represented as a name/value list in an INI-like structure stored through HTML comments within the relevant tag scope.

When a value changes, the corresponding bound values can be updated as well.

If the variable structure does not already exist, the system can create it automatically.

The Variable system is being separated from form data management.

The two concepts are therefore treated independently:

[variable]
[form-data]
Enter fullscreen mode Exit fullscreen mode

This distinction is important because a variable is not necessarily form data, and form data does not necessarily represent the state of a component or element.

The retrieval side of this mechanism is being organized around FetchVariable, while operations such as SetVariable and BindVariable provide ways to update and bind values.

SetVariable is being designed to accept arbitrary data, convert it into JSON when appropriate, and then update the Variable structure.

The Variable system is also being extended with operations for manipulating values, including replacement, arithmetic operations, text extraction, appending, and prepending.

This is one of the larger pieces of the 2.3 data-management work and is still being refined.

Page-Level Race Condition Protection

Another important part of the current development is protection against stale operations.

Consider a user who quickly performs two actions:

  1. Change the language to English.
  2. Immediately change the language back to Persian.

If the first request takes longer to return, its response could arrive after the second request.

Without protection, an older response could modify a page that has already moved to a newer state.

WebForms Core 2.3 is being developed to treat these operations as ordered requests.

The request execution model will track requests with increasing identifiers. In addition to the existing Action Control execution queue, request execution itself is being tracked.

When the page changes, the system can determine whether a pending request or Action Control belongs to an older page state.

If it does, it becomes obsolete.

The old operation must then be ignored even if its response has already arrived.

This provides protection against several related problems:

  • Race Conditions — multiple operations competing to update the page
  • Stale Responses — a response belonging to an older page state
  • Cancellation — preventing obsolete Action Controls from executing
  • Out-of-order responses — ensuring that an older response cannot overwrite a newer state

The important point is that this is not limited to server responses.

The same protection must apply to Action Controls that are already waiting in the client execution flow.

The goal is a simple rule:

Once the page has moved to a newer state, operations belonging to the previous state must no longer be allowed to modify the current page.

This is especially important for fast user interactions and applications where multiple server requests can be generated within a very short period.

Replacing the * Magic Character in DeleteAll

A protocol-level ambiguity in DeleteAll has also been addressed.

Previously, * was used as a special value to represent "delete everything".

For example:

Add("do" + InputPlace, "*");
Enter fullscreen mode Exit fullscreen mode

and:

Add("dk" + InputPlace, "*");
Enter fullscreen mode Exit fullscreen mode

The problem is that * can also be a legitimate value.

If an actual <option> or checkbox value is exactly *, the protocol cannot distinguish between:

Delete the item whose value is *
Enter fullscreen mode Exit fullscreen mode

and:

Delete all items
Enter fullscreen mode Exit fullscreen mode

WebForms Core 2.3 replaces this magic-character approach with a dedicated flag structure.

This removes the ambiguity and allows * to be treated as a normal value when necessary.

SafeValue Now Handles HTML Encoding

SafeValue has also been improved.

It now performs HTML encoding in addition to its existing processing, providing a centralized mechanism for safely handling values that are inserted into HTML-related output.

The goal is to avoid requiring developers to remember separate encoding operations in different parts of the framework.

UpdateLineByIndex Fix

An edge case involving empty values in UpdateLineByIndex has been fixed.

Previously, an empty value could result in an additional = being generated for an Action Control that did not actually contain an assigned value.

This could produce malformed or ambiguous command output.

The new behavior correctly preserves empty values without introducing an unnecessary assignment character.

WebFormsJS Improvements

Several internal improvements have also been made to WebFormsJS.

The options section has been converted to an Object Initializer structure.

This reduces the amount of code and makes the configuration structure easier to read and maintain.

WebFormsOptions has also been renamed to WFO, reducing the size of the library and simplifying the API.

Two non-ASCII characters have been removed from the WebFormsJS source as part of the ongoing effort to keep the client-side library compact and predictable.

<main> Becomes the Default Location

One of the more practical changes in WebFormsJS 2.3 is the default location used by:

  • ResponseLocation
  • StateBodyLocation

The default has been changed from:

<body>
Enter fullscreen mode Exit fullscreen mode

to:

<main>
Enter fullscreen mode Exit fullscreen mode

There is also an automatic fallback.

If a <main> element does not exist, WebFormsJS uses <body>.

This change removes one of the configuration steps that previously had to be recommended to developers.

As a result, the WebFormsJS 2.3 package can now be consumed directly from a CDN without requiring developers to download and host the library themselves.

The package size is approximately 45 KB.

For applications that do not need to customize these locations, the result is a simpler setup with less configuration and a very small client-side payload.

Modal

A dedicated Modal API has also been introduced.

The existing concept is essentially a container or Box, but Modal is the terminology commonly used on the web for this type of UI.

A modal can be opened with:

ShowModal
Enter fullscreen mode Exit fullscreen mode

and removed with:

CloseModal
Enter fullscreen mode Exit fullscreen mode

This provides a clearer high-level API for a very common UI pattern.

What Is Left?

With the release approximately three to four weeks away, the project has moved from architectural design into final implementation and refinement.

The major new foundations are now in place:

  • Component-scoped execution through BeginComponent
  • Automatic component boundaries through DoComponent
  • Declarative collection rendering through RenderList
  • Form-to-JSON conversion through GetFormJSON
  • The new Variable system
  • Improved value handling through SafeValue
  • Protocol improvements for DeleteAll
  • WebFormsJS size and configuration improvements
  • <main>-based default locations with automatic <body> fallback
  • Page-level protection against stale requests and Action Controls

The remaining work is primarily focused on completing the Variable operations, finalizing request lifecycle handling, integration testing, edge cases, and polishing the APIs before release.

WebForms Core 2.3 is becoming much more than an incremental update.

The component boundary, scoped execution, data binding, variable management, request lifecycle, and client-side execution model are increasingly becoming parts of one coherent system.

And the most important part is that this is still the same WebForms Core philosophy:

The server provides the commands. WebFormsJS executes them on the client.

But with 2.3, those commands can now operate with much stronger boundaries, better lifecycle control, and a more structured component model.

WebForms Core 2.3 is getting close.

Related Links

On Elanat:

On GitHub:

Top comments (0)