JSLint.VS2010: Automatic JavaScript Static Analysis

May 24, 2011 5 Comments

Recently, I was working on a project that used some asynchronous JSON-to-HTML databiding. Testers sent a bug that the site was working in Chrome, Firefox, Safari and IE9 but nothing was happening in IE8. The IE8 javascript debugger didn’t report any errors, it just didn’t do anything.

This sort of thing is no fun to debug and I spent an increasingly desperate evening staring at code that couldn’t possibly be wrong  failing to see the problem. Eventually, in desperation, I pasted the code into Douglas Crockford’s jslint and it quickly pointed out a stray comma which made all the difference.

I later discovered that there is a jslint extension available for Visual Studio 2010.

jslint-options

The really cool thing about the JSLint Visual Studio extension is that it reports its warnings and errors into the Visual Studio Error List window where they work just like other code errors. Even better, it has the option to cancel the build on error. That means if jslint finds an error, the project build dies. In my world, this is fantastic. It means I don’t even try to test something if jslint finds something wrong with it. I consider this to be a huge productivity win.skip-on-build

The following JSLint global options were key for me to use jslint as a build-time checker:

  • Output: Errors – causes Visual Studio to interpret JSLint output as errors
  • Run JSLint on build: true – causes JSLint to test all .JS files during build
  • Cancel build on error true– causes JSLint errors to cancel the build, just like C# compiler errors
  • Assume a browser: true
  • Predefined Vars: jQuery, $
  • Strict whitespace: false
  • Maximum line length: 999
    One issue with cancelling the build on error is that jslint is pedantic and some of its warnings are not strictly errors which means that standard libraries like jquery aren’t going to pass jslint. Fortunately, you can exclude individual .js files from build-time testing by right-clicking on the files you want to exclude in the Solution Explorer window. (Note that jslint doesn’t plug its menus into the Solution Navigator window from the “Productivity Power Tools” extension. You have to use the Solution Explorer.)
    Happy linting.
Advertisement

Filed under Uncategorized Tagged with , , ,

Submitting an MVC Ajax.BeginForm Using JavaScript and jQuery

April 5, 2011 8 Comments

The Ajax.BeginForm() helper method in ASP.Net MVC generates a bit of inline JavaScript attached to the onsubmit event of the form. When the form is submitted in the usual manner with a submit button the request is sent using XMLHttpRequest and the result is returned into the <DIV /> of your choice. However, if you want try to submit the form using JavaScript things are less tidy.

For my example, imagine a user account management tool that displays a grid of accounts and has a number batch of operations that you can perform against the grid data in an Ajax-y manner.account-mgmt

The idea here is that you could, for example, check a number of accounts and then click disable and those accounts would be disabled. The result of your operation gets written into a notification <DIV />.

Here’s the naïve implementation for submitting an MVC Ajax form.

jQuery().ready(function () {
	//other stuff including jqGrid initialization here...

	//'grid' is the id of the jqGrid table element
	//'disableKeys' is the id of the Ajax form we are submitting.
	$('form#disableAccounts').find('a.submit-link').click(function () {
	    //work to set the state of the form before sending it to the server here...
	    $('form#disableAccounts').submit();
	});
)};

Unfortunately, this doesn’t do at all what we want. What you end up with is the text that was intended for the notification <DIV /> replacing the entire window contents. In other words, a classic POST. But wait, there’s more.

debug-double-post

What actually happens is that the request is submitted twice! The first version is Ajax and the second is classic POST, interrupting the Ajax response.

The First Solution

My initial approach to solving this double-submit problem hinged on leveraging the fact that Ajax.BeginForm() generates a <FORM /> tag with some JavaScript attached to the onsubmit event to handle the Ajax behavior. Why not just trigger the onsubmit event directly?

jQuery().ready(function () {
	//other stuff including jqGrid initialization here...

	//'grid' is the id of the jqGrid table element
	//'disableKeys' is the id of the Ajax form we are submitting.
	$('form#disableAccounts').find('a.submit-link').click(function () {
	    //work to set the state of the form before sending it to the server here...
	    $('form#disableAccounts').trigger('onsubmit');
	});
)};

This works great except in Safari where nothing happens at all.

The Final Solution

I tried a number of different techniques to suppress the default form POST behavior. The one that worked in IE, Firefox, Chrome and Safari is to attach a new event handler to the submit event that always returns false.

jQuery().ready(function () {
	//other stuff including jqGrid initialization here...

	//prevent the form from submitting in a non-Ajax manner for all browsers
	$('form#disableAccounts').submit(function (event) { eval($(this).attr("submit")); return false; });

	//'grid' is the id of the jqGrid table element
	//'disableKeys' is the id of the Ajax form we are submitting.
	$('form#disableAccounts').find('a.submit-link').click(function () {
	    //work to set the state of the form before sending it to the server here...
	    $('form#disableAccounts').submit();
	});
)};

This works to suppress the second standard POST and allow the ASP.Net Ajax behavior to complete as expected.

Filed under Uncategorized Tagged with , , ,

%d bloggers like this: