Part 2 - Update Pales, Ajax Calls, API

Server Side Programming: Part 2
What’s coming up
1. Client state Loss problem
2. Solutions to state loss problem.
a. Use of update panel
b. Use of ajax calls to API
3. Some Important Controls and Elements and how to handle them.
Client state loss problem

As we know, post backs are the key components that have enabled the whole dynamism in the
web apps. Without post backs none of this could have happened. However, although being critically
important, post backs pose a serious problem. Imagine the following scenario –
You are to develop a lengthy form for a car servicing job entry. The form is so long; the user has to scroll
multiple times to fill it completely. In the middle of the form, you have a field for entering car’s
registration #. After entering it, the operator can press a button to fetch all the past records of the
servicing done to the car.
Here is the code for it
Stateproblem.aspx :
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="stateProblem.aspx.cs"
Inherits="stateProblem" %>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
</head>
<body>
<form id="form1" runat="server">
<div>
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<input type="text" id="carNO" runat="server" />

<asp:Button ID="Button1" runat="server" Text="Produce Results"
OnClick="Button1_Click" />
<textarea id="results" runat="server" rows="8"></textarea>
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
<h1>Dummy</h1>
<br />
</div>
</form>
</body>
</html>
Stateproblem.aspx.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
public partial class stateProblem : System.Web.UI.Page

