What is Postback?

[antonyliu2002]

I know that this has been asked and answered thousands of times. As a
matter of fact, I know that I need to say

If Not Page.IsPostBack Then
'Do something
End If

for things that needs to be processed by the web server. I am still
struggling to understand this postback logic, and hope that some kind
gurus out there could help me clarify the confusion I have.

I did read quite some articles/posts about this, but still could not
clearly understand this terminology.

The MSDN documentation at the following URL says:

http://msdn.microsoft.com/library/d.../frlrfSystemWebUIPageClassIsPostBackTopic.asp

Page.IsPostBack Property
Gets a value indicating whether the page is being loaded in response to
a client postback, or if it is being loaded and accessed for the first
time.

From my understanding, there is no doubt that "postback" means that

some bits of information has been transmitted to the Web server from
the client.

But what exactly is meant by "being loaded and accessed for the first
time"? How is "for the first time" defined? If I fill up the forms on
a page and submit it to server, is this a postback or no? And when the
server processes the form and returns it to the client, is this the
first time or no? Since the returned page would likely be different
from the original one.

For example, if I have a page called test.aspx. When a user puts the
following URL into the address bar of his/her browser:

http://www.someserver.com/test.aspx

The web server gets this request and compiles the test.aspx page and
sends the resulting HTML back to the client.

Up to this point, OK, there is no problem. This is absolutely the first
time that test.aspx is being accessed or loaded.

Now, suppose that the user enters some user profile information on
test.aspx page and hits the "Submit" button to update his/her profile.
And usually in this case, we enclose our implementation of the
EventHandler of the Submit button with

If Not Page.IsPostBack Then
'Do something
End If

This is exactly where it confuses me (and maybe many others out there).
This "If Not" condition is exactly opposite to my understanding of the
logic. Instead, I think it should be,

If Page.IsPostBack Then
'Do something
End If

Because, after the user fills up his/her profile info and hits the
"Submit" button, isn't this data-submission a postback? So, naturally,
we should state in our code, "if this is a postback, please do this and
this."

But, contrary to my understanding, in order for the web server to
really update the user profile, we are required to state, "if this is
not a postback, please do this and this." Hey, if an updating request
from a client is NOT a postback, then what is a postback?

Any kind guru please clarify postback?

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Your confusion is not at all about what a postback is, I think that you
have that clear enough. Your confusion is just what the If statement is
used for.

The code in the "If Not Page.IsPostBack" block is executed when the page
is loaded for the first time. This is used to set the initial values for
controls in the page. When the page loads for a postback, you don't want
to initialise the controls as you want them to get their values from the
data that the user posted.

If you instead want to do something when the page is loaded for a
postback, you use an "If Page.IsPostBack" statement, just as you
thought. This is not used very much, though, that's why you rarely see
it in examples. Usually you use the click event for the submit button to
perform anything on postback.

 

[antonyliu2002]

Your confusion is not at all about what a postback is, I think that you
have that clear enough. Your confusion is just what the If statement is
used for.

The code in the "If Not Page.IsPostBack" block is executed when the page
is loaded for the first time. This is used to set the initial values for
controls in the page. When the page loads for a postback, you don't want
to initialise the controls as you want them to get their values from the
data that the user posted.

If you instead want to do something when the page is loaded for a
postback, you use an "If Page.IsPostBack" statement, just as you
thought. This is not used very much, though, that's why you rarely see
it in examples. Usually you use the click event for the submit button to
perform anything on postback.

Thank you so much. But I am still not clear. So you suggest that in
plain English, "If Not Page.IsPostBack" simply means "If this page is
being loaded for the first time"?

So, in other words, if I have

If Not Page.IsPostBack Then
'populate the textboxes with the latest stored session values.
End If

I am saying, "If this page is loaded for the first time, please fill up
the textboxes with whatever info the user has just supplied?"

Then, in what kind of situations, a page is NOT considered being loaded
for the first time?

 

[Mark Rae]

Then, in what kind of situations, a page is NOT considered being loaded
for the first time?

When it's being posted back.

Consider a page which displays a record fetched from a database so that the
user can edit it.

