Thoughts Caused by ispostback

I have read numerous articles on webform-related technologies, including excellent ones. However, in my opinion, most of them are just "knowing but not knowing why ". It mainly teaches you how to do it, and few people will explain the principle behind it.

This is probably related to Microsoft's entire technical system. Haha. Of course, this is not the focus of this chapter. In this chapter, I will use a common ispostback attribute to explain the nature of the Web, hoping to inspire readers to think.

The explanation of ispostback can be found on the Internet. However, I believe that the summary is incomplete and beginners are easily confused ".

Loading the page for the first time: for example, you can directly enter "http: //.../index. aspx" in the browser address bar and press Enter. By default, http get requests are sent, and ispostback is false.

Page loading for the second time: select the address bar of the browser and press enter (or refresh directly). By default, GET requests are sent, and ispostback is false. For repeated operations, ispostback is always false.

Therefore, correct it. The so-called "first access" or "first loading" is also mentioned in all the explanations of "ispostback" on the Internet.
However, this explanation is not accurate and far-fetched (translated directly from msdn ). It is especially easy for beginners (or those who have transformed from JSP and PHP) to get dizzy.
Some beginners even think this way: After opening the index. ASPX page for the first time, refresh the page. This is the second access (page loading). At this time, the ispostback should be true.

I have always been used to looking at technology in essence. I personally think that to fully understand ispostback, we must understand the nature of Web applications (such as basic HTML, form, and HTTP protocols)
In this chapter, I will not use the reflector tool to decompile the page class and its ispostback attributes, so that some readers may be confused.

Asp.net webform technology is suitable for developers who have transformed from the traditional C/S development model, especially those who are engaged in Windows desktop programming, based on controls and event-driven programming.
In order to provide this convenience and integrate the BS/CS architecture, in fact, the webform technology has done countless work behind the scenes, which makes many developers feel that "Asp.net and desktop applications are similar, they are all drag controls, set Properties, events... ".
Therefore, the "Code workers" who do not want to solve the problem will feel that Asp.net is very simple, just drag the control to set the property event to bind data. This has caused the industry to degrade Asp.net programmers.
On the contrary, people who have been engaged in ASP and JSP development (I am myself) are more accustomed to exploring and thinking about the nature of the "Request/processing/response" model of web development.

Let's get back to the topic and continue talking about ispostback. Let's talk about PostBack first. In webform, the so-called PostBack is actually post before back. What do you mean? Some may have doubts. Can't I use a GET request? Of course not. Check the image first:

After clicking:

See it. After submite submitted the form, the value in the text box becomes blank again, the page is restored, and the form and button still exist. This is "back" (after the server completes processing the request, it will send a response to the data to the browser, and then the browser will render the html ).If you use pure HTML, submit the form to an ashx program for processing. In ashx, only one line of response is used. wrtite ("Hello World") responds to the user's request and outputs it. You will find that after you click the button, the page is refreshed and displayed to you, there is only one line of "Hello World", and the form elements and buttons on the page are gone, which is obviously not what we want. In our aspx, the request is submitted to the background for processing, and only one line of response. wrtite ("Hello
World "), but the result will be like this: the previous forms, buttons, and so on all exist, and the value of the text box is empty, and an extra line" "helloworld" is displayed on the page. Therefore, this indicates that in our webform model, after processing the request, the server returns the HTML data of the previous page to the client and submits it to the browser for rendering, and then present it to the user. This is actually a complicated process. Do you understand? Webform has quietly done countless jobs behind it, so that you are used to taking it for granted and have not noticed anything. Is it powerful? It includes webform event-driven, and controls that can be directly used in the background. In fact, they are all simulated. Use Performance consumption for convenience.

Needless to say, when I click the button to submit the form, this action is "Post. Of course, the post mentioned here is not limited to the POST request method, as in the above example, the form is submitted using the get method, implements the "Request/processing/response" process for Dynamic Web applications. After clarifying the PostBack, we should understand the ispostback attribute of the page class.

