elanatframework

Posted on Oct 8

End of Front-End, Just Use Djang, Laravel, Spring Boot, Express, ...

#django #laravel #webdev #javascript

Elanat plans to add WebForms Core technology in all Back-End frameworks as a module. This is possible only with the participation of web developers who are proficient in web frameworks.

WebForms Core is a new technology supported by the powerful CodeBehind framework. In this technology, the control of HTML tags is done on the server side, but the processing is done on the client side (the server only sends command codes in the INI structure to the client).

Articles about WebForms Core:
https://dev.to/elanatframework/using-webforms-core-36ka
https://dev.to/elanatframework/surprise-2024-web-forms-back-to-aspnet-core-j1h

Videos:
https://www.youtube.com/watch?v=zl4sxjIkBwU
https://www.youtube.com/watch?v=ZuMMApM00xM

This article explains how to deploy modern WebForms Core technology on other back-end frameworks. Web developers familiar with web frameworks are encouraged to build the WebForms Core module on their favorite framework. The source code of the modules is placed in the repository below, and public participation in all sources is acceptable.

https://github.com/elanatframework/Web_forms_classes

Please adhere to Elanat's standards and rules when creating modules.

How WebForms Core technology works in back-end frameworks

To use WebForms Core technology, developers can use only classes from the WebForms Core Classes repository, but building a module on top of the back-end frameworks allows you to take advantage of the maximum functionality of WebForms Core.

Web Requests

WebForms Core is completely faithful to HTML and all web requests are completely based on form submission.
Requests from the server are sent along with the request header with the name Post-Back and the value true; the reasons for this are listed below:

Have full support for HTML form methods
To have a faster diagnosis of the client's request
Back-end developers do not need to evaluate requests

Therefore you don't need to do anything yet. It is better to tell developers with explanations that in order to use WebForms Core technology, they should add the following script tag in the head section of HTML pages:

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

Server response

The codes below are an HTML page in which the script tag is added to call the WebFormsJS library. On this page, there is a form tag that contains a button that sends data to the textbox.

<!DOCTYPE html>
<html>
<head>
  <script type="text/javascript" src="/script/web-forms.js"></script>
</head>
<body>
  <p>Hello World!</p>
  <form method="POST" action="/">
    <input type="text" name="TexBox1">
    <input type="submit" name="Button1" value="Send data">
  </form>
</body>
</html>

We use the above example to explain how to respond from the server side to the client in WebForms Core technology.

When WebForms Core technology is used, 5 situations occur:

First response without Action Controls
First response with Action Controls
The response without View only includes Action Controls after submitting the form
The response includes sending the View without Action Controls after submitting the form
The response includes sending the View along with Action Controls after submitting the form

1. First response without Action Controls
If the request is for the first call and the server does not generate Action Controls, the View is dispatched normally. So you don't have to do anything.