1) When the page first loads (i.e. it is NOT being posted back to itself for
server-side processing), it fetches the record from the database and
displays its various fields for the user to edit, maybe in TextBox,
DropDownList, CheckBox webcontrols or whatever.

2) The user makes the changes etc and then clicks the Save button.

3) Clicking on the Save button causes the page to post back to itself,
persisting the newly edited values so that they can be written back to the
database.
THE VERY LAST THING YOU WANT TO DO HERE IS FETCH THE CURRENT RECORD FROM THE
DATABASE AND POTENTIALLY OVERWRITE ALL THE EDITS THAT THE USER HAS JUST
MADE!!!

Therefore, the code which does that is surrounded by the IsPostBack logic so
that it DOES NOT RUN when the page is being posted back.

Is this clear now...?

 

[antonyliu2002]

When it's being posted back.

Thanks a lot, Mark.

But, what is postback? What is the definition of postback? What are
involved in a postback event? What exactly is meant by "a page being
posted back to itself"?

There is a two-line definition of postback at webopedia, but it does
not help clear my confusion.

So a postback event ONLY happens on the client side, and its function
is to refresh the screen and persist the newly entered data? And it is
only after this, the new data is sent back to the web server?

I guess I need a definition of postback before I can possibly
understand the whole thing.

AL

 

[Juan T. Llibre]

re:

So a postback event ONLY happens on the client side, and its function
is to refresh the screen and persist the newly entered data? And it is
only after this, the new data is sent back to the web server?

The IsPostBack page property allows you to check whether
it is the first time that the page has been requested, or whether
the page has been requested more than once by the same client,
i.e., whether the page is posting data to itself.

If the page is posting data to itself, IsPostback is true.
If the page is requested from a page other than itself, IsPostback is false.




Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================

 

[Mark Rae]

But, what is postback? What is the definition of postback? What are
involved in a postback event? What exactly is meant by "a page being
posted back to itself"?

OK - think we need a bit of a step back here.

The entire ASP / ASP.NET paradigm works on the fact that the webserver and
web clients are entirely disconnected one from another. Communication
between them is, generally speaking, via an HttpRequest and an HttpResponse.
The client sends a request to the server and the server responds with a
stream of HTML markup back down to the client.

When you first go to a webpage, it is served back to you "clean", for want
of a better description. There may be a QueryString or there may be a Form
object which the server processes to decide what data to serve back to the
client, but that's pretty much it.

With ASP.NET we have the concept of a postback. That means that, in response
to a client-side event (e.g. a button click etc) the page is requested A
SECOND TIME. Behind the scenes a submit action has been intiated on the
page's Form object. Two hidden elements of the page's Form collection tell
the server which webcontrol has initiated this "postback", and which
server-side event to process.

Broadly speaking, that tells the server which server-side code to run. If an
<asp:Button> control has been clicked, it is likely that the event to be
processed with be that button's Click event. The developer writes code
"behind" that event which gets processed with the button is clicked.

Postback is really not much more than a form submission which the server is
able to interpret.

However, through the IsPostback property of the page object, ASP.NET is able
to tell whether the page is being reqested for the first time, or as the
result of a postback. This allows the developer to control which code runs
in either scenario.

Let's say we have an aspx page with the following webcontrols:

<asp:Form ID="MyForm" runat="server">
<asp:TextBox ID="MyTextBox runat="server">
<asp:Button ID="MyButton" runat="server" Text="Save"
OnClick="MyButton_Click" />
</asp:Form>

When the page first loads, it fetches a value from the database, which it
pokes into the Text property of the TextBox.

Let's say we have a Page_Load event as follows:

private void Page_Load(object sender, System.EventArgs e)
{
string strText = <fetch value from database>; // fetch value
MyTextBox.Text = strText; // populate TextBox
}

Now the TextBox is displayed on the webpage with the value from the database
because every time this webpage loads, the Page_Load event fires.

When the Button object is clicked, it will fire the event as defined in its
OnClick property, so we'd better write one...

protected void MyButton_Click(object sender, EventArgs e)
{
string strNewValue = MyTextBox.Text; // get the new value of the
TextBox
<update database with value from TextBox>
}

