Part 1 - Introduction
Part 2 - Basic Example
Part 3 - Complex Example
Part 4 - Final Notes
Bonus - Ajax History and the Memento Pattern
Extra Bonus - Issues with Opera

I dedicate this blog to Tomi, who brought this issue to my attention. Without I would be blissfully unaware that my ajax examples did not work with Opera.

To make a long story short, the basic Ajax history points that are demonstrated starting in this blog entry and on the site here fail miserably when used by Opera, even the most recent v 10. It would go forward once and then fail on either the next history point or going backwards. It worked fine if history was not stored.

At first I thought that it might have to do with Validation, so I turned off Event Validation and ValidateRequests but no dice. I tried modifying the LoadScriptBeforeUI setting on the ScriptManager thinking that maybe Opera was attempting to access the controls before they were instantiated. No dice.

Looking at the "Error Console" in Opera gave this confusing information:

JavaScript - http://www.myfriedmind.com/ajaxexamples/AjaxSimplehistory.aspx
Unknown thread
Error:
name: Sys.WebForms.PageRequestManagerServerErrorException
message: Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 400
stacktrace:   Line 5 of linked script http://www.myfriedmind.com/ScriptResource.axd?d=Ca9Q30sQJzQkznL95cxsbDyIKgsvVPJZcb1rw8ROyNsMckgQG68w3ACHnEiANP
BR_VaW0NUFhahnNTwkTQZ39NfZ8sEeH0NKN9NzfqKtjhs1&t=40a63f28
    function(a,d,f){if(this._request===d.get_webRequest()){this._processingRequest=false;this._additionalInput=null;this._request=null}var e=this._get_eventHandlerList().getHandler("endRequest"),b=false;if(e){var c=new Sys.WebForms.EndRequestEventArgs(a,f?f.dataItems:{},d);e(this,c);b=c.get_errorHandled()}if(a&&!b)throw a}
.....

The key is that it was not returning the 200 that we all know and love, but a 400 status. Per this Msoft article (kb 247249) -

If the contents of a GET request are corrupt, then the server is unable to determine the URL or the host to which the GET request should be sent. IIS is unable to retrieve the host information from the GET request packet in order to look up the meta data for the custom error. This is by design. Errors that result from severely corrupted GET requests are not customizable.

