Go to: http://blog.joycode.com/percyboy/archive/2004/08/22/31330.aspx
The web page is inconspicuous.
The web model, B / S is a special case of C / S, but it still continues the "request" of C / S - "Response" mechanism: from the request, analyze the request and request a response database on the server, Other resources, processing processing forms a HTML page (here you may contain client scripts to achieve specific effects) and then send back to the client browser back "response". The web is such a back and forth (loop), and a rounded run.
In this way, the Web is obviously intermittent. How do you say "no state"? Take the Windows program as an example, such as a text box, its text attribute value If you change, you can know the value of the value before changing and changed, this is a role of the status.
Programming of traditional web processing engines (CGI, ASP, PHP, JSP, etc.) are basically used in linear models.
"Continuous" and "State" description of ASP.NET Web Form
Fundamentally, ASP.NET does not change the nature of the web page: Each time you request an ASP.NET page, the server loads an ASP.NET page and uninstall the page when the request is completed. Page and its server controls are responsible for performing requests and presenting HTML to the client.
ASP.NET designer, reconsides with this process from the perspective of actual visitors: visitors open a page, click on a button, see new screen ... All seems to be continuous.
This continuous illusion is implemented by the ASP.NET page framework, page and its control. After returning, the behavior of the control must appear to begin from the end of the last Web request. On the other hand, for TextBox in Web Form, ASP.NET also makes them state, you can know changes in the next loop and the textbox value between this loop; if variation, you may trigger the TextBox TextChanged event. This is also an illusion of ASP.NET deliberately implemented.
The life cycle of the ASP.NET server control is generally as follows:
1. Initialization - INIT Events
2. Load View Status - LoadViewState Method
3. Process the return data - the loadPostData method to implement the control of the IPostBackDataHandler interface, you can automatically load the return data, such as TextBox, DropdownList, etc.
4. Loading - LOAD Events (ONLOAD Method)
5. Send a return change notification - the RaisePostDataChangeDevent method to implement the control of the IPostBackDataHandler interface, you can automatically load the return data. In step 3, the return data is loaded. If the data changes before and after the return, the corresponding server event is triggered in this step.
6. Handling the Raising Event - RaisePostBackeVent method to implement the control of the IPostBackeVentrandler interface, that is, the reply control, such as Button, LinkButton, Calendar, etc.
7. Pre-presentations - prerender events (onprender method)
8. Save view status - SaveViewState method
9. Rendering - Render Method
10. Disposal - Dispose Method
11. Uninstall - UNLOAD Events (ONUNLOAD Method)
Web form's base class system.web.ui.page inherits from System.Web.ui.Control, and it is also a special Control. How is ASP.NET implementation?
ASP.NET uses the ViewState view status, if you view the HTML code generated by the web form, you can see a hidden field named __viewstate, and the ASP.NET stores status information in Hash. Through it, you can know the state of each control before the next faster.
For example: a TextBox, the TEXT attribute before the return has a value "Hello", and the visitor fills in the new value "world". When this page returns to the server, the server code can know the TEXTBOX's text property value. Change, TextChanged events are triggered. From the life cycle, LoadViewState has loaded the original status of TextBox, and the LoadPostData has obtained the current value of TextBox from the Request.form collection. After RaisePostDataChangeDevent, the TEXTBOX TEXTCHANGED event is triggered. SaveViewState will current value. Deposits for ViewState as the original state of the next faster.
How does ASP.NET achieve continuous illusion?
For developers, in the past, the handling of a submission button, or how HTML Form submitted is often processed in another page, pointing FORM's target to this page. (Of course, it can be done in a page, but most people are used to two pages)
In ASP.NET, this process is processed into a process similar to the Windows program, button's click, and Form is submitted by ASP.NET "Packaging" into a server event, which is Button's Click event. From a life cycle, the BUTTON control is loaded as follows: LoadPostData can find the name value of Button from the Request.form collection (only clicked Button will generate a Name-Value pair in the Request.form collection); After Load, in RaisePostBacke, the Button's Click event will be triggered.
We reproduce the special situation: Button can cause formal submission in HTML, which can cause pages to return; but others, such as LinkButton (corresponding to HTML a a), DropdownList (corresponding to HTML SELECT) Wait, it will not automatically cause faster. In this case, ASP.NET uses another technique to ensure that this fake image continues to be established: open an HTML page code generated by a ASP.NET containing linkbutton, you can find two hidden fields, a called __EventTarget, a called _ _Eventargument, find a script next to:
Function __dopostback (evenettarget, 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 ();
}
Take a look at the code generated by LinkButton:
If you have a client script in a web page, you should know that when you click on this "linkButton", it is actually through the client script and several parameters (such as Calendar need to pass some parameters, LinkButton has no pass parameters. It is necessary to set it to both hidden fields and submit a form in the script.
Continue to see the service segment process: LoadPostData will see the values in the two hidden fields, but don't analyze immediately; it is still LOAD, in the RaisePostBacke, parse the value in these two fields, trigger the corresponding control event .
Let's finalize the autopostback attribute such as Checkbox or DropDownList: If AutoPostBack is True, then add the back of the __dopostback style to the client; if it is false, do not join this immediate return script, Instead, there are other controls that can cause fur, triggered Checkbox's CheckedChanged events in RaisePostDataChanged, DropdownList's SELECTEDEXCHANGED event; other resolved events continued to analyze other events in RaisePostBacke at RaisePostBackeVent.
Microsoft simplifies complex Web models into a traditional Windows programmer's easy-to-accept model, which greatly reduces the threshold for Web development. But in this way, Microsoft can't change the "stateless" and "intermittent" of the Web, so do not use the experience of all Windows program development to Web development. Understand its intrinsic mechanism, helping Windows programmers avoid these "arbitrary" errors.
