With several people working on the same page while we were recreating some JS functionality from scratch I’ve noticed one of my buttons suddenly stopped working. Scratched my head a bit, and for a minute thought that maybe it’s not having a “return false;” in my jQuery live() event handler.

Turned out though that it was actually one of the other developers actually putting a “return false;” in their event handler that just happened to target the same element…

Ideally we needed to propagate the event through a variable number of events but prevent the default behaviour of a link kicking in. preventDefault() to the rescue!

$('#tag').live('click', function(event){
    (...)
    event.preventDefault();
});

Now, before blindly applying this piece of code I’d encourage everyone to first read up on why “return false;” is evil.

And for a quick reference here’s a table featured on a related StackOverflow question:

When you attach an event to an element in jQuery within the event handler function the this keyword always refers to the element that triggered the event.

$('a').bind('click', function() {
    alert(this);
});

Here this will be the a element that triggered the event. For the majority of the time this behaviour is absolutely ideal. However, if you’re using object oriented javascript and are trying to handle an event using a method of one of your classes, the chances are you’d want this to refer to the instance of your class instead of the DOM element.

var Klass = function() {
    this.message = 'hello';
};
Klass.prototype.handleClick = function(e) {
    alert(this.message);
};
var obj = new Klass();

$('a').bind('click', obj.handleClick);

The above fails because when Klass.prototype.handleClick is triggered from the click event this still refers to the a element that was clicked on. Hence this.message is undefined.

To solve this problem I made a small jQuery plugin called hitch that allows you to control the object scope. The above example would be rewritten as

var Klass = function() {
    this.message = 'hello';
};
Klass.prototype.handleClick = function(e) {
    alert(this.message);
};
var obj = new Klass();

$('a').hitch('click', obj.handleClick, obj);

If the handleClick method needs to access the DOM element that triggered the event, that can still be accessed through e.target. If the object scope argument is omitted then hitch should work in the same way as the standard bind method.

The plugin itself is just a few lines

(function($) {
    $.fn.hitch = function(ev, fn, scope) {
        return this.bind(ev, function() {
            return fn.apply(scope || this, Array.prototype.slice.call(arguments));
        });
    };
})(jQuery);

I believe similar functionality is scheduled to be included in an upcoming jQuery release, but for the time being I’m finding this plugin to be exceptionally useful.

Minimal is a very good word to describe jTree, which most of the time is good, however sometimes you might just want a little bit more. One of the biggest issues for me was lack of clickable links inside the LIs. Fortunately after some tweaking I came up with a hacky but working solution:

if ($("#jTreeHelper").is(":not(:animated)") && e.button !=2) {
 	//	Allow for clickable links
	if(new String(e.target).match(/(f|ht)tp(s{0,1}):///ig)){
 		return false;
	}
	$("body").css("cursor","move");

Just add the highlighted lines in the jquery.jtree.js file. Basically it just checks if the target of the click is a link and if it is it ignores the dragging.