Understanding The Complete Story of Postback in ASP.NET

https://docs.microsoft.com/zh-cn/dotnet/api/system.web.ui.page.ispostback?view=netframework-4.7

https://docs.microsoft.com/zh-cn/dotnet/api/system.web.ui.usercontrol.ispostback?view=netframework-4.7.1

Understanding The Complete Story of Postback in ASP.NET

https://www.codeproject.com/Articles/811684/Understanding-The-Complete-Story-of-Postback-in-AS

Introduction

下面提到了asp和asp.net，这是2个不同的东西

In the old HTML, the only way to make something updated on the webpage is to resend a new webpage to the client browser.

That's what ASP used to do, you have to do this thing call a "PostBack" to send an updated page to the client.

Postback的定义:send an updated page to the client.

In ASP .NET, you don't have to resend the entire webpage. You can now use AJAX, or other ASP.NET controls such that you don't have to resend the entire webpage.

If you visit some old website, you would notice that once you click something, the entire page has to be refresh, this is the old ASP.

In most of the modern website, you will notice your browser doesn't have to refresh the entire page, it only updates the part of the content that needs to be updated.

For example, in Stackoverflow, you see the page update only the content, not the entire webpage.

Programming model in old ASP for using POST method in form is to post the values of a Form to a second page.

The second asp page will receive the data and process it for doing any validation or processing on the server side.

With ASP .Net, the whole model has changed.

Each of the asp .net pages will be a separate entity with ability to process its own posted data.

That is, the values of the Form are posted to the same page and the very same page can process the data.

This model is called post back.

Each Asp .net page when loaded goes through a regular creation and destruction cycle like Initialization, Page load etc., in the beginning and unload while closing it.

This Postback is a read only property with each Asp .Net Page (System.Web.UI.Page) class.

This is false when the first time the page is loaded and is true when the page is submitted and processed.

This enables users to write the code depending on if the PostBack is true or false (with the use of the function Page.IsPostBack()).

Understanding the PostBack

PostBack is the name given to the process of submitting an ASP.NET page to the server for processing.

PostBack is done if certain credentials of the page are to be checked against some sources (such as verification of username and password using database). This is something that a client machine is not able to accomplish and thus these details have to be 'posted back' to the server.

A post back is round trip from the client (Browser) to the server and then back to the client. This enables you page to go through the asp engine on the server and any dynamic content to be updated.

Using the Code

Post back is implemented with the use javascript in the client side.

The HTML page generated for each .aspx page will have the action property of the form tag set to the same page. This makes the page to be posted on to itself. If we check the entry on the HTML file, it will look something like this.

Hide   Copy Code

<form name="_ctl1″ method="post" action="pagename.aspx?getparameter1=134″ language="javascript" onsubmit="if (!ValidatorOnSubmit()) return false;" id="_ctl1″ >

Also, all the validation code that is written (Required Field Validation, Regular Expression validation etc.,) will all be processed at the client side using the .js(javascript) file present in the webserver_wwwroot/aspnet_client folder.

With this new ASP .Net model, even if the user wants to post the data to a different .aspx page, the web server will check for the runat=’server’ tag in the form tag and post the web form to the same .aspx page. A simple declaration as in the following code snippet will be enough to create such a web form.

Hide   Copy Code

<form id="form1″ runat="server" > 
<!– place the controls inside –>
</form>

Understanding the AutoPostBack

AutopostBack is a property which you assign to web controls if you want to post back the page when any event occurs at them.

Using the Code

Hide   Copy Code

<asp:DropDownList id="id" runat="server" AutoPostBack="true" OnSelectIndexChanged="..."/>

This ddl not need asp:button for example in order to post, when you change ddl is autoposted.

Defaut value on control is false.

ASP.NET also adds two additional hidden input fields that are used to pass information back to the server.

This information consists of ID of the Control that raised the event and any additional information if needed. These fields will empty initially as shown below,

The _doPostBack() function has the responsibility for setting these values with the appropriate information about the event and the submitting the form. The _doPostBack() function is shown below:

Hide   Copy Code

<script language="text/javascript">
 
    function __doPostBack(eventTarget, eventArgument) {
        if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
        theForm.__EVENTTARGET.value = eventTarget;
        theForm.__EVENTARGUMENT.value = eventArgument;
        theForm.submit();

    }
</script>

ASP.NET generates the _doPostBack() function automatically, provided at least one control on the page uses automatic postbacks.

Understanding the Page.IsPostBack

• Gets a value that indicates whether the page is being rendered for the first time or is being loaded in response to a postback.
• The IsPostBack property can be used to determine if the page is submitted to itself. When a form is submitted back to the same page that contains it, it's called a post back. ASP.NET provides a property called IsPostBack that is TRUE when the page is being loaded as a result of a post back, and is FALSE otherwise.

Using the code

Hide   Copy Code

private void Page_Load()

{

    if (!IsPostBack)

    {

        //You can write here the code, which you want to execute in the first time when the page is loaded.

        FunctionToBindSomething();

    }

}

Usage

1. The One of the Most Common Use of AutoPostBack is for Cascading Dropdown list.

 What is PostBack in ASP.NET

http://www.c-sharpcorner.com/uploadfile/2f73dd/what-is-postback-in-Asp-Net/

To work with the ASP.Net Web Controls events, we need a solid understanding of the web page life cycle.

The following actions will be taken place when a user changes a control that has the AutoPostBack property set to true :

