<antonyliu2002@yahoo.comwrote in message
news:1163269209.370081.244660@f16g2000cwb.googlegr oups.com...
Quote:
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:Buttoncontrol 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.
