I just stumbled upon the problem of having to load multiple resources during page initialization. During the initial load I wanted a way to prevent any animations and other fancy stuff from happening but rather only create the page as soon as possible.

Since I couldn't find any way in jQuery (there are no combined callbacks) I decided to implement this using the deferred promise concept jQuery 1.5 introduced.

Deferred basically means "I represent a ajax call that has happened or is happening - ask me about it and I'll tell you when it's done or was done already". So implementing my little wait functions was rather trivial:

I used CoffeeScript for this, but the resulting JavaScript is also quite readable and you can use that too.

What this does is provide you with the awkwardly named function waitForAjaxRequestsToComplete that takes one callback parameter and an array of jQuery promises. Once all promises succeed or fail the callback will be called and the first parameter will contain information about failures.

Sample usage:

waitForAjaxRequestsToComplete(function (info) {
  console.log("requests failed " + info.failures)
  console.log("requests succeeded " + info.successes)
  console.log(info.failed) //contains all failed promises
}, [ $.ajax(...), $.ajax(...), $.ajax(...) ]);

I like generic, convention based approaches to infrastructure so in most of my projects you'll find something like this in the main javascript file:

$('form').validate();

So if you want to validate multiple forms you have to call each form individually through each

$('form').each(function () {
    $(this).validate();
});

I was banging my head against the wall for more than three hours, reading jQuery.validate's code, trying to figure out why my supplied errorPlacement or highlight callbacks where not called.

The code in question looked perfectly fine and came pretty much straight out of the docs:

$('form').validate({
    debug: true,
    errorPlacement: function () {
        console.log("errorPlacement", this, arguments);
    },
    highlight: function () {
        console.log("highlight", this, arguments);
    },
    success: function () {
        console.log("success", this, arguments);
    }
});

As you can see I was still stuck in the "let's see what we can do from these callbacks" phase of implementing my own automatic validation scheme for a project. Guess what the above did? Nothing! And I mean really nothing. The validation worked as expected with my validation classes, but none of my callbacks got ever called (meanwhile supplied arguments like messages etc worked like a charm).

After 3 hours I finally came onto something when I couldn't find the validation classnames that where put on my elements inside the jQuery.validation code I was looking at. Turns out: Microsoft's jquery.validation.unobtrusive.js cripples jQuery.validation so that most of it's configuration options simply don't work any more. Neither with the $.validate.setDefaults() nor with the $('#element').validate() methods.

Needless to say that I almost broke into tears when my stuff was working fine once I removed the unobtrusive script from the page.

I do like the unobtrusive stuff - it serves it's purpose inside the MS MVC niche. But in this case I was not using unobtrusive on that form at all! So I simply did not expect the library to mess with jQuery.validate in any way as there was no unobtrusive validation stuff going on.

I usually try to avoid using too many jQuery plugins, especially for rather simple stuff like this. But displaying a calendar is pretty tricky (believe me - I wrote one using GDI+) and Fullcalendar has saved me countless hours so far.

One issue that cropped up now is that we needed our Fullcalendar to be localized in German. As with most things I came across so far, Fullcalendar already supports it - but the documentation is a bit cryptic on the issue so here is my localized options hash:

var localOptions = {
	buttonText: {
		today: 'Heute',
		month: 'Monat',
		day: 'Tag',
		week: 'Woche'
	},
	monthNames: ['Jänner','Februar','März','April','Mai','Juni','Juli','August','September','Oktober','November','Dezember'],
	monthNamesShort: ['Jän','Feb','Mär','Apr','Mai','Jun','Jul','Aug','Sept','Okt','Nov','Dez'],
	dayNames: ['Sonntag','Montag','Dienstag','Mittwoch','Donnerstag','Freitag','Samstag'],
	dayNamesShort: ['So','Mo','Di','Mi','Do','Fr','Sa']
}

$('#calendar').fullCalendar($.extend({ ... your options ... }, localOptions));

Good JavaScript almost forces you into learning async programming and jQuery animations is no different. Everything in jQuery supports callbacks because the stuff you do is in most cases done on the background while your script continues to run.

But as with most stuff, there are many ways of going about this:

Completed Callbacks

    $('#item').fadeOut('slow', function () {
        console.log('animation finished');
    });

The problem with this approach is that it gets rather tedious to queue stuff together if you want to do say three things in order.

Let's say you want to a fadeOut animation then add a cssClass, start another animation and once that one is finished remove the cssClass again. Using callbacks this looks rather ugly:

    $('#item').fadeOut('slow', function () {
        var foo = $('#foo');
        foo.addClass('myclass');
        $('#item2').fadeIn('slow', function () {
          foo.removeClasS('myclass');
        }
    });

As you can see, two nested callbacks is really not that readable and almost confusing.. That's why there is a better way to do this:

The fx Queue

jQuery uses a queue for all it's animations. That's the magic behind this nice syntax:

    $('#item').fadeIn().fadeOut();

If you run this code it will first fade the item in and only once it's completely visible it will start the fadeOut animation.

Problem with this is that it looks nice in it's syntax, but can't be mixed with the regular jQuery methods. Something like

$('#item').fadeIn().removeClass('active').fadeOut();

In that case you can hook into the queue yourself by using the .queue() method:

    $('#item').fadeIn().queue(function (next) {
        $(this).removeClass('active');
        next(); //Important to continue running the queue
    }).fadeOut();

Hope this helps!

I just stumbled upon a little issue while using jQuery.Stepy wizard plugin: There are callbacks for navigating, but there is simply no callback that gets fired when the current step is actually displayed. As it happens there are a number of things you may want to do once a wizard  step is shown like start animations or maybe initialize something. (And next/back get fired before validation happens so they don't actually work in case validation fails)

Thank god JavaScript is almost by definition open-source so I fixed this with the following pull request.

The select callback works just like the back/next callbacks:

$('#wizard').stepy({
  select: function (index) {
     //your code goes here
     //index is 1 based - not zero based
  }
});

It's usually not considered polite to open new windows whenever somebody clicks one of your external links. Those back and forward buttons are there for a reason, so I strongly encourage people to avoid opening new windows.

But, we all know customers. They get this "but I want this" look the second they discover that users may leave their web site too early (can't say how much this attitude sucks..).

One popular way to do this is to use jQuery to open all external links on your page in a popup (making code that obviously violates the "don't open new windows" rule still validate).

$(document).ready(function() {
    $("a[rel='external']").click(function(event) {
        window.open($(this).attr("href"));
        event.preventDefault();
    });
});

Now all you have to do is, add a rel="external" attribute to all outgoing links, and this little jQuery function will take care of making them popup.

Still, this is bad. It contradicts the whole idea why they removed the target attribute in the first place, so consider this as a quick'n'dirty hack to satisfy stupid customers.