Tag Archives: JavaScript

jQuery Webinar

I’ll be doing a webinar for DevelopMentor tomorrow at 11 AM Pacific. The title is “Spice Up Your Web Applications with a Dash of jQuery!”.

I’ll be enhancing a simple MVC application so that it “feels” a bit slicker for your users. If you know JavaScript and jQuery, it’s basic stuff, but the goal is really to help those who aren’t as comfortable doing that to become confident enough to dive in and start learning.

I’ve been told that more people registered than we can actually have join. Sorry in advance if anybody can’t get in. You’ll be able to watch a recording of it afterwards here.

jQuery Deferreds

I’m absolutely loving the new Deferred objects in jQuery 1.5 and am using them heavily in a new project at work.

I just spent a bit of time trying to figure out why they weren’t working the way I was expecting them to, actually having to step into the jQuery code to realize my mistake.

The $.when method can take in one or more Deferred objects, but it can’t take them in as an array. Once I realized this, I immediately realized this could be solved with JavaScript’s apply function like this:

$.when.apply($, myDeferreds).done(function () {
    // All deferreds were resolved...

The first argument to apply is the object that gets to be “this” inside the when method. The second argument is the array containing the deferreds.

If myDeferreds contains three deferred objects, the above is the equivalent of this:

$.when(deferred1, deferred2, deferred3).done(function () {
    // All deferreds were resolved...

I thought that it would be neat if $.when would check to see if it was passed an array, but the jQuery team disagrees. Here’s hoping I won’t make this mistake again…

Verifying JavaScript with JSLint and Visual Studio

Douglas Crockford’s JavaScript: The Good Parts is a short, but informative read that all JavaScript developers should probably pick up. In it, he describes what parts of the JavaScript language we should be using (the good parts) and what parts we shouldn’t (the bad and the awful parts).

To help keep ourselves in check, he’s made his JSLint tool available years ago, but I always found myself too lazy to copy/paste my script into the tool to verify it. I finally decided to make this an almost instantaneous process.

The source code for JSLint is written in, what else, JavaScript. Since I do the majority of my work on Windows machines, I’m fortunate enough to have a built-in scripting engine that can run JavaScript without having to install any extra tools. And, no, I don’t mean my web browser—I mean cscript.exe.

Mr. Crockford does have a simple, cscript-compatible version of his script on his web site. It’s too simple, though. Most of the options it can check are disabled so aren’t checked and it stops after finding its first error.

For that reason, I’ve put together my own “host” for JSLint. It supports the enabling and disabling of all the options listed on the JSLint documentation page with command-line parameters and includes reasonable defaults so that you shouldn’t need to set or unset too many.

I’ve also added an option that adds the global variables defined in the Microsoft AJAX Library so that you don’t have to declare them in each of your scripts or on the command line. I’ve turned that option on by default, but it shouldn’t hurt you if you’re not using ASP.NET AJAX.

It also outputs any errors it finds in a format compatible with Visual Studio. If you set it up as an external tool, you can run it against your current file and hit F8 (the key bound to Edit.GoToNextLocation, by default) to jump to each line an error occurred on. This makes it trivially easy to detect and fix errors. No more excuses for using the bad parts of JavaScript!

To use it, all you have to do is download the latest version of fulljslint.js from the JSLint web site. Put it in some folder in your PATH. For example, I use a folder called C:\Tools to hold the various little tools I find myself needing frequently. Next, download jslint.wsf from this web site and put it in the same folder you put fulljslint.js in. Finally, download jslint.cmd and, once again, save it in the same folder as the other two files. You should now be able to issue a simple command like the following to verify any JavaScript file:

jslint script.js

Of course, to get the most out of using this, you’re going to want to set it up as an external tool in Visual Studio. Open up Visual Studio, go to Tools -> External Tools… and click Add. Enter “&JSLint” as the Title and “C:\Tools\jslint.cmd” (modified to use the folder you actually saved the files in, of course) as the Command. Enter “$(ItemPath)” as the Arguments. Check Use Output Window and click OK.

To test it out, open up any .js file and hit Alt+T and then J (or use the mouse). You should see your Output window appear with the results of the run. If there were any errors just hit F8 to cycle through them.

If you’re confused about why it’s saying such simple things like == and ++ are errors, read Douglas’ book or at least read the documentation for JSLint and the other essays on his web site.

A quick tip for ASP.NET AJAX users: If you register your own namespaces using Type.registerNamespace, you’ll get many errors telling you that your namespace is undefined. Put a comment like this at the top of your file and you’ll be good to go:

/*global YourNamespace*/

Feel free to contact me with any questions or issues you might have. I really want to see us all improve as JavaScript developers so the more people who are using tools like this, the better our code will be.