471,851 Members | 1,235 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,851 software developers and data experts.

Using Atlas UpdatePanels with GridView sorting?

Hi all,

I'm a newbie to Atlas (and recently ASP.NET) after coming from a long
Java background, also have done quite a bit with an Ajax.NET/ASP.NET
1.1 project, but it was basically all javascript, nothing really having
to do with ASP.NET...

I'm attempting to put together an application that consists of several
GridView controls each bound to some xml data. Each table exists in
its own update panel. The two effects I'm going for are:

1. Sorts on the GridView should be handled through a PartialLoad, so
nothing else on the page changes (ideally that HTML wouldn't even be
created on the server side, especially if there is heavy processing
involved in recreating some of the tables).
2. I'd initially like the page to load blank (meaning no GridViews),
then have each GridView come down individually in its own partial load
call, thereby popping up on the screen as they arrive (this is because
the retrieval of data underlying some tables may be a very long
processing call, 1 minute in some cases. Other tables should be
available on the page even while that one is still loading server

So far I've been using UpdatePanels to implement this functionality and
have gotten some good results without truly understanding the lifecycle
of a PartialLoad request indepth (both client and server side).
However there are a few stumbling blocks that I've come across, as well
as questions about how Atlas partial loads are really performing their
job. Any advice that this group can provide would be greatly

I've created a small simulation to post here. We have one aspx page,
with two GridViews, each within it's own UpdatePanel:

<form id="form1" runat="server">
<atlas:ScriptManager ID="ScriptManager1" runat="server" />
<atlas:UpdatePanel ID="panel1" runat="server"
<asp:GridView ID="table1" runat="server"
AllowSorting="true" OnSorting="SortTable">
<atlas:UpdatePanel ID="panel2" runat="server"
<asp:GridView ID="table2" runat="server"
AllowSorting="true" OnSorting="SortTable">
Obviously there is a ScriptManager on the page as well, with
EnablePartialRendering set to true. Next, in the code behind, I just
create a few lists of dummy objects to act as the model data for these
tables. I'm binding the GridView directly to these lists. I added an
event handler to handle the GridView sort calls when clicking on the
table headers, but haven't implemented the sorting yet (it's not
important for this example):

protected void Page_Load(object sender, EventArgs e)
// set up model for first two tables
Table1Model obj1 = new Table1Model("string", "another string");
Table1Model obj2 = new Table1Model("more strings", "and even

Table2Model obj3 = new Table2Model("A", "B", "C");
Table2Model obj4 = new Table2Model("D", "E", "F");

IList<Table1Modeltable1Datasource = new List<Table1Model>();

IList<Table2Modeltable2Datasource = new List<Table2Model>();

table1.DataSource = table1Datasource;
table2.DataSource = table2Datasource;



So the two things I'd like to accomplish go hand in hand here. One is
that I'd like to get the Page_Load to the point where only the GridView
that is being sorted needs to be rebuilt (ie. binding it to the model
again and then having ASP.NET render that HTML). Logically that should
be fine because the only HTML that should get swapped out on the
browser side is the HTML for that particular table. I can do that by
detecting which table fired the sort action using the parameter that
the Atlas PartialLoad seems to put in the Request, __EVENTTARGET. Thus
Page_Load becomes this:
if (!IsPostBack)
... create model like above for both tables on initial page

string eventTarget = Request.Params[__EVENTTARGET]; //
figure out which table asked for the sort.
if (eventTarget.Equals("table1"))
Table1Model obj1 = new Table1Model("string", "another
Table1Model obj2 = new Table1Model("more strings", "and
even more!");
IList<Table1Modeltable1Datasource = new
table1.DataSource = table1Datasource;
else if (eventTarget.Equals("table2"))
Table2Model obj3 = new Table2Model("A", "B", "C");
Table2Model obj4 = new Table2Model("D", "E", "F");
IList<Table2Modeltable2Datasource = new
table2.DataSource = table2Datasource;

This works very well actually (please forgive the code duplication
here, just a silly example).

Now I need to take this to the final step. On the initial page load, I
won't do any databinding at all. The HTML that is delivered to the
browser is just the empty <divtabs for each UpdatePanel. However,
how can I actually trigger the PartialLoad to happen from the browser,
one it has the initial blank page? It must be some custom javascript
that I'll execute in the page load which will essentially make
PartialLoad requests for each of the empty <divtags currently
existing in the page on the browser, and in those Page_Loads I'll
detect that it is a postback, figure out which table needs to load (it
won't be __EVENTARGET in this first case, it'll have to be a parameter
I provide, like the updatePanel name) and then databind just that one
to the model that gets computed (like above). How to execute those
though? Looking at the HTML rendered in the browser when I do render
all the tables at the start, I notice these important bits:

<script type="text/javascript">
var theForm = document.forms['form1'];
if (!theForm) {
theForm = document.form1;
function __doPostBack(eventTarget, eventArgument) {
if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
theForm.__EVENTTARGET.value = eventTarget;
theForm.__EVENTARGUMENT.value = eventArgument;
// -->

and <a
href="javascript:__doPostBack('table2','Sort$Field 4')">Field4</afor
the column headers of every table. When doing theForm.submit(), why
does the browser know to execute this in the background as a partial
load, instead of doing a regular postback in which the user loses the
page and the entire page refreshes? I'm very unclear about that, if I
knew the answer, I could then write my own javascript to do the behind
the scenes postbacks for every table.

Or is there some way that Atlas provides to do this already by setting
up the appropriate properties on the ScriptManager or UpdatePanels?
Also, I do see a lot when researching update panels about providing
triggers, but I don't know how that factors in with triggering sort
events. Does Atlas recognize that the GridView is inside an
UpdatePanel, and create the necessary triggers? Or is this somehow
bypassing that functionality entirely?

Also, is there a way to debug through the client side javascript code
that makes up the Atlas client libraries? Where does one even find
this source, it is hidden within the Atlas.dll?
Thanks for any input!


Oct 11 '06 #1
1 3410
If you don't get an answer here you can try the Atlas (now renammed to
ASP.NET AJAX) forum at asp.net:


Oct 12 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by Chris | last post: by
3 posts views Thread by Piotrek | last post: by
1 post views Thread by majorone | last post: by
3 posts views Thread by Robert Scheer | last post: by
1 post views Thread by tcc.se7en | last post: by
reply views Thread by Eduardo Klein | last post: by
1 post views Thread by Oriane | last post: by
reply views Thread by NeoPa | last post: by
reply views Thread by YellowAndGreen | last post: by
reply views Thread by aboka | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.