I love demonstrating the UpdatePanel to people on a paged, sortable GridView. Especially people who have tried to do the same thing manually. It's a very cool demo.

But I want to say a little something on the problem Atlas doesn't solve for this demo. Let's say you have a page that loads a grid on startup. Then you move ahead a couple of pages and sort the grid on a different field. It's pretty easy to configure the GridView for this so that it shows the proper results. That is, it will sort the results first, then render the third page.

Now let's say the user refreshes the page. If it's a normal ASP.NET page, you'll get the normal warning saying you are about to repost the data you submitted. It sucks that users have had to get used to this little quirk since in reality, what have you really submitted? But c'est la web and until some kid gets fed up enough to actually build Web 2.0 in his basement, we'll have to live with this.

Take the same example with an UpdatePanel. Page ahead two and resort. Again the results are displayed correctly and we have the benefit of not having to regenerate the entire page. But press refresh in this case and the page returns to its original state. I.E. Unsorted on page one. (You can see the effects of this in the sample app I did for Calgary Code Camp; it doesn't page but it sorts.)

In some respects, this is better in that you don't see the annoying popup (or the Page Expired message if you click Cancel). For the most part, though, it's more confusing for general users who would certainly wonder what happened to their results.

The reason this is a problem is familiar to anyone who has done AJAX work. On the one hand, you don't reload the entire page but on the other hand, but as a consequence, the browser hasn't registered that any page change has taken place while you've been merrily clicking away. When you reload a page in the browser, it will load the page as it was first rendered.

Incidentally, this also applies if you do any sort of DHTML work, too. For example, if you add rows to a table on the client, this will get lost when you refresh.

And at its core, Atlas is still AJAX. It doesn't solve any of the architectural problems that go along with AJAX, just some of the developmental ones (while introducing a couple of new ones). If you were to build this same page five years ago using AJAX, you would have the same problem. It's the nature of HTTP.

Note that you can get around this refresh problem with AJAX/Atlas through inventive/bastardized use of cookies. You store data about the grid's current state in a cookie and in the onload event for the body, do some mucking around with DHTML. I imagine this is pretty tough with AJAX because you'll need to know very intimately what the HTML looks like generated by ASP.NET.

But here's another question: what if the user wants to bookmark that exact page number and sort? A cookie won't work in this case. Or rather it might work if the user only ever wants to bookmark one page. Try to bookmark page four as well as page three and you're out of luck. With both AJAX and ASP.NET.

If you do need to support bookmarkable pages (or similarly, the ability to e-mail a page to a friend), the ultimate solution is pretty low tech: use an HTTP GET. Remember HTTP GETs? From the old ASP days? It seems so long, long ago in a galaxy far, far away.

Stick with QueryString parameters to figure out what page you're on and how you're sorting and in what direction. Google does it. Yahoo does it. MSN does it. All search engines do it. They have to. C'est la web. I know, I know. It's not as fun building apps like this in ASP.NET because you pretty much circumvent the entire event architecture they so desperately want you to use. And Request.QueryString seems so twentieth century.

But such is the sacrifice we make for our beloved users.