2. First response with Action Controls
In this case, the View is also displayed normally and then a tag named web-forms containing an attribute named ac and the value of Action Controls is added to the end of the View. The Action Control value is added without starting with the [web-forms] header in the ac tag. In this case, Action Controls with string $[sln]; They are separated (instead of \n); also string $[dq]; It replaces the double quote character (").

Example:

<!DOCTYPE html>
<html>
<head>
  <script type="text/javascript" src="/script/web-forms.js"></script>
</head>
<body>
  <p>Hello World!</p>
  <form method="POST" action="/">
    <input type="text" name="TexBox1">
    <input type="submit" name="Button1" value="Send data">
  </form>
</body>
</html>
<web-forms ac="tc(Button1)=violet$[sln];sh(TexBox1)=40px"></web-forms>

Note: This is a default mode that module developers must follow. Maybe you think that adding a tag after the end of the HTML tag is not a clean code; but don't worry because WebForms classes have methods to change the location of this tag. Therefore developers can simply add this web-forms tag anywhere on the page they like using some methods of the WebForms class.

3. Only Action Controls after submit
If View is not specified in the server response, only the INI response containing the Action Controls is sent.

Example:

[web-forms]
sd(Button1)=1
sr(TexBox1)=1

4. Only View after submit
If the server response does not contain WebForms codes, i.e. WebForms class methods are not used (Action Control is not present in the response), you do not need to do anything, and WebFormsJS replaces the responses as Ajax in the body tag (changeable) of the page.

Please note that in this case, only the internal values of the body tag in the View should be sent. Usually, frameworks use Layout and there must be a condition where Layout is disabled and only View is sent. If the framework does not have an option to disable Layout, the module writer must add a procedure to disable Layout.

Result example:

<!DOCTYPE html>
<html>
<head>
  <script type="text/javascript" src="/script/web-forms.js"></script>
</head>
<body>
  <p id="About">About text ...</p>
</body>
</html>

According to the above codes, the server will change the View page and the server's response will be as below.

New View

  <p id="About">About text ...</p>

5. View and Action Controls after submit
In this case, the View string is first placed in the first line of Action Controls. If the positioning tag is body, the View is placed in the first line of Action Controls as follows:

[web-forms]
st<body>=<p>About text ...</p>
bc<p>=green
fs<p>=24px

In this case, if there is a \n character in the View string, it should be matched with the string $[ln]; be replaced

Set Content-Type to response header

As we said, the response of the server is in the form of INI when there are WebForms Action Controls in the response, so Content-Type should be set to text/plain in the response header.

Standards and rules that must be followed

Module name

The module name should be WebForms Core.

WebForms Class Update

The classes in the WebForms Classes repository must be updated according to the WebForms class in the CodeBeihnd framework.

WebForms class link in CodeBeihnd framework:
https://github.com/elanatframework/Code_behind/blob/elanat_framework/class/WebForms.cs

WebForms Middleware

You should create a middleware called UseWebForms so that it can be easily used in back-end framework projects.

WebFormsJS library name

The name of the WebFormsJS library should be web-forms.js and not changed.

Options

The codes below are WebForms Core technology settings in the CodeBehind framework.

web_forms_script_path=/script
auto_create_web_forms_script=true
recreate_web_forms_script_after_recompile=false
web_forms_view_place=<body>

The above options are explained below.

WebFormsJS library path
(web_forms_script_path=/script)

The web_forms_script_path option specifies the path to the WebFormsJS file. According to the /script value, the WebFormsJS file is created in the following path:
/script/web-forms.js

Should the Web-Forms script be created automatically?
(auto_create_web_forms_script=true)

If the auto_create_web_forms_script option is enabled, the WebFormsJS file will be created automatically.

Rebuilding the Web-Forms script after each compilation
(recreate_web_forms_script_after_recompile=false)

If the recreate_web_forms_script_after_recompile option is enabled, the WebFormsJS file will be created after each compile. This option is for situations where we want to update and need to recreate the new version of the WebFormsJS library. You can ignore this option.

Determining the location of the server response tag
(web_forms_view_place=<body>)

The web_forms_view_place option is for situations where the Action Control is not present in the response and determines the tag location of the server's response.

All options must be applicable in a UseWebForms method.

Example:

public static void UseWebForms(string WebFormsViewPlace = "<body>", bool AutoCreateWebFormsJS = true, string WebFormsJSPath = "/script")
{
  // Do something
}

The View location option must be stored in a static variable.

Questions

If you don't understand any topic well, we at Elanat team will help you to create WebForms Core module for back-end frameworks. If you have any questions, you can ask in the link below:

https://github.com/elanatframework/Web_forms_classes/discussions

DEV Community

End of Front-End, Just Use Djang, Laravel, Spring Boot, Express, ...

How WebForms Core technology works in back-end frameworks

Web Requests

Server response

Set Content-Type to response header

Standards and rules that must be followed

Options

Questions

Related links

Top comments (0)

Read next

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory on Digital OceanDroplet

HTML meta 標籤中 viewport 的設定

Avoiding Connection Pinning in Lambda and RDS Proxy with NestJS and Proxy Splitting

Why Homelab Users Need a WAF