In fact, ispostback indicates whether to send back ". To determine whether to send back, the common point is: "Do you simply process page rendering, convert dynamic web pages into HTML to the client, or process client requests, and make the corresponding ". To put it bluntly, it is whether the submit action for form submission has occurred. For traditional form submission actions on the web, GET requests place values in URLs by default, while post requests place values in form forms for submission by default.

In general, it is the form submission action (and pass through). Whether it is post or get, the browser client has passed the value, the server side handles the request and the ispostback attribute is true.

When a user uses a GET request to submit a form, the address bar of the browser may contain the following content:

Http: // localhost: 1749/webform1.aspx? _ Viewstate = % 2fwepdwullte2mty2odcymjlkzhxr20kawii6wo4w0y % 2fgzlgmrvuhj87dk99baggiezzw & id = FF

This is normal. This is the viewstate used in webform and the hidden domain to store the value (which is base64-encoded ). Copy the URL to the address bar of the new browser window and press enter to track the ispostback attribute under page_load in the background code.

However, if you remove or modify the "viewstate" in the URL (it cannot be changed to a letter), press enter to jump to the background, and the ispostback attribute will change to false.

Similarly, you directly typed localhost: 1175/ispostbackdemo. aspx in the browser? Id = 1. It seems that the URL is also used to pass the value, but this is just a common GET request. It does not include the form submission action, and there is no hidden field, no viewstate-related data. Therefore, ispostback is false.

And I typed "... /index. aspx ", no form submission action, the server is only responsible for rendering the page (converted to HTML), flushing and loading for 10 thousand times, the ispostback attribute is still false

The following conclusions are concluded:
Conclusion ① ispostback = false for the page migrated when server. Transfer is used for migration.

Conclusion ② if there is no request value in the post method request, that is, request. if form = NULL, ispostback = false; if the get method does not contain a request value, that is, request. if querystring = NULL, ispostback = false.

Conclusion ③ if querystring or form has a request value, the keys in querystring or form do not have "_ viewstate", "_ eventtarget", and "_ viewstatefieldcount ", if no key is "null" and the value starts with "_ viewstate" and the value is "_ eventtarget", ispostback = false.

Conclusion ④ ispostback = false when migrating data to the image using response. Redirect mode.

Conclusion ⑤ cross-page commit (crosspagepostback) occurs. When the previouspage attribute is accessed, ispostback = true for The Source Page.

Conclusion ⑥ when cross-Page Submission (crosspagepostback) occurs, the target page is ispostback = false.

Conclusion 7. ispostback = false for the page migrated by server. Execute.

Conclusion During page running, the corresponding DLL is updated and the page tree structure has changed. In this case, ispostback = false for the request.

I personally add another point: when Ajax is used to request An ASPX page (this page can also be requested), whether post or get, ispostback is always false by default.

Unless you use: $ (document. Forms [0]). serialize () as a parameter, this method can automatically serialize the value of form forms, similar to a post form submission action. In fact, the ispostback attribute is changed to true because "_ viewstate" information is submitted to the server.

Similarly, if viewstate is disabled when you use the value of the server control in the background, the value cannot be obtained.

Tip: request. form refers to the data submitted using form. Request. querystring is submitted using a URL. The request contains all the request information.
There are also some misunderstandings: when using request. when form ["AAA"] or request ["AAA"] is de-valued, AAA actually refers to the name attribute of the form element, rather than its ID.
When a server control is used, only the ID attribute is available. For example, <asp: textbox id = "textbox1" runat = "server"> </ASP: textbox>
By default, after being parsed to HTML, it is changed to <input name = "textbox1" type = "text" id = "textbox1"/>. By default, the ID attribute of the server control is the same as the hidden clientid value.
However, when aspx is encapsulated by a parent class (such as the master template page), the ID and name after being parsed into HTML will change, and clientid will be used in this case.