However, there is an obvious flaw in the above, since the Page_Load event
fires whenever the page is loaded, whether in response to a postback or not.
Therefore the following will happen:

1) The user loads the page for the first time

2) The Page_Load event fires, queries the database, and populates the
TextBox

3) The user edits the value of the TextBox

4) The user clicks the Save button

5) The page is posted back to itself in response to the click of the button

6) The Page_Load event fires, queries the database, and populates the
TextBox - hint: here's the problem!

7) The MyButton_Click event fires, reads the value from the TextBox and
updates the database

We could go round in circles like this ad infinitum. The new value never
gets written back to the database because it's being overwritten with the
old value every time.

Therefore, all we need to do to fix this is surround the code in the
Page_Load event with the IsPostback logic, as follows:

private void Page_Load(object sender, System.EventArgs e)
{
if (!IsPostback)
{
string strText = <fetch value from database>; // fetch value
MyTextBox.Text = strText; // populate
TextBox
}
}

Now, the following happens:

1) The user loads the page for the first time

2) The Page_Load event fires, queries the database, and populates the
TextBox BECAUSE IT'S NOT A POSTBACK!!!

3) The user edits the value of the TextBox

4) The user clicks the Save button

5) The page is posted back to itself in response to the click of the button

6) The Page_Load event fires as it always does BUT DOES NOT RUN ANY OF THE
Page_Load CODE BECAUSE IT'S SURROUNDED BY THE IsPostback LOGIC!!!

7) The MyButton_Click event fires, reads the value from the TextBox WHICH
HASN'T BEEN OVERWRITTEN THIS TIME and updates the database.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

But, what is postback? What is the definition of postback? What are
involved in a postback event? What exactly is meant by "a page being
posted back to itself"?

A postback is when a form with runat="server" is posted back to the same
page.

If you come to the page from a link, from a redirect, from a typed in
url, from a form without runat="server", or from a form with
runat="server" but on a different page, it's not a postback.

 

[antonyliu2002]

OK - think we need a bit of a step back here.

The entire ASP / ASP.NET paradigm works on the fact that the webserver and
web clients are entirely disconnected one from another. Communication
between them is, generally speaking, via an HttpRequest and an HttpResponse.
The client sends a request to the server and the server responds with a
stream of HTML markup back down to the client.

When you first go to a webpage, it is served back to you "clean", for want
of a better description. There may be a QueryString or there may be a Form
object which the server processes to decide what data to serve back to the
client, but that's pretty much it.

With ASP.NET we have the concept of a postback. That means that, in response
to a client-side event (e.g. a button click etc) the page is requested A
SECOND TIME. Behind the scenes a submit action has been intiated on the
page's Form object. Two hidden elements of the page's Form collection tell
the server which webcontrol has initiated this "postback", and which
server-side event to process.

Broadly speaking, that tells the server which server-side code to run. If an
<asp:Button> control has been clicked, it is likely that the event to be
processed with be that button's Click event. The developer writes code
"behind" that event which gets processed with the button is clicked.

Postback is really not much more than a form submission which the server is
able to interpret.

However, through the IsPostback property of the page object, ASP.NET is able
to tell whether the page is being reqested for the first time, or as the
result of a postback. This allows the developer to control which code runs
in either scenario.

Let's say we have an aspx page with the following webcontrols:

<asp:Form ID="MyForm" runat="server">
<asp:TextBox ID="MyTextBox runat="server">
<asp:Button ID="MyButton" runat="server" Text="Save"
OnClick="MyButton_Click" />
</asp:Form>

When the page first loads, it fetches a value from the database, which it
pokes into the Text property of the TextBox.

Let's say we have a Page_Load event as follows:

private void Page_Load(object sender, System.EventArgs e)
{
string strText = <fetch value from database>; // fetch value
MyTextBox.Text = strText; // populate TextBox
}

Now the TextBox is displayed on the webpage with the value from the database
because every time this webpage loads, the Page_Load event fires.

When the Button object is clicked, it will fire the event as defined in its
OnClick property, so we'd better write one...

