Introduction
This is a custom web control for implementing AJAX in a Web Form. Now this has been done a couple of times I realize but most of these implementations I think would be difficult to implement in the production code. I didn’t understand why, for example, the JavaScript files would be added to my web site at runtime. I also didn’t understand why I needed to add attributes to my server sided function I intended to call from the client. I looked at Atlas and while I’m sure it’s a great way to do AJAX, I didn’t like the fact that I had to learn a bunch of script syntax and that I had to add so many links to the JavaScript files. It seemed messy to me for some reason.
My solution
My goal was to create a control that I could drop on any form in multiple assemblies. I also wanted to minimize what developers had to know in order to use the control. The control should be able to call either a web service and/or a class in the Web Forms assembly and use the same function signature as the server sided function. The developer would set the Callback and WebServiceURL properties as follows:
Jax1.Callback = "MyJaxTest.WebForm1"
Jax1.WebServiceURL = "http://localhost/myJaxTest/Math.asmx"
My solution is to create the JavaScript functions to call both the web service and the public classes on the page the Jax control is added to.
Calling web services
Calling the web service is done by calling the WSDL of the web service. I then use XSL to transform the WSDL into something easier to use. From that I create the JavaScript to call each function of the web service. I end up making the function stubs for asynchronous calls but they are not supported in this version of the control. All that the developer needs to do is call the web service with the same function signature:
function cmdWSTest_onclick()
{
alert(Multiply(2,3));
}
Calling server classes
Calling classes in the Web Form assembly is a bit trickier. I use reflection to create the JavaScript stubs for the web page. This means I don’t have to apply attributes to the function signatures. If the method is public, a stub is created for it. The rest of the implementation is pretty standard for an AJAX tool. You create the HTTPHandler in your web.config so when your assembly sees something come in with a *.ashx on the end it will route it to the handler. (See this article) The biggest difference between this control and other implementations that I have seen is that because this is in a different DLL other than the web site the handler has to have a reference to the web site’s DLL. I include this in the assembly reference in the JavaScript stub so that in the post I can get the information to call the assembly. By the time this gets to the production code we will probably encrypt the assembly path. Again, the developer simply calls the function as if it were on the server.
About AJAX
On a note about AJAX, calling server sided code has a lot of promise. We did this years ago in ASP code. ASP.NET is so geared to doing things on the server that it sacrifices user experience for speed of development. The real challenge for AJAX application is not getting the information from the server as this control makes this pretty easy. The real issue is how you use it on the client. For example, you can bring back a bunch of XML from a DataSet but all the processing of that XML is done on the client. This is exactly what we did in ASP. I think this mitigates what ASP.NET brings to the table somewhat as we are moving forward by moving back. We will end up doing much more in JavaScript than we used to or than what I think ASP.NET thought we would.