{
protected void Page_Load(object sender, EventArgs e)
{
string getPast(string no)

{
string op = "";
op += "entry1\n";
op += "entry1\n";
op += "entry1\n";
op += "entry1\n";
op += "entry1\n";
return op;
}
protected void Button1_Click(object sender, EventArgs e)
{
/* since we havent covered the database operations yet
let's just assume this function gives us a <br> separated past servicing
entries
*/
string pastEntries = getPast(carNO.Value);

results.InnerHtml = pastEntries;
}
}
Looks good right? Well the code is correct, although there is a minor issue with it. Let’s run it to analyze
it better.
Please take a look at the scroll bar, its in the middle of the page as the form is quite large in length. Let’s
press the button now.
Whoa ! The page scrolled all the way to up !
However if you scrolled down
So it calculated the results as we intended, but It scrolled up the beginning of the page. Why did this
happen?
Well to be precise, the page didn’t scroll to the top. What really happened was a postback, the button
posted back to server, and the server sent the response with the textarea filled with appropriate entries,
and the client browser just loaded the response. And as we have seen it’s the whole response again, so
naturally, as the browser loaded a new response from the server, it put the focus to the top of the
response.
Now, you might say this is a minor issue, but it’s really not, apart from the obvious annoying bad user
experience to the operator, It’s a really serious issue, the whole page got reloaded, that means any state
stored in the HTML page that server wasn’t aware of is lost. And this state sometimes includes a lot of
data such as a modal is opened, a particular element is highlighted with some color; all such “on page”
things will be lost upon the postback. And loss of such state is really critical. Imagine, you are filling the
same form on a modal, as it is an added functionality to existing page that displays the filled up job
tracks. So when you press the button now, to view the past entries, the entire modal on which you were
filling the form would be gone! This is because the modal is open (meaning its display property set to
block) is only known to the client not the server (why?), hence the server wouldn’t set the modal’s
display to block upon the post back, and the modal will be invisible upon the post back.
As a thumb rule of web programming, post backs are very expensive (it’s a round trip to server via the
slow and unreliable internet), hence we always try to make the number of postbacks as minimum as
possible. And hence a lot of processing is done on client side, and it is really critical, (as you would see in
real world development scenario), to not to lose that client state.
Solution to state loss problems

If you think closely on the problem, it would appear that the entire mess was because of the
entire reloading of the response from the server. To solve this problem, thus, there are 2 approaches –
1. Load only that content of the response that has changed in the postback. This is called as update
panel approach.
2. Change the postback in such a way that it only sends the response of required info and not the
response with the whole page. So the post back in this case would only return those “entry”
strings and not the entire page. Load this response to an appropriate container in the page. This
is called API approach.
As you might have guessed, the API approach is always better, since it returns as well as loads only
concerned info, whereas the update panel approach returns whole page, but only loads what’s changed
from last response.
However, as with all the good things in life, the API approach is more pain to implement. The update
panel approach is easier to implement. So there is a tread off between two. And we generally tend to
make the decision about which approach to follow based on particular task we want to achieve. If it’s
not so performance heavy task, we may go for the update panel approach. If it’s a lengthy page, itself,
and the postback is going to add further more info on it, we may go for API approach. It really depends
on what you are trying to achieve. You will develop the sense of what to use in coming future.
We are going to solve the problem using both. Let’s take a look at update panel approach first.
Update panel approach
What it does –
Update panel is a special panel, which blocks the loading of entire response of a post back. Instead it will
analyze the response and only reload the content within it that has changed. Key points to remember
here are – it only loads the content that is within the update panel and that too if it has changed.
So if there are some changes in the outside elements of update panel, the update panel will reject those
changes.
Also it is worthwhile to mention here that update panel only analyzes those postbacks that have been
generated by one of the triggers of the update panel. By default, all the controls placed inside an update
panel will be triggers to the update panel.
Let’s explain it more, take a look at the modified section of stateproblem.aspx file –
<asp:UpdatePanel ID="UpdatePanel1" runat="server">

<ContentTemplate>
<input type="text" id="carNO" runat="server" />

<asp:Button ID="Button1" runat="server" Text="Produce Results"
OnClick="Button1_Click" />
<textarea id="results" runat="server" rows="8"></textarea>
</ContentTemplate>
</asp:UpdatePanel>
Also the update panel requires a script manager on the page, so we have added it just
below the form element
<form id="form1" runat="server">

<asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager>
So we have placed the input, button, and the text area inside the <contenttemplate> tag of the update
panel, that means they are inside the update panel now. Hence update panel will catch any updates
made to these elements/controls. Also it will only consider changes made by those backs that are
generated within the update panel. Currently there is only one post back generating control in update
panel i.e. the button. Hence the button, when pressed, will cause a post back, the server will execute
the button_click mehod, would generate a new post back, send it to browser, the update panel will
block the post back, since it has been generated by one of its triggers, it would analyze to see for any
changes in the elements which are inside the update panel, it will the textarea’s inner HTML is modified
in the postback, so it will load the new inner html for the text area, and it will load only that, nothing
else. Hence the page doesn’t scroll now, and the client state is not lost. Run it, and verify the results by
yourself.
At this point, I would like you to answer yourself following questions,
1. What would happen if the CarNO input is put outside update panel
2. What would happen if the results textarea is put outside update panel
3. What would happen if the button if placed outside the update panel. Why ?
If we are adamant on putting the button outside the update panel, what needs to be done? research on
it, and do it, that will be the problem for this tutorial. There are two solutions to this problem.
1. Add an outside button to update panel’s triggers

2. Use javascript function - ‘__doPostBack(‘ButtonID’, ‘’)’ to generate a post back for a button that
is placed inside an update panel from any element that is placed outside the update panel. This
is a particularly important scenario. We will discuss more on it in later stages of tutorial.
The 2nd solution to the state loss problem, i.e. the one involving use of APIs will be covered in next
tutorial.
The controls, and elements after that.

Part 2 - Update Pales, Ajax Calls, API

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Part 2 - Update Pales, Ajax Calls, API

Загружено:

Авторское право:

Доступные форматы

Server Side Programming: Part 2

Client state loss problem

Here is the code for it

<input type="text" id="carNO" runat="server" />

public partial class stateProblem : System.Web.UI.Page

string getPast(string no)

string pastEntries = getPast(carNO.Value);

However if you scrolled down

Solution to state loss problems

<asp:UpdatePanel ID="UpdatePanel1" runat="server">

<input type="text" id="carNO" runat="server" />

<form id="form1" runat="server">

At this point, I would like you to answer yourself following questions,

1. Add an outside button to update panel’s triggers

The controls, and elements after that.

Вам также может понравиться