Now I KNOW that they are not corrupt. It works perfectly fine with IE and Firefox. When I run it on Fiddler (http://www.fiddler2.com/) - my go-to tool for troubleshooting odd Ajax problems I do see the 400 returned. Note in the picture that the first three are for IE which work (all 200s) the second set of three is for opera - the final one being the 400 error.

When I look at the raw data of that entry it tells me that the response is that it is getting a Bad Request <Invalid URL> (see below). hmmmmm, should I trust it?

Hunting and pecking I find various entries dealing with Opera and its issues with Ajax, most of them from years ago. And then I discover this gem: http://www.webmasterworld.com/javascript/3195000.htm which has this notation near the end (italics mine)

opera has a rather annoying bug. This occurred in both 8 and 9: If the URL is exactly the same, the PHP file results are cached, and all the requests terminate as soon as the first result is returned. IE does the same, but I was able to fix it by spitting out a couple of "no-cache" headers. opera ignores these headers.

I fixed that by adding an "id=" parameter to the URL, which made each URL unique. This forced opera to stop caching.

Wha??? So I added a querystring to the end of my url (it does not matter what it is) and it worked! In other words http://www.myfriedmind.com/ajaxexamples/AjaxSimplehistory.aspx?x=y will work in Opera but http://www.myfriedmind.com/ajaxexamples/AjaxSimplehistory.aspx will not.

Now here is the odd part, and to display it I am going to direct you to a slight different simple ajax example I just whipped up -> http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx. I am also going to give you a behind the scenes look (via fiddler) as to what, exactly, Opera is 'requesting'. The main modification I did was to change the length of the text used for the history point (I am only going to store hour, minutes, seconds to expedite this) to make it shorter and easier to view.

Again http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx works for the first one and fails for the second.

First, let us look at what happens in IE per Fiddler (note that I only include the querystring here for comparison, this example works in IE without it).

• clicking on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y 
  Post /ajaxexamples/AjaxSimpleOpera.aspx
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=042004
• clicking on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx#&&myTime=042004 
  Post /ajaxexamples/AjaxSimpleOpera.aspx
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx#&&myTime=042006
• clicking on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx#&&myTime=042006  
  Post /ajaxexamples/AjaxSimpleOpera.aspx
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx#&&myTime=042007
• clicking on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx#&&myTime=042007
  Post /ajaxexamples/AjaxSimpleOpera.aspx
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx#&&myTime=042008

Now the Opera per Fiddler -

• Now adding a querystring on to the end - ex: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y works. But notice what is happening behind the scenes with each click
• click on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y
  POST /ajaxexamples/AjaxSimpleOpera.aspx?x=y
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041426
• click on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041426
  POST /ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041426
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041443
• click on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041443
  POST /ajaxexamples/AjaxSimpleOpera.aspx?x=y%23&&myTime=041426#&&myTime=041443
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041443
• click on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041443
  POST /ajaxexamples/AjaxSimpleOpera.aspx?x=y%23&&&myTime=041426%23&myTime=041443#&&myTime=041535
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=0414535
• click on http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=0414535
  POST /ajaxexamples/AjaxSimpleOpera.aspx?x=y%23&&&&myTime=041426%23&myTime=041443%23&myTime=041535#&&myTime=041537
  new url: http://www.myfriedmind.com/ajaxexamples/AjaxSimpleOpera.aspx?x=y#&&myTime=041542

Okay, okay, there was a long time between clicks (I was pasting it over), but do you notice anything different between the two (pay attention to the POST that is done via Ajax)? Internet Explorer ALWAYS Posts to the same URL - it ignores the hash entry. Opera prepends the previous hash entry after encoding it for the url, and so it gets longer and longer.

What is really, really odd is that Opera keeps prepending EVEN WHEN YOU HIT THE BACK BUTTON! So moving back and forth in your ajax history means that you are getting a longer and longer request entry. If you want to see this, snag fiddler -> http://www.fiddler2.com and try it. Your POST request gets longer and longer due to the prepending, but the URL does not reflect this at all. This ALL happens under the covers.

I finally went into Opera and tried turning off ALL caching (disk and otherwise). No luck! And when I set it to pretend to be IE it threw an error on the history point setting, claiming it was not asynchronous. I even went into opera:config under User Prefs and set the "History Navigation Mode" to 1 per this article http://www.opera.com/support/kb/view/827/ to prevent what it calls "fast history navigation". Still no dice! I even set the Opera to "Always Reload Https In History" and then connected via https to the page and that failed as well.

So why does adding a query string work? I honestly don't know. But this might be a clue - when it succeeded the hash was passed as a query string variable in Opera. When it failed, no query string was passed at all. There are a number of posts all over the web that refer to Opera caching when it should not, so I suspect that that may indeed be the issue - Opera is caching the page regardless of what it is told. Only by including the query string can you force Opera to not do whatever it is doing.

So there appear to be three solutions

1. Don't use Ajax history for Opera unless you use a query string (it might work in systems other than .net, I have not tested this)
2. Get Opera to fix the issue (good luck!)
3. Make sure you have a querystring, even a nonsense one, if your users will be using Opera...

Happy coding!

----------

Further notes:

This article -> http://cfis.savagexi.com/2007/06/12/opera-ajax-and-bugs talks about an issue with Opera rejecting status codes other than 200. However that is probably not the issue since it should be returning a 200 code anyway. Just something to keep in mind.

Now I should note assuming that it was a caching issue I added a bunch of code to prevent caching - including the ones below:

Response.ClearHeaders();
Response.AppendHeader("Cache-Control", "no-cache");
Response.AppendHeader("Cache-Control", "private");
Response.AppendHeader("Cache-Control", "no-store");
Response.AppendHeader("Cache-Control", "must-revalidate");
Response.AppendHeader("Cache-Control", "max-stale=0"); 
Response.AppendHeader("Cache-Control", "post-check=0"); 
Response.AppendHeader("Cache-Control", "pre-check=0"); 
Response.AppendHeader("Pragma", "no-cache"); 
Response.AppendHeader("Keep-Alive", "timeout=3, max=993"); 
Response.AppendHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT");
Response.Cache.SetExpires(DateTime.UtcNow.AddMinutes(-1));
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();

But again, the only thing that appears to resolve the issue is the inclusion of a query string.

Part 1 - Introduction
Part 2 - Basic Example
Part 3 - Complex Example
Part 4 - Final Notes
Bonus - Ajax History and the Memento Pattern

There is some clean up I need to do in regards to my posts for Ajax History.

Where can I see an example?

You can download the zipped files here -> AjaxExamples.zip or go to http://www.myfriedmind.com/AjaxExamples and poke around

What version of .net do I need?

I want to reiterate that you must be using .net 3.5 (or higher) for this to function. The methods and properties that are used are packaged into .net 3.5 (as is Ajax itself).

How long does my history last (ie going back/forward)?

Your history lasts only as long as you are on that particular page. You can go forward and backward over your Ajax history all you want, but once you got to a different page, either preceding or following, you lose your pathway. This does not mean that if you get one of the intermediate URIs either through bookmarks, links, manually typing, etc that it will not return that particular page. It will. But the tracking of the entries in your browser history will be lost.

This also means that if the user modifies the URI manuallyto change what is in the has, it will lose that history since it considers you having gone to a new page.

What if I need to keep a perfect snapshot of the page itself?

If that is the case then you are going to need to look at a different way to store/retrieve the data. You will probably need to store each page, as it appears, into the database and then recall it from there. Do NOT store it in the History Points Remember, what is stored in the History Points must be tiny!

Why does Opera NOT WORK???

http://www.myfriedmind.com/techBlog/2009/09/21/Opera9x10xFailingOnAjaxHistoryAndTheHackToFixIt.aspx (thanks to Tomi for discovering this issue)

Part 1 - Introduction
Part 2 - Basic Example
Part 3 - Complex Example
Part 4 - Final Notes
Bonus - Ajax History and the Memento Pattern
Extra Bonus - Issues with Opera

This is the third in a series looking at using Ajax History in .net 3.5. I would recommend you look at Part 1 and Part 2 if you have not already done so.

Ajax out of the box is wonderful in that it reduces page reloads, but it is not wonderful in that it does not treat each Ajax call as a unique URI. As a result all Ajax modified changes are lost when the Back or refresh button are clicked. In addition there is no way to store the URL of the page in such a way that it will display the results of Ajax changes. I explain much of this in Part 1. In Part 2 I provide (very) basic example of storing/retrieving Ajax changes. However in the real world we do not live with simple pages. Most of what we want to reconstruct are complex systems. This post will attempt to give a real-life example of such a functionality.

Many people use mapping pages as an example of how to do Ajax history functionality. That is very nice because, especially for retrieving the pages, because the world generally changes very little geographically. Longitude and Latitude have been fairly constant since the early explorers. GPS does not change from year to year. So it is the perfect example of how you can use a small portion of data (GPS coords for example) to return a large complex data (a map). This is similar to the Memento pattern (take a look at http://www.myfriedmind.com/techBlog/2009/05/20/AjaxHistoryAndTheMementoPattern.aspx for more on my thoughts on that).

Using a Memento pattern is critical because if you were to try to store all that complex data in the Ajax history it would quickly fall to pieces.

So, rule #1 - do not store complex data, store simple data that can be used to reconstruct complex data

While racking my brain for what to use as a non-map example, I came across a post by Senthilkumar Moorthy on forums.asp.net in which he lays out an interaction using Ajax that I thought would be a useful example since it uses multiple history points

The page layout

For simplicity sake I am keeping their names fairly generic and not adding a lot of extra (fun) code...

• There are two UpdatePanels (upPanel1 and upPanel2).
• upPanel1 contains a TextBox (textBox1), a Button (button1) and a DropDownList (ddl1)
• when the user enters in phrase in textBox1 and clicks button1, ddl1 is populated with subchoices
• when the user clicks on ddl1 to select a choice, upPanel2 displays the details of the selected item in a handful of labels

It should be noted that I am using the Adventure Works (light) database as my source of data.

1. I will use textbox1 to search through ProductDescription and return a list of possible matching items into ddl1.
2. Selecting an item from ddl1 will then display information about that particular item in the details pane.

I have also included a class in the page called ProductInformation.

The history point events

The first thing to consider is where we want to put our history points. Ie, where do we want, if the user clicks 'Back' to roll them back to. Also, what do we want, if they post the URI, to display. It seems to me that there are clearly two logical places and these all take place when events occur (which is a good way to start)

1. when the user clicks button1 to populate ddl1
2. when the user selects an item from ddl1 and the detail is displayed

First off, note that we are storing three connected, but different points of data, as opposed to the single point in the simple example of Part 2. In addition we are having to store the Page Title (more on that later) because of an apparent issue with the way that .net handles that.

The caveats

The biggest issue here is that data changes. Here are a few possibilities

1. the entry of the textbox1 is no longer valid and returns no matching items
2. the selected item of ddl1 is no longer valid and returns no matching product
3. the details in upPanel2 have changed since the last update

Again, if this were simply mapping, #1 and #2 (changes in basic data) would not be an issue. And since most people want the most up-to-date maps, #3 does not matter. However, we are going, for the sake of study, assume that we care about all 3 of these potential issues. This means we are going to have to handle that in a graceful way when we unpack it to recreate the data.

I have the sample code included below for you to download and I am using the AdventureWorksLT for my data. You can snag it from CodePlex at http://www.codeplex.com/MSFTDBProdSamples/Release/ProjectReleases.aspx?ReleaseId=4004 . The code itself is fairly rough in patches since I really wanted to hit the main points about Ajax History but let me know if I need to clarify any section of it just so you can understand what I am attempting to show.

Creating the basic methods to create the page display

My methods for populating the DDL are as follows:

    private void PopulateDDL(string text)
    {
        ddl1.Enabled = true;
        StringDictionary _results = GetMatchingDescriptions(text);
        if (_results != null)
        {
            ddl1.DataSource = _results;
            ddl1.DataTextField = "Value";
            ddl1.DataValueField = "Key";
            ddl1.DataBind();
        }
    }
    private void PrefixDDL(string text, string value)
    {
        ddl1.Items.Insert(0, new ListItem(text, value));
        if (ddl1.SelectedIndex != -1)
        {
            ddl1.SelectedItem.Selected = false;
        }
        ddl1.Items[0].Selected = true;
    }

My method for the Display Info (upPanel2) are as follows:

    private void DisplayInfo(string selectedValue, DateTime requestedOn)
    {
        if (String.IsNullOrEmpty(selectedValue))
        {
            DisplayError("That selection is no longer valid. Please retry");
        }
        else
        {
            int _productId;
            if (Int32.TryParse(selectedValue, out _productId))
            {
                ProductInformation _product = GetProduct(_productId);
                if (_product == null)
                {
                    DisplayError("That selection could not be found. Please retry");
                }
                else
                {
                    lblLastModified.Text = _product.LastModified.ToString("F");
                    lblName.Text = Server.HtmlEncode(_product.Name);
                    lblModel.Text = Server.HtmlEncode(_product.Model);
                    lblDescription.Text = Server.HtmlEncode(_product.Description);
                // what if the data is old? notify the user
                    if (requestedOn < _product.LastModified)
                    {
                        lblRequestedOn.Text = String.Format("This item has been modifed since request at {0}", requestedOn.ToString("F"));
                    }
                    else
                    {
                        lblRequestedOn.Text = requestedOn.ToString("F");
                    }
                }
            }
            else
            {
                DisplayError("That was an invalid selection");
            }
        }
    }
    private void ResetDisplayInfo()
    {
        lblRequestedOn.Text = "";
        lblLastModified.Text = "";
        lblName.Text = "";
        lblModel.Text = "";
        lblDescription.Text = "";
    }
    private void DisplayError(string errorText)
    {
        ResetDisplayInfo();
        lblName.Text = errorText;
    }

I will call these methods not merely when the page is initially created but also when it is REcreated during the ScriptManager's Navigate command.

Creating the HistoryPoint methods/event handler

Apart from the modifications that are made similar to what was done on Part 2, the main changes deal with the methods to store the History Points and to recreate the page after the History Points have been reloaded. In other words what happens when a History Point is set and what happens when a History Point is retrieved. Because we do not want to store the ENTIRE page in the browser URI the fundamental question is "what can I get away with?" This is a good time to practice your YAGNI (You ain't gonna need it) to eliminate all but the most essential and simplest pieces of information. In this case I have three pieces that can not be reduced any more

1. the text in the textbox
2. the selected value of the dropdown list
3. the DateTime that the page was loaded (to see if the data has been changed)
4. (bonus) In addition, due to a 'feature' of Ajax History in .net 3.5, I am also including the Page Title. I will discuss more about this later, but just know that it is included.

My method to store the History Point looks like this:

    protected void StoreHistoryPoints(string textBoxText, string ddlValue,
        DateTime requestedOn, string pageTitle)
    {
        ScriptManager _mySM = ScriptManager.GetCurrent(this.Page);
        NameValueCollection _historyPointEntries = new NameValueCollection();
        _historyPointEntries.Add("whatTextBoxContains", textBoxText);
        _historyPointEntries.Add("whatWasSelectedInDDL", ddlValue);
        _historyPointEntries.Add("requestedOn", requestedOn.Ticks.ToString()); // ticks are shorter in length
        _historyPointEntries.Add("pageTitle", String.Format("AV - {0}", pageTitle));
        _mySM.AddHistoryPoint(_historyPointEntries, String.Format("AV - {0}", pageTitle));
    }

It is very straightforward. I create a NameValueCollection to hold my minimal data and then call the AddHistoryPoint.

Before I continue I should mention that there are three overloaded methods for AddHistoryPoint

• ScriptManager.AddHistoryPoint(string, string)
• ScriptManager.AddHistoryPoint(string, string, string)
• ScriptManager.AddHistoryPoint(NameValueCollection, string)

The second two have an additional string parameter which is used to set the Page Title when the History Point is stored. In this example I use it to set the Page Title to whatever bike model that they are looking at. Thus if they save it in their favorites it gives a user friendly name.

HOWEVER!!! While this works going forward that information is lost when the Navigate method is called and the HistoryPoint information is unpackaged. Ie - going forward the ScriptManager changes the Page Title, but when the page is loaded using the "Back" button or from a manually typed URI, it does not set the Page Title, nor is it accessible through the HistoryEventArgs. As a workaround I have included the Page Title as one of the KeyValue pairs in my history point so that I can recreate along with the rest of the page. Of course, since this is an issue I could simply have set the Page Title manually (for example in the portion of the code that determines the bike to display) but I wanted to show you this overload.

Also note that I could as easily have done this in my method:

    protected void StoreHistoryPoints(string textBoxText, string ddlValue,
        DateTime requestedOn, string pageTitle)
    {
        ScriptManager _mySM = ScriptManager.GetCurrent(this.Page);
        _mySM.AddHistoryPoint("whatTextBoxContains", textBoxText);
        _mySM.AddHistoryPoint("whatWasSelectedInDDL", ddlValue);
        _mySM.AddHistoryPoint("requestedOn", requestedOn.Ticks.ToString()); // ticks are shorter in length
        _mySM.AddHistoryPoint("pageTitle", String.Format("AV - {0}", pageTitle));
    }

There is actually no discernable difference except for the Page Title being handled by the Script Manager going forward. The NameValueCollection that the HistoryEventArgs of the ScriptManager's Navigate method returns are the same in both methods. The code that I display below for the Navigate event handles them exactly the same because both return the same NameValueCollection.

Quick note also that all these entries must be string values (they are stored in the URI after all). For this reason I have changed the DateTime to use ticks instead of writing it out, but you could have easily have chosen a format which would return a simpler string. The key is to approach this with a minimalist attitude. Not being too obsessive, but the shorting the string, the shorter the URI, the better for the system.

Recreating the page

Now I have the process in place for the storing of History Points. I can call this method as my final command from both the button1_Click event handler and the ddl1_SelectedIndexChanged event handler and it will store the information I pass it into the history. The Page does not need to know what this data represents. It is the Caretaker (see Ajax and Memento). All it knows is that it needs to store this information and return it when requested.

The second portion is the unpackaging when the History Points have been returned. This is handled through the ScriptManager's Navigate event. One quick thing to note - this event is called when the "Back" or "Refresh" commands are given to the browser, but it also is called when the page is loaded with the specific History Point URI, for example from a "Bookmark" or from a link.

My event handler looks like this:

   protected void sm1_Navigate(object sender, HistoryEventArgs e)
    {
        long _requestedOnAsTicks;
        bool _hasHistory = long.TryParse(e.State["requestedOn"], out _requestedOnAsTicks);
        if (_hasHistory)
        {
            DateTime _requestedOn = new DateTime(_requestedOnAsTicks);

            string _textStored = e.State["whatTextBoxContains"];
            if (!String.IsNullOrEmpty(_textStored))
            {
                // restore entries on TextBox and DDL
                textbox1.Text = _textStored;
                PopulateDDL(_textStored);
            }
            string _ddlValueStored = e.State["whatWasSelectedInDDL"];
            if (!String.IsNullOrEmpty(_ddlValueStored))
            {
                ListItem _matchingItem = ddl1.Items.FindByValue(_ddlValueStored);
                if (_matchingItem != null)
                {
                   // we have victory, display the item...
                    _matchingItem.Selected = true;
                    DisplayInfo(_ddlValueStored, _requestedOn);
                }
                else
                {
                    // something is wrong, the item no longer shows. Display error...
                    ListItem _errorItem = new ListItem(_ddlValueStored, "");
                    DisplayInfo("", _requestedOn);
                }
            }
            else
            {
                // since no DDL value was selected, add prompt at beginning of DDL
                PrefixDDL("Select One", "");
            }

            // this is a required hack because even though page title is specified in the AjaxHistory, it
            // does not work when you navigate backwards..
            string _pageTitle = e.State["pageTitle"];
            Page.Title = _pageTitle;
        }
        else
        {
            // if there is no DateTime stored than this is the original (ie no history) -> reset form
            textbox1.Text = "";
            ddl1.Items.Clear();
            ResetDisplayInfo();
            Page.Title = "AV";
        }
    }

The Navigate event uses the HistoryEventArgs. This really only has one thing in there - the State, which is the NameValueCollection that you passed the ScriptManager during the AddHistoryPoints calls.

The first thing I do is see if there is anything in there. Since I am wanted to get the date and the TryParse is a convenient way for me to verify that it is a valid long, I check it there. If there is no history than this is a non-modified Ajax Page (probably the very beginning) and I simply reset everything.

Once I know there is a history I have to go through the process of recreating the page. I extract the appropriate information and repopulate the Textbox, the DropDownList (if appropriate) and the Display (if appropriate). By doing this I am creating a complex page from simplistic data.

Because my data may have changed (say the Description has been updated) I have also included a notification to the user if this takes place in the DisplayInfo method. However, I no longer have access to the original data. That data is lost to me because all I am passing are the minimal pieces to recreate the page. What is displayed is the CURRENT information on that particular product.

Also, note the setting of the Page.Title. Remember that even though I did pass that as a parameter during my AddHistoryPoint method call, it is no longer available to me during the Navigate event. If you want to use a unique Page Title when an Ajax modification takes place, make sure to pass the Page Title as its own KeyValue pair and then unpack and recreate it.

Final Notes

If you have stuck in this long, congrats!!! I know this may still seem murky, probably more due to my explanation than to anything else, but there are a few more things I want to touch on. I will actually them in my (potentially) last blog on this - part 4 - wrap up.

Zipped Example

AjaxExamples.zip (1.37 MB)

Part 1 - Introduction
Part 2 - Basic Example
Part 3 - Complex Example
Part 4 - Final Notes
Bonus - Ajax History and the Memento Pattern
Extra Bonus - Issues with Opera

Handling Ajax history has been a critical issue since Ajax first started. With the advent of .net 3.5 the ability to easily deal with that is rolled into the code. This is part 2, here we will look at a simple example of handling Ajax history to give a basic understanding of the process. If you have not read Part 1, I suggest you do that now. Part 3 will expand on handling Ajax history when the data is more complex.
For simplicity sake we are only going to look at an example of very, very basic history. We are going to look at a page that displays changes made to the time.

A basic assumption is that you are fairly familiar with Ajax (http://ajax.asp.net). We are going to be using the ScriptManager (of course) and an UpdatePanel.
Our basic page looks like this

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="AjaxHistory.aspx.cs" Inherits="AjaxHistory" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <asp:ScriptManager runat="server" ID="sm1" EnablePartialRendering="true" />
    <div>
        <asp:UpdatePanel runat="server" ID="upME">
            <ContentTemplate>
                <asp:Button runat="server" ID="uxChangeTime"
                    OnClick="uxChangeTime_Click" Text="-- change:" />
                <asp:Label runat="server" ID="lblTime" />
            </ContentTemplate>
            <Triggers>
                <asp:AsyncPostBackTrigger ControlID="uxChangeTime"
                     EventName="Click" />
            </Triggers>
        </asp:UpdatePanel>
    </div>
    </form>
</body>
</html>

The codebehind sets the label text to be the current date/time on every click:

(c# code)
protected void uxChangeTime_Click(object sender, EventArgs e)
{
    string _currentDateTime = DateTime.Now.ToString("F");
    lblTime.Text = _currentDateTime;
}

(vb code)
Protected Sub uxChangeTime_Click(ByVal sender As Object, &_
  ByVal e As System.EventArgs) Handles uxChangeTime.Click
    Dim _currentDateTime As String = DateTime.Now.ToString("F")
    lblTime.Text = _currentDateTime
End Sub

As you can see this is fairly straightforward. Clicking on the button displays the current DateTime in the label. However, there is no history. Clicking back will not display the last DateTime displayed but either be grayed out (if this was the first page loaded) or take you back to the page before this one.

To enable history is very, very simple in 3.5

1. modify the ScriptManager, setting a property or two and registering an event (Navigate) for the ScriptManager
2. modify the Click handler to notify the ScriptManager to record a History Point
3. handle the event called by the ScriptManager to rollback, when required, the page

Step 1: Modify the ScriptManager

The modifications are very simple - set EnableHistory equal to true and specify what should handle the Navigate event. You can also specify if you want the HistoryState to be 'secure' by setting EnableSecurityHistoryState equal to true, but this is optional.

Your ScriptManager should now look like this:

<asp:ScriptManager runat="server" ID="sm1"
     EnableHistory="true" OnNavigate="sm1_Navigate"
     EnableSecureHistoryState="true" />

Step 2: Add an AsyncPostBackTrigger for the Navigate event of the ScriptManager

<asp:UpdatePanel ...>
    ...
    <Triggers>
         <asp:AsyncPostBackTrigger ControlID="uxChangeTime"
                     EventName="Click" />
         <asp:AsyncPostBackTrigger ControlID="sm1" EventName="Navigate" />
    </Triggers>
</asp:UpdatePanel>

Step 3: Modify the Click handler (or whatever event it is that would trigger a HistoryPoint to be recorded

What you are doing here is notifying the ScriptManager what information to store as a HistoryPoint by calling its AddHistoryPoint method. There are three possible overloads and we will look at the other two next blog, but for now we will use one of the simplest, a single key/value string pair to store the current DateTime with the key "myTime":

(c# code)
protected void uxChangeTime_Click(object sender, EventArgs e)
{
    string _currentDateTime = DateTime.Now.ToString("F");
    lblTime.Text = _currentDateTime;
    ScriptManager.GetCurrent(this).AddHistoryPoint("myTime", _currentDateTime);
}

(vb code)
Protected Sub uxChangeTime_Click(ByVal sender As Object, &_
  ByVal e As System.EventArgs) Handles uxChangeTime.Click
    Dim _currentDateTime As String = DateTime.Now.ToString("F")
    lblTime.Text = _currentDateTime
    ScriptManager.GetCurrent(Me).AddHistoryPoint("myTime", _currentDateTime)
End Sub

Step 4: handle the ScriptManager Navigate event

In this event we retrive the State property of the HistoryEventArgs and use that to set the page to be what we want it to be. In this very simple example we will use it to set the value of the label to be the DateTime that that particular page displayed:

(c# code)
protected void sm1_Navigate(object sender, HistoryEventArgs e)
{
    string _historyValue = e.State["myTime"];
    if (_historyValue != null)
    {
        lblTime.Text = _historyValue;
    }
}

(vb code)
Protected Sub sm1_Navigate(ByVal sender As Object, &_
  ByVal e As System.HistoryEventArgs) Handles sm1.Navigate
    Dim _historyValue As String = e.State["myTime"]
    if(_historyValue <> Nothing)
    {
       lblTime.Text = _historyValue
    }
End Sub

Voila! We now have a functional Ajax page with history. Try it!

What has happened is that we are using History Points. When we click the button it determines the current DateTime, displays it, and stores it as a history point. When we click the "Back" button it retrieves the previous history point (which was the current DateTime in string format) and displays that (see chart below).

Next blog: a look at more intensive use of History Points...
btw, for prep, take a looksee at my blog on the Memento pattern and Ajax history to understand my basic approach: http://www.myfriedmind.com/techBlog/2009/05/20/AjaxHistoryAndTheMementoPattern.aspx

Part 1 - Introduction
Part 2 - Basic Example
Part 3 - Complex Example
Part 4 - Final Notes
Bonus - Ajax History and the Memento Pattern
Extra Bonus - Issues with Opera

One of the most exciting prospects with .net 3.5 is the ability to handle Ajax History.

Ajax, for those of you who may be only vaguely familiar, is a way to do partial postbacks of web pages. This allows you to modify only a portion of the screen rather than updating the entire transaction. This increases the potential speed exponentially. One form are CallBacks, another used by the UpdatePanel is a full PostBack but only a redrawing of the appropriate sections of the page.

However, there are three main problems with Ajax when using controls like the UpdatePanel:

1. Hitting the “Back” button loads the page that was loaded BEFORE the ajax page
2. Refreshing the page has the effect of losing whatever Ajax calls have been made (ie the page itself is reloaded from the start).
3. There is no effective method to ‘link’ to the page resulting from ajax calls. All links lose any Ajax calls because the URL does not display the necessary information to recreate the page at the appropriate place.

All of these can be resolved (as we shall see) by using Ajax History.

This first blog entry will lay out the problems in greater detail and the general means by which Ajax History resolves them. Later entries will go more into detail on how to do Ajax History (yes, there is some additional work, but not very much).

Hitting the “Back” button loads the page that was loaded BEFORE the ajax page

The issue here is caused by two factors:

1. The "Back" button loads the last entry in url history
2. Ajax does not automatically change the url history

An example of what I am talking about can be seen in my (non-artistic) image below.

Hitting the "Back" button after doing regular Postbacks will take you to the most recent page of information. However, hitting the "Back" button after doing CallBacks takes you all the way back to the page that was loaded BEFORE you even got to the Ajax page.

The reason for this lies in the way that the href property of the Html Document Object Model is handled. By default whenever a full PostBack occurs or a modification to the hash in the URI (such as an internal link), the URI of the new entry is stored in the location history. This is handled by the browser behind the scenes and has been since the early days. However, since Ajax calls are not full PostBacks the browser mechanism does not, by default, record their entry.

To get around this, a rather ingenious method is used. Because modifications to the URI’s hash portion is included in the history but DOES NOT require full PostBack (think internal anchor links) .net 3.5 writes to the hash portion of the page to trigger the entry being recorded, by the browser, in the href history. Pretty slick, hunh?

For those of you unfamiliar with the hash concept of the URI, consider the following quick example:

<html>
<head></head>
<body>
<a name=’Up’></a>
<a href=’upsidedown.html#Down’>Go Down</a>
<p>&nbsp;</p>
<a name=’Down’></a>
<a href=’upsidedown.html#Up’>Go Up</a>
</body>
</html>

I have posted this basic page to my site. Note that there are anchor tags (<a…) that have names and others that have a hash sign (#) in them that refer to that name. These are commonly used to enable users to just to a particular portion of the page without having to scroll and are known as Internal Links (because they link to an internal portion of the page and not to an external page).

When the page first loads you can see that the URI is simply http://www.myfriedmind.com/updown.html. There is one link visible (the other would be visible if you scrolled but I shrunk the browser window to give an idea of what internal links are generally used for.

Once the link is clicked it moves the page down to where the “named” anchor is. In other words, clicking on the anchor tag that references #Down (<a href=’upsidedown.html#Down’>Go Down</a>) moves the page to the anchor that contains the name that matches the one after the hash sign – so you are moved WITHIN the page (to <a name=’Down’></a>). This is very important – note that the URI has changed, it is now showing the hash. Also critical to note is that THE PAGE DID NOT POSTBACK!

Clicking on the link that has the hash entry for Up (<a href=’upsidedown.html#Up’>Go Up</a>) results in moving to the anchor tag that has the name (Up) that matches what was after the hash mark. Again, the URI is updated to a new hash display and THE PAGE DID NOT POSTBACK!!!

It is critical that you understand that when this takes place the browser records the change in its href history. In other words, modifications to the hash are RECORDED in the browser’s href history. Thus hitting the “Back” button means that we move back to the previous entry, which is NOT http://www.myfriedmind.com/updown.html, but http://www.myfriedmind.com/updown.html#Down (see below)

Thus the elegant solution – to store Ajax postbacks, record the entries in the hash of the URI (like you are doing an internal link) and the updated URI will be recorded in the browser history for you. Any clicks on the “Back” button will load the previous entry. See the basic example below. Note that the change after CallBack to the URL (adding a hash entry).

I must note here that the adding to the hash is not automatic. You do need to do code but very, very little. Your code mostly deals with how to effectively package the info and unpackage when required. If you are curious take a looksee at my (fascinating) blog on how this is similar to the Memento pattern ->  http://www.myfriedmind.com/techBlog/2009/05/20/AjaxHistoryAndTheMementoPattern.aspx.

Once you grasp this concept – that the Ajax History is stored in the URI’s hash, the solutions to both of problems #2 and #3 (page refresh and linking) are resolved.

• Refreshing  the page refreshes the URI, INCLUDING the hash. Thus the page that gets returned is the page that has had the Ajax modifications done
• Sending a link to this page, INCLUDES the URI’s hash, and thus the page will be able to return the point in its Ajax modifications that a person wants

There are a number of very useful examples of how this is used today (Ajax History is not new with 3.5 but it DOES make it a whole lot simpler). The most commonly used are mapping websites. One can hunt around (using Ajax) until one gets to the exact display one desires and then save/send/whatever that display. Without the hash entry one would always end up at the very beginning and the desired display would be lost. I can use bing to zoom into the street view of Dunn Bros (the BEST coffee) by my old alma mater in Saint Paul and shoot that url to a friend.( shortened for display - http://www.bing.com/maps/#JnE9eX...zMTI1)

But this is not limited to mapping sites. Imagine that you have a Ajax based site that enables users to filter/sort/etc on a GridView display customer accounts. “Ah ha,” says the manager (they say things like that when no one is listening) “this is precisely the display I am looking for. I will just save it into my favorites. And I will also email it to the big boss.” Without the hash they would be exceedingly frustrated as would the big boss. With proper Ajax history coding the sun shines, the wind blows, and gas prices drop. Everyone is happy.

;)

Next blog: What exactly is involved in doing Ajax History, the concepts….

okay, I apologize. I promised to do this weeks ago and am only finally getting it up. Hopefully it will be worth the wait...

If you are planning on simply using a DDL (and not Cascading), look here -> http://www.myfriedmind.com/techBlog/2009/06/04/DropDownListGridViewAndDynamicallySelectingTheAppropriateListItemDuringEdit.aspx

Note that this example uses a remote webservice (rather than a PageMethod) for the CascadingDropDownList calls and I have not included them to simplify the amount of code on this page, but they are fairly straightforward -> http://www.asp.net/AJAX/AjaxControlToolkit/Samples/CascadingDropDown/CascadingDropDown.aspx

Sample DataObject (in c#)

class MyObject
{
   public int ObjId { get; set; }
   public string StateAbbreviation { get; set; }
   public string ZipCode { get; set; }
}

Sample DataObject (in vb.net)

Class MyObject
   Public ObjId As Integer
   Public StateAbbreviation As String
   Public ZipCode As String
End Class

Entry on SampleGridView.aspx page (as simple as you can get it)

<asp:GridView runat="server" ID="lstMyData" DataKeyNames="ObjId"
    AutoGenerateColumns="false" EnableViewState="true"
    AutoGenerateEditButton="true"
    OnRowDataBound="lstMyData_RowDataBound" >
    <Columns>
        <asp:TemplateField>
            <ItemTemplate>
                <asp:Label runat="server" ID="lblState"    
                    Text='<%# Eval("StateAbbreviation") %>' />
            </ItemTemplate>
            <EditItemTemplate>
                <asp:DropDownList runat="server" ID="uxState" />
                <aKit:CascadingDropDown ID="ajxState" runat="server"
                    TargetControlID="uxState" Category="State" 
                    ServiceMethod="GetStates" />
            </EditItemTemplate>
        </asp:TemplateField>
        <asp:TemplateField>
            <ItemTemplate>
                <asp:Label runat="server" ID="lblZipCode"  
                   Text='<%# Eval("ZipCode") %>' />
            </ItemTemplate>
            <EditItemTemplate>
                <asp:DropDownList runat="server" ID="uxZipCode" />
                <aKit:CascadingDropDown ID="ajxZipCode" runat="server"
                    TargetControlID="uxZipCode" Category="ZipCode"
                    LoadingText="[Loading Zipcode...]"
                    ServicePath="WebServiceToReturnData.asmx" 
                    ServiceMethod="GetZipCode"
                  ParentControlID="uxState" />
            </EditItemTemplate>
        </asp:TemplateField>
    </Columns>
</asp:GridView>

Codebehind (in c#) SampleGridView.apx.cs (note this does NOT include the code to return the values)

protected void lstMyData_RowDataBound(object sender,
        GridViewRowEventArgs e)
{
    // verify this is a DataRow, not a Header, Footer, etc...
    if (e.Row.RowType == DataControlRowType.DataRow)
    {
        // in case you want to do something else here....
       
        // see if this is the Row used for Editing
        if ((e.Row.RowState & DataControlRowState.Edit) != 0)
        {
            // get the DataItem that is bound
            // and cast it accordingly
            MyObject _myObject = (MyObject)e.Row.DataItem;

            // get the CascadingDropDowns
            CascadingDropDown _ajxState =
                (CascadingDropDown) e.Row.FindControl("ajxState");
            CascadingDropDown _ajxZipCode =
                (CascadingDropDown) e.Row.FindControl("ajxZipCode");

            // the data is automatically updated via the Ajax,
            // so we merely need to select the item

            _ajxState.SelectedValue = _myObject.StateAbbreviation
            // _ajxState.ContextKey = this can be set here if you are using it;

            _ajxZipCode.SelectedValue = myObject.ZipCode;
        }
    }
}

Codebehind (in vb.net) SampleGridView.apx.cs (note this does NOT include the code to return the values)

Protected Sub lstMyData_RowDataBound(ByVal sender As Object, _
    ByVal e As System.Web.UI.WebControls.GridViewRowEventArgs) _
    Handles lstMyData.RowDataBound
    If e.Row.RowType = DataControlRowType.DataRow Then

            ' in case you want to do something else here....

            ' see if this is the Row used for Editing
            If (e.Row.RowState And DataControlRowState.Edit) <> 0 Then

                ' get the DataItem that is bound
                ' and cast it accordingly
                Dim _myObject As MyObject = _
                    DirectCast(e.Row.DataItem, MyObject)

                ' get the CascadingDropDowns
                Dim _ajxState As CascadingDropDown = _
                    DirectCast(e.Row.FindControl("ajxState"), CascadingDropDown)
                Dim _ajxZipcode As CascadingDropDown = _
                    DirectCast(e.Row.FindControl("ajxZipCode"), CascadingDropDown)

                ' ddl population should be handled by the Ajax
                ' ServiceMethod of the CascadingDropDown

                ' select the appropriate item
                _ajxState.SelectedValue = _myObject.StateAbbreviation
                _ajxZipCode.SelectedValue = _myObject.ZipCode

            End If
     End If
End Sub

Note: special thanks to Thomas who catches my error in using QueryString vs url hash - I have made the appropriate changes in this entry...

Part 1 - Introduction
Part 2 - Basic Example
Part 3 - Complex Example
Part 4 - Final Notes
Bonus - Ajax History and the Memento Pattern
Extra Bonus - Issues with Opera

Recently while watching a geekspeak on Ajax history it struck me that it reminded me strongly of a Memento pattern. I mentioned this to Glen Gordon and he recommended I write a blog on it, so without further ado...

First off, a little background. Maintaining history has been one of the holy grails of Ajax since it began. It is a wonderful feeling to produce a zippy, intiutive site that has fantastic UI, but once someone hits the "back" button everything goes down the tube. The reason is simple, browsers were created in the time before, even before Javascript, much less XML. Back then the "back" button, or any sort of history action, brought you back not to your last action but to the last page that fully loaded.

To give a parallel, for anyone who has used the "undo" command in whatever program, what it does is "undo" the last action that you did. Imagine typing for hours in Word, clicking "undo", and having it wipe out EVERYTHING that you had just done, not just the last little action. No one would want that, but this is what the "back" key effectively did by default. Hence, the quest to maintain Ajax history. Wouldn't it be nice if the "back" key, or other "back" command acted as an "undo" vs a true "back to the previous page"?

In addition, what if after working on a page (say a maps page) that uses Ajax, you want to send someone the link. The option is to use a URL, but since Ajax by default modified the page but not the URL, all that work would be useless. You would think you were sending them a map to your cabin by the lake, they would simply get the default map of the world. Not good.

There have been ways to resolve this even before .net 3.5 came out. One merely has to look at some of the larger Ajax enabled sites (such as google maps) to see this, but this is such a constant and complex requirement in almost any Ajax development that it is only logical that someone develop a abstractive pattern to simplify and standardize it. The 3.5 framework does this, one of many reason it makes me squeal like schoolgirl. But what is especially fun to look at is how it does it, specifically what pattern was chosen. The pattern, which is extremely logical to choose, is akin to the Memento pattern.

I won't go into Design Patterns here. If you are not sure, follow this link, buy the book, get the poster. I want to focus on one pattern, the Memento pattern and how it relates to Ajax history in the hopes that it will illumine your coding.

The Memento pattern requires two players, commonly refered to as the Originator and the Caretaker. To clarify the interaction:

1. The Caretaker is going to change the Originator in some way but the Originator needs to be able to undo the change.
2. The Caretaker receives a small "memento" object and stores it (hence the Caretaker name).
3. The Caretaker then changes the Originator.

If the change needs to be undone:

1. The Caretaker returns the "memento" object to the Originator.
2. The Originator uses the "memento" object to undo the change.

But it is also critical to understand about the "memento".

• The "memento" is an opaque object, meaning the Caretaker can not change it
• The "memento" is small, it is not the entire Originator, merely the minimal information needed to rollback state
• The Originator is the one who packages and unpackages the "memento"
• The Originator is the one who rolls back state (ie, the Caretaker does not modify the Originator to roll it back)

So how does this apply to how .Net does Ajax history? In short, .Net uses the URL of the page as the "memento", the History as the Caretaker, with the code you write in the framework acting as the Originator.

1. The Ajax action is going to change the webpage someway.
2. The current hash is already stored
3. The Ajax action makes the change and alters the hash

If the change needs to be undone:

1. The hash (in the URL) that was from the previous page (the rollback state) is returned.
2. The code that YOU wrote rollsback the state.

In this case the memento has these characteristics

• The "memento" is a url which is unchanged by the Caretaker (browser)
• The "memento" is small (you should make sure of this)
• The framework writes the URL that you need and allows you to access it
• Your code is what rolls back state

So, what does this mean? Basically the key point is that you can apply the practices that you have in place for working with the Memento pattern to working with Ajax history. Chief among these is that the "memento" should be small! Do not try to squeeze too much into your URL. It is not pretty and there are limits! Instead pare down to the minimum of what you need to be able to restore state.

One major bonus is that this not merely allows rollback, but enables your users to use URLs to return an Ajax-enabled page on which certain steps have already been taken. This is AMAZING!!!!!!! And compared to how we used to have to do it, it is like a walk in the park!

Recently someone asked about using Ajax on Sharepoint. I should note that a number of resources are out there on this which I used, so - as brilliant as I am <g> - the credit for this has to go to those who have gone before...

Like a lot of people I have been working on both since their betas, so whether or not I should install Ajax on Sharepoint was a no-brainer. Unfortunately, when Sharepoint 2007 first came out it was the very end of 2006 and Ajax was not officially released until January 23, 2007. As a result, in order to utilize Ajax on Sharepoint (pre-SP1) you needed to jump through a whole host of hoops. This is not to say it could not be done, merely that it was a cumbersome and painful process.

Step 1: Install SP1 on Sharepoint

Luckily the folks on the Sharepoint team made that a priority, and even though we had to wait a bit for it, they did include 'Ajax support' in SP1. So the first step to using Ajax on Sharepoint 2007 is, quite simply, install Sharepoint 2007 SP1. You can do it without SP1, but really, why would you?

Note that simply installing SP1 does not automatically turn on Ajax (there are more steps) but it removes some of the bugs that popped up.

Step 2: (Recommended): Install Asp.Net framework 3.5 SP1

The next thing that I strongly suggest is that you upgrade to .Net 3.5 (sp1). Why? Simply because if you are going to be doing any Ajax you will want to.

• It includes it directly in the framework, no need to install it separately
• It has awesome debugging - you will still use Fiddler, but less often
• Intellisense
• Much, much easier means of creating a 'tracking history' of Ajax calls

If you decide to install .Net 3.5, note that you will not see a Web Service Extension for it in the IIS Manager. This is not a flaw, this is because 3.5 is an extension of 2.0. Let me state that again - if you install 3.5 you will actually use 2.0 as the .Net version.

Doing these two steps does not mean that Ajax is automatically up and running, just that the necessary dlls have been put into the GAC.

One final note - if you install 3.5 you will be using version 3.5.0.0 of System.Web.UI.* in a number of your web.config entries. If you are using an earlier version, make sure to check the GAC and find out what the specific version is. Most of the rest of the steps involve modifying your web.config, so make sure you know your System.Web.UI.Extensions version before you being

Step 2a: Make a back up of your web.config

We are all good techies here, right? Which means we are all paranoid, right? Never, ever modify your web.config unless you have a rollback copy at hand. Remember, paranoia is a job-requirement.

Step 3: Add the system.web.extensions sectionGroups to the configSections of your web.config

If you are not familiar with Sharepoint, this will be located in your c:\inetpub\wwwroot\VirtualDirectories\wss\{your site's port here}. So if you have your Sharepoint on port 8080 your web.config will be located at c:\inetpub\wwwroot\VirtualDirectories\wss\8080. Remember to make a copy of it like a good, paranoid nerd. Also, I tend to remark what I am adding and why to my web.config, but you don't have to.

Add this in the <configSections> portion, which should be at the top. You will already see other <sectionGroup... > entries there, just add this one at the end (above the </configSections> entry), wrapped for readability...

Step 4: Add System.Web.Extensions as a "SafeControl" to your web.config

SafeControls are those assemblies that should be considered "Safe" by Sharepoint. Do a quick find for <SafeControls> and you will see a whole lotta them. Simply add this line to the bottom, above the </SafeControls>.

NOTE!!! If you are using a different version than .net 3.5, make sure that you verify what version it is in the GAC. This needs to be specified in the "Version" section or Sharepoint will throw an error. Because I am using 3.5, my version is 3.5.0.0

Step 5: Add the needed "verbs" to your <httpHandlers>

Note that this is NOT the <httpModules> section. There should already be some entries there, so just stick this at the end, above the </httpHandlers> line....

Step 6: Add the <controls> reference to the <pages...> section of the web.config

This will enable your pages to recognize the controls that come with Ajax (such as the ScriptManager, etc). Locate the <pages ...> section and add this at the end above the </pages> entry. Again, keep an eye on the Version.

Step 7: Add this at the very end of your web.config, just above the </configuration> line

Of course you could stick it somewhere else, but let's be neat here... This is the section that first thing that you put into your web.config (the <sectionGroup...> referenced. There is documentation out there on sectionGroups, and they are very handy, if you get interested. I have left a lot of commented lines in there for if you need them. And, once more repeat after me, if you are not using 3.5, check the Version!

Step 8: Add a ScriptManager to your Master Page

You can always do it dynamically, and I always check in my code to see if it exists before whatever webpart I am writing loads, but it is much simpler just to add it on your Master Page. Just stick it below the <form id="Form1"... > entry :

<asp:ScriptManagerrunat="server"ID="ScriptManager1 />

Please note that there are a LOT of other goodies you can add to your ScriptManager, especially in .net 3.5, so feel free to expand it. Just make sure it is in there.

Step 9: Write Ajax pages (or webparts).

If you have followed these directions you should be ready to roll. I have not included how to add the AjaxControlToolkit, but if you are this far it is fairly a no-brainer. Add the .dll to the GAC; add the assembly reference to the web.config 'assemblies', add the namespace entry to the web.config 'controls' section and you are ready to rock! 

Final NOTE!!! UpdatePanels on Pre-SP1 ...

You may need to add the following code to get UpdatePanels to work properly, just put it in your Master Page