A few months back I was invited to talk about the “GeoWeb” at the Texas GIS Forum. Somehow I pulled a great slot – first presenter in the first session following the keynote by Dr. Bill Gail from the Virtual Earth group.  I chose to talk about “Usability in the GeoWeb” – you can download the presentation (as PDF) at SlideShare.net and view it below. The basic gist of the talk is that traditional Web Development groups are moving into our market space. In order to avoid having them “eat our lunch”, we need to adopt some of their techniques to make sure we build usable, high-performance applications. Check it out.

One big hurdle for developers moving to javascript is the lack of “compile time checking”. The only way to see if your code is syntactically correct is to load it into a browser and run it. But, sometimes small syntax errors can cause the javascript parser to fail, and the file will not load. This is a huge pain, and a great way to waste hours trying to find the smallest of syntax errors.

Enter Javascript Validation. There are some on-line tools for validating javascript, and Douglas Crockford’s JSLint is likely the most widely known. And while these tools can be handy, copy/pasting code into a text box, validating it, making changes, re-validating etc etc is tiresome.

Luckily for all of us Predrag Tomasevic created a Visual Studio add-in that uses JSLint to validate javascript from within Visual Studio 2005/2008. It’s called JSLint.VS, and the code is over at CodeProject. Get it.

The simplest way to use it is to run JSLint on a file from the context menu…

But, if you look at the options (Tools –> JSLint.VS options) you can integrate this with your build.

You can see the options that I have checked – running with minimal items checked tones things down to just checking for syntax – which end up being the most irritating bugs to catch. For example here is some code that’s catching an event, and then propagating that to another method along with some customized event arguments.

onClick: function(evt){
    // stub for event propagation
    console.log("DashboardMenu::onCommandItemClick");
    this.onCommandItemClick({
        action: this._menuConfig.action,
        type: this._menuConfig.type
    });
},

The customized arguments being passed over to onCommandItemClick are created via object notation – JSON if you will. Since I’m refactoring the code quite frequently, small little things can become problems. For example, I decided I did not need to pass “type” along anymore. Ok, I just went in an deleted that line resulting in this code…

onClick: function(evt){
    // stub for event propagation
    console.log("DashboardMenu::onCommandItemClick");
    this.onCommandItemClick({
        action: this._menuConfig.action,
    });
},

And as usual I refreshed FireFox, and followed along in FireBug and all was well and good. An hour or so (and a dozen or more changes) later I tried the page in IE…

Oh sweet. Without getting into dojo.require etc etc, this message is basically saying that IE could not load the class “dts.DashboardController” from the file because of some javascript syntax error. What’s not really clear is that the error could exist in that file, or any other class that’s dojo.require’d by the specified class. In my case, the code shown above is in dts.DashboardMenu, which is required in dts.DashboardController as shown below…

dojo.provide("dts.DashboardController");

dojo.require("dijit._Widget");
dojo.require("dijit._Templated");
dojo.require("dts.DashboardMenu"); //<-- DashboardMenu is pulled in here

dojo.declare("dts.DashboardController",
    [dijit._Widget, dijit._Templated, dijit._Container],
    {
        //class definition here...
    }
);

So – back to the problem – those who work with javascript and JSON every day ,and have sharp eyes might have noticed the error in the second code block – there is an extra comma in the JSON. Firefox accepts this, and works just fine. However, in IE the file fails to parse and we get that error dialog.

Turning on JSLint.VS, I get a notice about the missing comma as soon as I build… with the line number… how easy is that!

This will clearly save me a LOT of time over the long-haul – if you are using Visual Studio for your javascript development, this should be a “must-have” addin.

With the recent announcement that jQuery will ship with ASP.NET MVC and Visual Studio, the question of what javascript framework to use just got more complex.

Here’s my situation:

1) I need to work with the ESRI Javascript API for the maps in my apps, and this is based on the dojo toolkit

2) I want to work with ASP.NET MVC because it’s actually a sane way to built RESTful web apps on the Microsoft platform.

3) I need to send complex data between client and server as json

4) I work in an agile manner, so I need an environment that’s flexible – hand coding of client-side “data classes” is a waste of time if they can be generated.

So – what to do?

jQuery is awesome, but if I already have dojo loaded into the browser for the map controls, it does not add much to the mix (besides more bytes to download!)

MSAjax and ASP.NET JSON Web Services make sending complex data across the wire super simple, but should I drag along this library just to save some effort here and there? Sending complex data is possible with dojo, but it requires coding the Json deserialization on the server, which is tedious but not that difficult.

So – what to do?  My initial thinking goes like this – for apps that use Google Maps or Virtual Earth, I’m inclined to use just jQuery. If I need to send complex data across the wire, then adding MSAjax into the mix is likely worth it. For sites using the ESRI Javascript API, I’m torn. Dojo has to be loaded, so I don’t see good reason to load up jQuery as well. Again the call on MSAjax will be based on the complexity of the data services.

If you are working with this stack, I’d love to hear your thoughts on this…

Next up in my series of posts on using dojo to communicate with a Controller class is POSTing data. In this example, I used dojo.xhrPost to send Json as a form and have the MVC framework parse it into the Create(string name, string age) method on the Services controller. In this case, the data being sent back and forth is simple – a Name and Age from two text boxes.

Dojo Code

function CreateEmployeeMVCPost(){
    var responseNode = dojo.byId("responseMVCPost");
    var request = {"name":dojo.byId("username").value , "age":parseInt(dojo.byId("age").value)};

    dojo.xhrPost({
        url: '<%= Page.ResolveClientUrl("~/Service/Create") %>',
        handleAs: 'json',
        timeout:3000,
        content: request,
        //Don't set content type to Json
        contentType: "application/x-www-form-urlencoded",
        load: function(person,args){
            responseNode.innerHTML = "Response: " + person.Name + " " + person.Age;
        },
        error: function(error,args){
            alert(error);
            responseNode.innerHtml("Error!",error);
        }
    });
}

Controller Code

ASP.NET MVC looks at the form data and matches up form elements which have the same name as the parameters of the method. So – the in-bound json {”name”:”steve”, “age”:34} is parsed into form elements called “name” and “age”, which line up with the parameters of the method (shown below). The controller just uses the inputs to create a new instance of an Employee object, which is then Json serialized and returned to the client.

This is pretty smooth and works very well for simple data. Next time I’ll look at trying to POST complex objects.