I was setting up a Man in the Middle webservice to intercept a message coming in so that I could do some processing of it on the side. Don't worry, it was our webservice. My process is fairly simple:

1. accept the submitted object
2. forward the object to the old web service
3. do what I wanted with the info

Step #2 appears fairly straightforward, and for the most part it is.

1. Create a (new) Web Service.
2. Expose the same public WebMethods.
3. Add a 'Web Reference' to the (old) Web Service
4. Create a new Web Service object of the old Web Service
5. Pass the received object onward

The problem that occurs is that because the (new) Web Service has to be all-inclusive it creates its own object type. While this is acceptable in .Net (since it goes by .net classnames) this gets all out of whack in the XML. This is because the XML uses a different namespace process - and since the (new) Web Service uses the same object as the (old) Web Service, albeit with a different .net namespace one of the things that it includes as an Attribute is the XML namespace. So

• The two classes have different .net namespaces
• The two classes have the exact same XML namespace

The compiler does not catch this because it is only looking at the .net namespace. So it will give you all sorts of helpful suggestions.

However....

There is a simpler way to do it. Basically, since you KNOW that the incoming and outgoing objects are the same, you are simply going to override the class that the Web Reference uses to tell it to use the original class.

If you initially open up the Web Reference to your (old) Web Service you are not going to see the file you need. You need to go up to the File Menu and select Project, Show All Files.

Now you will see the file that you want over in the Solution Exploerer -> Reference.cs.

Open that puppy up and make the necessary changes, just remember to wipe out the (new) objects that will be in there. All you want to leave are the methods, and those should now be passing the classes from the (old) Web Service.

Happy coding!

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

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!