P5 Technologies Blog

An ASP.NET Ajax UpdateProgress That Works

2007-06-26T15:08:00.001-07:00

The ASP.NET Ajax UpdateProgress works ok if you're using the UpdatePanel to pass Ajax calls to your back end page code. But it doesn't work if you're making webservice calls from within javascript on your page.

It's easy to add this functionality to your web application however. All you need to do is to add handlers on Sys.Net.WebRequestManager to handle the invokeRequest and completedRequest events, like so:


        
       Sys.Net.WebRequestManager.add_invokingRequest(onRequestInvoked);
       Sys.Net.WebRequestManager.add_completedRequest(onRequestCompleted);

Make sure you do this after the ScriptManager control is loaded, otherwise you'll get an exception that Sys.Net doesn't exist. From there, your code can be as simple or as complicated as you like. Mine generally looks something like:


        function onRequestInvoked() {
            var stat = $get("status");
            if (stat != null) stat.style.display = "block";
        }

        function onRequestCompleted() {
            var stat = $get("status");
            if (stat != null) stat.style.display = "none";
        }

That's all there is to it!

Calling ASP.NET WebServices using Plain Ol' Ajax

2007-05-17T20:58:00.000-07:00

I recently had a situation in which I needed to call an ASP.NET webservice from a straight HTML/javascript file. I could not use an ASPX file for this, and therefore could not use the ASP.NET Ajax ScriptManager. I had to use good ol' XMLHttpRequest.

Not a problem. Took a while to put the pieces together, but not a problem. There are some tricks to making it work.

First, you need the know the URL of your webservice. An ASP.NET webservice URL looks like this:

http://servername/WebService.asmx/MethodName

Note that it must look EXACTLY like this. If you include a trailing "/", you will get an error.

Next, you need to make sure that HttpPost and HttpGet are enabled for your services. By default, in ASP.NET 2.0, they are not. You can fix this by adding the following to the config file of your webservice:

    <system.web>
        <webservices>
            <protocols>
                <add name="HttpGet">
                <add name="HttpPost">
            </protocols>
        </webservices>
    </system.web>

Now comes the fun part. I tried for a while to figure out how to get JSON returned from the web service, and not get SOAP back. A lot of stuff on the web tells you that JSON is the default if you are using the web service as a script service. It's not.

In order to get JSON back, you MUST add the following header to your request, and you MUST do it after the call to open(). In the example, httpObj is an XMLHttpRequest object:

httpObj.open("POST", url, true);
httpObj.setRequestHeader("Content-Type", "application/json; charset=utf-8");

httpObj.send(parameters ? parameters : "");

Finally, in the example above, "parameters" is passed if it exists, otherwise an empty string is passed. If parameters exists, it must be in the form of a JSON string. So, for example, if the Web Service method is expecting a string called "s", your parameters would look like:

parameters = "{s: 'Hello World'}";

That's it! Happy coding!

ColdFusion WebServices for Ajax

2007-05-04T12:52:00.000-07:00

As a longtime .NET and Ajax developer, I was a little excited to be asked by a client to implement an Ajax-based website using ColdFusion. Good to get out of the house every now and then. In building this app, I learned a lot about how ColdFusion works, and how to best use it to write services that return data for my browser-side javascript (ajax) calls. I also discovered that, though there is a lot of information about how to write CF webservices for Ajax apps, it was fragmented, difficult to follow, and often wrong. Hence this blog.

If you're unfamiliar with an Ajax app, it's basically made up of two parts. A server component to supply data (or accept data), and a client component that comprises javascript running in a browser and making HTTP calls to the server component. There can be a lot more to it than that, but that captures the flavor of it.

Because the server component typically returns data to the javascript, some data format is required that the server can return and that the client can parse and use. In many Ajax apps, this is done using JSON, a "stringified" version of a javascript object. It can also be done using raw text, XML, or whatever, but JSON is often preferred because it is compact, rich enough for most uses, and extremely easy to parse on both the server and the client. In my app, I initially decided to use JSON.

In ColdFusion, the normal way to code a webservice is to write a CFC file with function definitions that are defined with remote access, and to return your data using <cfreturn>, like so:

<cffunction name="getFeatures" access="remote">
   <cfquery name="myQuery" datasource="MyDatasource">
       select * from MyTable
   </cfquery>

   <cfreturn #myQuery#>
</cffunction>

This will allow you to call the "getFeatures" function from your javascript code. The returned data can then ostensibly be parsed and used in the javascript on the client.

However.... when the <cfreturn> tag returns the data, it wraps it in bunch of webservice XML called WDDX (other technologies, like .NET, wrap the returned data in SOAP). This is problematic for the client, because it's non-trivial to parse the data out of the WDDX wrapper.

If you recall, I initially wanted to use JSON so that it was easy to use the returned data in my client. To convert to JSON, I use the CFJASON converter available at http://www.epiphantastic.com/cfjson/. Once the conversion is done, it is easy to return the JSON string, but there is a problem, because the JSON is returned to the client still wrapped in WDDX.

So, there are a couple ways around this. First, the way CF works, it turns out that it is the <cfreturn> call itself that wraps the return with WDDX. You can overcome this by outputting the data using <cfoutput> instead:

<cffunction name="getFeatures" access="remote">
   <cfquery name="myQuery" datasource="MyDatasource">
       select * from MyTable
   </cfquery>

   <cfinvoke component="cfcommon.json" method="encode" data="#myQuery#" returnvariable="jsonResult" />
   <cfoutput>#jsonResult#</cfoutput>
</cffunction>

As it so happens, this is a pretty good way to write a CF webservice that returns generic JSON and can be consumed by any javascript client.

There is an additional option, however, that will allow me to return the results using <cfreturn> and still consume the returned values within my javascript. Check out the JSMX Engine at http://www.lalabird.com/. This is a essentially a javascript component that will perform the HTTP call, but then parse the resulting returned data. If the returned data is raw JSON, it passes back a pre-created javascript object. If the returned data is WDDX, it also passes back a pre-created javascript object. Nice! It will additionally handle a couple of other formats, which makes it a nice tool to have in your utility belt.

Once I discovered the JSMX at component, I decided to code my webservices without using JSON. I now can just return the objects from my webservice and let the JSMX engine handle the parsing for me.

So to summarize, there are two good ways to code a CF webservice that returns data to your javascript clients. First, you can return a JSON string (or any other format, for that matter) using <cfoutput> to avoid wrapping the return values in WDDX. Otherwise, you can use <cfreturn> (and get the returned values wrapped in WDDX), and then use the JSMX engine to deal with the wrapper on the client side. I chose the latter approach because using the JSMX engine allows me to call both WDDX and JSON webservices without any change to my client code, and without having to modify the "standard" way of doing things on the server.