Having the option to manage AJAX history from both the server-side and client-side lends itself really nicely to being able to accomodate a large number of situations. If you’re looking to add some history functionality to an existing web page that was developed using server controls, it is pretty painless to drop in a ScriptManager and UpdatePanel and go off on your merry way. If you’re creating a web page from scratch and you’re looking to get as streamlined as possible, then using the Sys.Application class in the ASP.NET AJAX library can make all of your history dreams come true. Unfortunately it isn’t always that cut-and-dry though, and sometimes a single application, or even a single page, might have multiple peices of functionality in it that have different needs. The question that arises is this: can both history approaches be easily leveraged within the same application or page and functionality properly? The answer to that can be derived from a 70’s English rock band:
Not only can the two approaches co-exist, in many ways they feel like they were meant to live together. Remember how it was mentioned that in the state URL all server-side history points are appended after a double ampersand whereas all client-side history points preceed the ampersands? That fact alone makes the intermingling of the two to successfully work.
What we’re going to do is take both versions of the quarterback selector app (client and server editions) and mash them together onto the same page. We’re not even going to touch a single character of code. I’ve added some extra text and HTML to make the overall demo look a little more compelling. If I run the app, this is what we’ll see:
This should obviously look pretty familiar to you by now. The client-side portion is 100% JavaScript code, while the server-side porition is leaning on the ScriptManager and UpdatePanel server controls. What would you expect to happen if we began selecting quarterbacks from both lists at the same time and then trying to use the back and forward buttons? If you are the type of person who doesn’t like to take risks I would recommend you stop reading here. If you are completely insane and love living life on the edge, the continue reading because extreme awesomeness is about the ensue.
Let’s start by selecting a quarterback from the client-side list to make sure it still works. Let’s go with David Garrard:
So far so good. Let’s now try to select a quarterback from the server-side list to ensure that implementation still works. Let’s go with Brett Farve:
Alright so both implementations seem to work beautifully, but that doesn’t prove that our history is working. I notice that my browser’s back button is active which makes me wonder what will happen if I click it’s pretty blue little face. What do you think?
Is that cool or what? The back button undid the last action, which in this case was the server history point, but didn’t affect the client history point. You might have originally thought that hitting the back button would have removed both selections, because it would be backing out of both the client and server side history “buckets”. So how does this work? I’m going to hit the browser forward button to redo our server-side selection and then examine the current URL:
http://localhost:49652/#FavoriteQuarterback=David%20Garrard%20&&FavoriteQuarterback=Brett+Farve
Doesn’t get much clearer than that. You can easily see the two history points seperated by client/server. The point before the double ampersand is the client history point and the one following the double ampersand is the server history point. What that means is that I could bookmark my page right now and when I return it will recreate both selections. Because the URL contains state information for both the client and the server approaches, the ScriptManager’s Navigate event will be fired as well as the Sys.Application class’s navigate event. I think that is just too cool. I could sit here and click on both lists all day long, repeatedely hit the back button, and then watch it undo every one of my selections from each list individually. I would recommend going crazy with it, it really drives the point home just how awesome this is.
At the conclusion of this three-part series on ASP.NET AJAX History, hopefully your minds are running wild with ways you can begin implementing it into your applications. While this may not be the most groundbreaking feature to be released this year, it certainly shouldn’t be thrown to the wayside. It’s a very powerful little feature that can really increase the useability of a web page for a user with little effort from the developer.
