kurtiss.org

I don’t usually write technical articles in this blog, but I thought I’d give you a taste of the kind of articles I write on my work blog, just for kicks… (and in case you forgot I was a geek). I’ve left a few company sensitive lines out…

Readers will know that I fancy words, in particular words that can be used to describe technologies. One hot buzzword for web programmers at the moment is AJAX (Asynchronous Javascript And XML). The term is used to categorize a munging of technologies, centering around Microsoft’s XmlHttpRequest ActiveX object. This object allows the implementor to make requests to a server inline with the execution of a page. It then hangs around until the server sends back a response (asynchronous) and provides that response to the user in the form of an XML DOM object (the XML part).

My first observation is that XML can be overkill. There are certain things that XML is very good at, including manipulating the structure of already structured data, and formatting data such that it is easily readable by unknown readers. It’s power comes from the fact that it is a shared language, and it can be used as a “universal tongue,” for interoperation of technologies and machines across the world. However, the need for communication between a client that I write and a server that I write can be in any sort of language I like—it doesn’t need to interoperate or be interpreted by anyone but me—and serves more as a means of transportation. Therefore, I should take as many shortcuts as I can, while still ensuring a translatable message on both ends.

My second observation is that Javascript already provides a completely adequate means of object serialization/deserialization: the object literal. Here are a couple examples of javascript literal objects:

    var strLiteral = "\"Literal String\"";
    var strString = eval(strLiteral); // strString contains: "Literal String"
    strLiteral = "1";
    var nNumber = eval(strLiteral); // nNumber contains: 1
    strLiteral = "new Object({ 'key' : 'value' })";
    var oAssocArray = eval(strLiteral); // oAssocArray contains: {"key" : "value"}
    strLiteral = "new Array([1,2,3])";
    var oArray = eval(strLiteral); // oArray contains: [1,2,3]

This is a pretty powerful serialization/deserialization mechanism built right into javascript, which is perfectly capable of transporting the kind of data I would want to send from a server to a client.

Adding a request handler on the server end, and a proxy (of sorts) on the client end, makes this process even simpler. Currently, the following will allow me to transport data asynchronously, and inline within the execution of a client page:

  *Server (Code-Behind):*

     [ClientSideMethod]
     public string GetArticleName(string articleID)
     {
       return String.Format("\"{0}\"", GetArticleName(documentID));
     }

   *Client (Javascript):*

     var oProxy = new ProviderProxy("<%= Request.Url %>");
     function getDocumentName(nDocumentID)
     {
       oProxy.call("GetArticleName", [nDocumentID], endGetArticleName);
     }

     function endGetArticleName(strArticleName)
     {
       alert(strArticleName);
     }

The ProviderProxy object serves to encapsulate all the necessary XmlHttpRequest calls, and the server side handler, ensures that methods being called have been decorated with the ClientSideMethod attribute. In the above example, when the client fires an event that calls getArticleName(), a request is sent to the server, and the client goes back to normal operation, until a response for that request is received. When the response is received, the callback method, “endGetArticleName” is called with the first parameter being the deserialized result of the server side operation. The client then alerts the user of the document’s name.

The currently coded mechanisms are basically the bare minimum that I need to get the job done. Of course if I were to code this on my own time, I would make sure that the server handler could easily translate between IDictionary → Javascript Associative Arrays, IEnumerables → Arrays, Strings → Strings, Ints, Doubles, Etc → Numbers. I would also allow the Client Side methods to have strongly typed parameters (instead of all strings). I might also think about changing the interface to the proxy, such that instantiating the ProviderProxy object makes a standard request to the server, which returns interface information for the current provider. Client Side code for this kind of interaction would look much nicer :)

Server Side:

     [ClientSideMethod]
     public Hashtable GetArticleNames(ArrayList ids)
     {
       Hashtable IdNameMap = new Hashtable();
       foreach (int ID in ids)
       {
         IdNameMap.Add(ID, GetArticleByID(ID).Name);
       }
       return IdNameMap;
     }

Client Side:

     var oProxy = new ProviderProxy("<%= Request.Url %>");
     oProxy.onEndGetArticleNames = function(oArticleNames)
     {
       for (var nId in oArticleNames)
       {
         alert("Article #" + nId + ": " + oArticleNames[nId]);
       }
     }
     oProxy.beginGetArticleNames([101,102,103]);

     //var oArticleNames = oProxy.getArticleNames([101,102,103]) would be a blocking call to the server.

Therefore, my new acronym AJAL (pronounced Agile, like the long sought after development practive), stands for Asynchronous Javascript And Literals. There you have it, an acronymous web architecture (blah!) that doesn’t really do anything new, but makes the old stuff easier. Making the hard (read time consuming) stuff easier is almost a sure fire way to allow the developer to focus on a better interface.