protected void MyButton_Click(object sender, EventArgs e)
{
string strNewValue = MyTextBox.Text; // get the new value of the
TextBox
<update database with value from TextBox>
}

However, there is an obvious flaw in the above, since the Page_Load event
fires whenever the page is loaded, whether in response to a postback or not.
Therefore the following will happen:

1) The user loads the page for the first time

2) The Page_Load event fires, queries the database, and populates the
TextBox

3) The user edits the value of the TextBox

4) The user clicks the Save button

5) The page is posted back to itself in response to the click of the button

6) The Page_Load event fires, queries the database, and populates the
TextBox - hint: here's the problem!

7) The MyButton_Click event fires, reads the value from the TextBox and
updates the database

We could go round in circles like this ad infinitum. The new value never
gets written back to the database because it's being overwritten with the
old value every time.

Therefore, all we need to do to fix this is surround the code in the
Page_Load event with the IsPostback logic, as follows:

private void Page_Load(object sender, System.EventArgs e)
{
if (!IsPostback)
{
string strText = <fetch value from database>; // fetch value
MyTextBox.Text = strText; // populate
TextBox
}
}

Now, the following happens:

1) The user loads the page for the first time

2) The Page_Load event fires, queries the database, and populates the
TextBox BECAUSE IT'S NOT A POSTBACK!!!

3) The user edits the value of the TextBox

4) The user clicks the Save button

5) The page is posted back to itself in response to the click of the button

6) The Page_Load event fires as it always does BUT DOES NOT RUN ANY OF THE
Page_Load CODE BECAUSE IT'S SURROUNDED BY THE IsPostback LOGIC!!!

7) The MyButton_Click event fires, reads the value from the TextBox WHICH
HASN'T BEEN OVERWRITTEN THIS TIME and updates the database.

Hey, Mark. Thanks so much for dedicating so much time in writing this.
I think I am pretty clear about this issue now.

After I read your eplanation, I realize that it is important to know
that the code is being executed linearly from top to bottom, such that
if every time the code in Page_Load is executed, it overwrites the
newly-entered data. And things happen so fast that we cannot eyeball
it, thus causing quite a bit confusing. (An animated flash movie
showing the whole thing frame by frame will certainly help in an
ASP.NET classroom.) I will save this and share it with my
co-student-worker who is also confused about the whole thing.

 

[antonyliu2002]

A postback is when a form with runat="server" is posted back to the same
page.

If you come to the page from a link, from a redirect, from a typed in
url, from a form without runat="server", or from a form with
runat="server" but on a different page, it's not a postback.

Velli good, much clearer now. Thanks a million.

AL

 

[Mark Rae]

After I read your eplanation, I realize that it is important to know
that the code is being executed linearly from top to bottom,

That's a common mistake that people new to ASP.NET make - there is indeed an
"order of events", but it most certainly isn't "top to bottom" - it may look
like that because Page_Load is by default the first event in the page's
class. However, if you wrote an event and placed it's code above Page_Load,
that would make no difference to when it fired.
http://msdn2.microsoft.com/en-us/library/ms178472.aspx

such that if every time the code in Page_Load is executed, it overwrites
the
newly-entered data.

This was just an example to try to demonstrate one possible effect of not
using the page's IsPostback property...

And things happen so fast that we cannot eyeball it, thus causing quite a
bit
confusing.

??? So put a breakpoint on the first line of each event and step through
your page's entire code line by line...

 

[antonyliu2002]

That's a common mistake that people new to ASP.NET make - there is indeed an
"order of events", but it most certainly isn't "top to bottom" - it may look
like that because Page_Load is by default the first event in the page's
class. However, if you wrote an event and placed it's code above Page_Load,
that would make no difference to when it fired.
http://msdn2.microsoft.com/en-us/library/ms178472.aspx

Thanks a lot for pointing this out. That's entirely correct.

This was just an example to try to demonstrate one possible effect of not
using the page's IsPostback property...


??? So put a breakpoint on the first line of each event and step through
your page's entire code line by line...

I haven't seriously used such debugging tools. But will definitely try.