Saturday, March 31, 2012

What is Postback?

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...stBackTopic.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?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@.yahoo.com wrote:
> 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...stBackTopic.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.
>
> 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?
>
> G=F6ran Andersson wrote:
> 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?
<antonyliu2002@.yahoo.com> wrote in message
news:1163227077.798074.64140@.i42g2000cwa.googlegroups.com...

> 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...?
Mark Rae wrote:
> <antonyliu2002@.yahoo.com> wrote in message
> news:1163227077.798074.64140@.i42g2000cwa.googlegroups.com...
>
> 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

> Consider a page which displays a record fetched from a database so that th
e
> user can edit it.
> 1) When the page first loads (i.e. it is NOT being posted back to itself f
or
> 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 T
HE
> 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...?
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 espaol : http://asp.net.do/foros/
===================================
<antonyliu2002@.yahoo.com> wrote in message
news:1163269209.370081.244660@.f16g2000cwb.googlegroups.com...
> Mark Rae wrote:
> 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
>
>
<antonyliu2002@.yahoo.com> wrote in message
news:1163269209.370081.244660@.f16g2000cwb.googlegroups.com...

> 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.
antonyliu2002@.yahoo.com wrote:
> 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.
Mark Rae wrote:
> <antonyliu2002@.yahoo.com> wrote in message
> news:1163269209.370081.244660@.f16g2000cwb.googlegroups.com...
>
> 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 HttpRespons
e.
> 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 respon
se
> 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 i
s
> able to interpret.
> However, through the IsPostback property of the page object, ASP.NET is ab
le
> 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 TextB
ox
> }
> Now the TextBox is displayed on the webpage with the value from the databa
se
> 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 it
s
> 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 no
t.
> 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 butto
n
> 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 butto
n
> 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 about the whole thing.
G=F6ran Andersson wrote:
> antonyliu2002@.yahoo.com wrote:
> A postback is when a form with runat=3D"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=3D"server", or from a form with
> runat=3D"server" but on a different page, it's not a postback.
Velli good, much clearer now. Thanks a million.
AL

0 comments:

Post a Comment