1. On the client side, the JavaScript _doPostBack function is invoked, and the page is resubmitted to the server.
2. ASP.NET re-creates the Page object using the .aspx file.
3. ASP.NET retrieves state information from the hidden view state field and updates the controls accordingly.
4. The Page.Load event is fired.
5. The appropriate change event is fired for the control. (If more than one control has been changed, the order of change events is undetermined.)
6. The Page.PreRender event fires, and the page is rendered (transformed from a set of objects to an HTML page).
7. Finally, the Page.Unload event is fired.
8. The new page is sent to the client.

To watch these events in action, we can create a simple event tracker application. 

What is a postback?

https://stackoverflow.com/questions/183254/what-is-a-postback

The following is aimed at beginners to ASP.Net...

When does it happen?

A postback originates from the client browser.

Usually one of the controls on the page will be manipulated by the user (a button clicked or dropdown changed, etc), and this control will initiate a postback.

The state of this control, plus all other controls on the page,(known as the View State) is Posted Back to the web server.

What happens?

Most commonly the postback causes the web server to create an instance of the code behind class of the page that initiated the postback.

This page object is then executed within the normal page lifecycle with a slight difference (see below).

If you do not redirect the user specifically to another page somewhere during the page lifecycle, the final result of the postback will be the same page displayed to the user again, and then another postback could happen, and so on.

Why does it happen?

The web application is running on the web server. In order to process the user’s response, cause the application state to change, or move to a different page, you need to get some code to execute on the web server.

The only way to achieve this is to collect up all the information that the user is currently working on and send it all back to the server.

Some things for a beginner to note are...

• The state of the controls on the posting back page are available within the context. This will allow you to manipulate the page controls or redirect to another page based on the information there.
• Controls on a web form have events, and therefore event handlers, just like any other controls. The initialisation part of the page lifecycle will execute before the event handler of the control that caused the post back. Therefore the code in the page’s Init and Load event handler will execute before the code in the event handler for the button that the user clicked.
• The value of the “Page.IsPostBack” property will be set to “true” when the page is executing after a postback, and “false” otherwise.
• Technologies like Ajax and MVC have changed the way postbacks work.

https://stackoverflow.com/questions/4251157/what-is-a-postback

So far I've seen the right answer alluded to repeatedly, and almost everyone has come shy of what I consider subjectively to be the mark.

Let's start with the basics:

An HTTP request can be any of the HTTP verbs, but the primary two used by  people are GET and POST. Well, those are the two a programmer uses most frequently. The others all have some purpose, if they're implemented on the server. When you send information to the server, you can do so either through the use of the URL (to request a page) or within the body of the request (POST, PUT, DELETE, for instance).

Now you'll remark (I'm sure) that the URL in a GET request often contains data, and this is true, but according to W3C, you should not use GET to alter state, and yet we do often. It's sort of a hack that we all agree is an actual use, and not a hack. Whether that makes it a hack or an actual implementation detail I leave up to you.

So when you send the body of the POST (skipping the others for now, you can figure it out from here) with the form elements, you're sending back certain elements. How those elements are defined is up to you and to the environment you're working in. You could post to a server with a JSON element in the body, or with XML, or with form fields. Generally we do posts from a FORM element in the body of the HTML.

Now everyone says, "oh, a postback is a subsequent request to a page." But, that's not true. A postback is when you send data via POST -> back to the server. I say this because the difference between a GET request and a POST request is if data is included in the body (and the verb used, but the client usually knows how to deal with that). You could postback to the page on the first time the page is visited, and in fact ASP.NET has tools for doing that in the library. You could certainly have a desktop client POST data to a server (think Twitter) without showing any webpage at all from the server (ok, so twitter is probably not the best concept to use for an example here, but I want to illustrate that you can use a client that doesn't show the webpage, so no request is necessary).

So really what you should read there in "postback" is "I'm POSTing data BACK to the server for processing". It's presumed that you retrieved the page initially with a GET to show the user the <form> element that has <input> fields for them to interact with, and that at the end you're sending data back. But I hope you can see that it doesn't have to be in that order.

So here's something else to consider:

What if you gave the user a page with a bunch of <input>s and no <form> but instead, had a button wired up in javascript to concat all those <input>s with &value-n= and send them as a GET? Does the same thing, but violates that concept of only using GET for requests. (possibly) ensuing discussion encourages me to reinforce that GET should have no side effects (no updating values)

It's how come you can send someone a link to a google search, for instance. So we don't ALWAYS have to POST BACK to the server to get data.

Hope this helps. Cheers

Difference between Page refresh and Page postback

A refresh mean a complete reload of the page, without any form data. This is essentially an HTTP GET.

A post back is when the page is posted to itself (through the form action=""). This is essentially an HTTP POST.

Webforms Refresh problem

that's a common problem. Here's explanation and solution of the problem.

When a web form is submitted to a server through an HTTP POST request, a web user that attempts to refresh the server response in certain user agents can cause the contents of the original HTTP POST request to be resubmitted, possibly causing undesired results, such as a duplicate web purchase. To avoid this problem, many web developers use the PRG(Post/Redirect/Get) pattern.

copied from wiki (LINK)

simplest solution can be Response.Redirect to the same page (i.e. if you page is named default.aspx write Response.Redirect("default.aspx")). if you do this browser refresh button will just load the page as if you have typed in address bar URL and navigated to it.

here's SO question How to stop unwanted postback that might be useful as well.