Asp_net web form's "continuous" and "stateful" illusion

Web pages are stateless and intermittent

Web model, B/S is a special case of C/S, but it continues the "request"-"response" mechanism of C/S: from receiving requests, analyze the request and request the response database and other resources on the server based on the request. process the request to form an HTML page (the client script may be included here for specific effect ), then, send a "response" to the client browser ". The Web is like a loop and a loop is running.

In this case, the Web is obviously intermittent. What should we say about "stateless? Take a Windows program as an example. For example, if the text attribute value of a text box is changed, you can know the value before the change and the value after the change. This is a role of the status.

The traditional Web Processing Engine (CGI, ASP, PHP, JSP, etc.) programming basically follows this linear model.

The illusion of "continuous" and "stateful" of ASP. NET web form

Basically, Asp. net does not change the nature of web pages: each request ASP. NET page, the server will load an ASP.. NET page, and uninstall the page when the request is complete. The page and its server control are responsible for executing the request and rendering the HTML to the client.

ASP. NET designers re-consider this process from the perspective of actual visitors: Visitors open a page and click a button to see a new picture ...... This seems to be continuous.

This kind of continuity illusion is implemented by the ASP. NET page framework, pages and their controls. After sending the API back, the control action must start from the end of the last Web request. For Textbox, Asp. net also gives them a State to know the changes in the textbox value between the previous loop and the loop. If they change, the textchanged event of the textbox may be triggered. This is also an illusion specifically implemented by ASP. NET.

Lifecycle of ASP. NET Server controlsGenerally:

1. initialize-InitEvent (oninit method)

2. Load view status-LoadviewstateMethod

3. process the returned data-LoadpostdataMethod
Controls that implement the ipostbackdatahandler interface, that is, controls that can automatically load the returned data, such as textbox and dropdownlist.

4. Load-LoadEvent (onload method)

5. Send a change notification-RaisepostdatachangedeventMethod
Controls that implement the ipostbackdatahandler interface, that is, controls that can automatically load the returned data.
Load and send back data in step 1. If the data changes before and after sending back, the corresponding server event is triggered in this step.

6. process the send-back event-RaisepostbackeventMethod
Controls that implement the ipostbackeventhandler interface, that is, controls that can cause sending back, such as buttons, linkbuttons, and calendar.

7. Pre-rendering-PrerenderEvent (onprerender method)

8. Save view status-SaveviewstateMethod

9. Rendering-RenderMethod

10. Disposal-DisposeMethod

11. Uninstall-UnloadEvent (onUnload method)

The base class system. Web. UI. Page of web form inherits from system. Web. UI. Control, which is also a special control.

How is ASP. NET implemented?

ASP. net uses the viewstate view status. If you view the HTML code generated by web form, you can see a hidden field named _ viewstate, Asp.. net stores the status information in hash mode. It can be used to know the status of each control before the next sending.

For example, for a Textbox, the text Attribute before sending back has the value "hello", and the visitor fills in the new value "world". When this page is sent back to the server, the server code shows that the text attribute value of textbox has changed, and the textchanged event is triggered. From the perspective of the lifecycle, loadviewstate loads the original status of Textbox, and loadpostdata loads the status from request. in the form set, the current value of textbox is obtained. After loading, the textchanged event of textbox is triggered in the raisepostdatachangedevent step. The saveviewstate stores the current value in viewstate as the original status of the next sending back.

How does ASP. NET implement the illusion of continuity?

For developers, in the past, when a button is clicked and sent back, or the HTML form is submitted on another page, the target of the form is directed to this page. (Of course it can be done on one page, but most people are used to two pages)

In ASP.. net.. net "wraps" into a server event, that is, the Click Event of the button. From the perspective of the lifecycle, the process of the button control being loaded is as follows: loadpostdata can be taken from the request. the name of the button in the form set (only the clicked button will be in the request. generate a name-value pair in the form set). After loading, the Click Event of the button is triggered in the raisepostbackevent step.

We will analyze the special situation: the button can cause form submission in HTML, that is, it can cause page sending back; but other, for example, linkbutton (corresponding to element a of HTML) and dropdownlist (corresponding to select of HTML) will not automatically cause sending back. In this case, Asp. net uses another technique to ensure that this Illusion persists: open an ASP with linkbutton. net generated HTML page code, you can find two hidden fields, one is _ eventtarget, the other is _ eventargument, and then find a script:

 function __doPostBack(eventTarget, eventArgument) {
  var theform;
  if (window.navigator.appName.toLowerCase().indexOf("netscape") > -1) {
   theform = document.forms["Form1"];
  }
  else {
   theform = document.Form1;
  }
  theform.__EVENTTARGET.value = eventTarget.split("$").join(":");
  theform.__EVENTARGUMENT.value = eventArgument;
  theform.submit();
 }

Let's look at the code generated by linkbutton:

<A id=LinkButton1 href="javascript:__doPostBack('LinkButton1','')">LinkButton</A>

If you have used a client script on a webpage, you should know that when you click this "linkbutton", it actually uses the client script to name it and several parameters (for example, the calendar needs to pass some parameters, linkbutton does not need to pass parameters) is set to two hidden fields, and the form is submitted in the script.

Continue to look at the service segment process: loadpostdata will see the values in these two hidden fields, but it is not resolved immediately; it is still after load, and the values in these two fields are parsed in raisepostbackevent, the event that triggers the corresponding control.

Finally, let's analyze the autopostback attributes such as checkbox or dropdownlist: If autopostback is true, add the above _ dopostback type sending back when outputting to the client; if it is false, the checkedchanged event of the checkbox is triggered in raisepostdatachanged after other controls (such as buttons and linkbuttons) that can cause sending back are not added, selectedindexchanged event of dropdownlist; Continue to analyze other events that cause sending back when raisepostbackevent.

 

Microsoft simplifies complex web models into a model that is easy for traditional Windows programmers to accept, greatly reducing the threshold for web development. However, Microsoft cannot change the "stateless" and "Intermittent" nature of the web, so it is not necessary to apply all windows program development experience to web development. Understanding its internal mechanism helps windows programmers avoid these "arbitrary" errors.