function onMousedown(e) {
  initDrag(e);
}
function initDrag(e) {
  document.onmousemove = onMousemove;
}
function onMousemove(e) {
  element.style.top = e.pageY +'px';
  element.style.left = e.pageX +'px';
}

But I would suggest that the code to reposition the element should be moved away from the event listener. Not just moving that code into it’s own function, and let the event listener call that function (even though that’s a good thought). Instead, let’s create a queue:

function onMousedown(e) {
  initDrag(e);
}
function initDrag(e) {
  document.onmousemove = onMousemove;
}
var new_positions = [];
function onMousemove(e) {
  new_positions.push({top: e.pageY, left: e.pageX});
}

And then code to process the queue:

var paint_interval = setInterval(
  function() {
    if(new_positions.length) {
      var pos = new_positions.shift();
      element.style.top = pos.top +'px';
      element.style.left = pos.left +'px';
    }
  },
  50
);

So what’s the use of this? Doesn’t it just add unnecessary complexity? In this very simple example it sure does, but there’s still a beauty in it since we are separating concerns. On one side, there’s code that listens to what the user wants to happen, and adds that to the queue. On the other side, there’s code that decides whether to actually listen to what the user wants to do, or to deny it, and the two sides doesn’t need to know about the other.
You could add logic in the queue processing function (the function in the interval) that checks if the queue is too large, and then ignore the first 10 queue items and move directly to number 11, which would save the browser having to paint those 10 steps and move directly to number 11.
Another reason could be that you only want to allow the element to move X number of pixels per run, regardless of how fast the user drags, and then eventually catch up with the mouse position. Or if you have a lot of stuff going on, and you don’t care if the dragging is smooth, you can change the interval to run 5 times per second, instead of 20.

This is essentially the Command Pattern, except that a Command is executable in itself, and my queue items are just data holders, and it’s up to the queue processor to make sense of that data. The Command pattern is more general, as any command can be added to the queue/stack, and thesehere queues are more specialized, since all queue items are of the same type.

So the point is to separate logic, and decouple different parts of your application to make them more isolated. The queue processing doesn’t care where a queue item comes from, it’s only concern is to process the queue. That enables you to add queue items from other parts of the application as well, and the code that listens to mousemove events doesn’t need to be touched.
That enables you to let your application grow and meet new requirements without making a mess of the code with lots if nested if statements, since you have separated logic. If nothing else, you can impress other people by telling them about your fancy queue processing architecture. It probably won’t impress beautiful women at your local bar though.

So let’s say you have code like this:

var User = Class.extend({
  _friends: [],
  _name: '',
  init: function(name) {
    this._name = name;
  },
  name: function() {
    return this._name;
  },
  addFriend: function(friend) {
    this._friends.push(friend);
  },
  greetFriends: function() {
    alert('Hi '+ this._friends.join(', ') +'!');
  }
});

var fred = new User('Fred');
var mike = new User('Mike');
var jennifer = new User('Jennifer');
var sara = new User('Sara');

fred.addFriend(jennifer.name());
fred.addFriend(sara.name());

mike.greetFriends();

You would expect that Mike who nobody seems to like would just alert “Hi !”, but he alerts Freds friends as well. And that’s because objects in Javascript (arrays are objects as well) are passed by reference. So all of Freds friends also become Mikes friends, since they share the same friend array.

So to get away from this, the trick is to declare your properties in the constructor, like this:

var User = Class.extend({
  _friends: [],
  _name: '',
  init: function(name) {
    this._name = name;
    this._friends = [];
  },
  name: function() {
    return this._name;
  },
  addFriend: function(friend) {
    this._friends.push(friend);
  },
  greetFriends: function() {
    alert('Hi '+ this._friends.join(', ') +'!');
  }
});

Since the constructor (init) is called every time a new user object is created, the friends array is set for only that instance. But sometimes you might forget to reset the variable in the constructor, so I usually do this:

var User = Class.extend({
  _friends: false,
  _name: '',
  init: function(name) {
    this._name = name;
    this._friends = [];
  },
  name: function() {
    return this._name;
  },
  addFriend: function(friend) {
    this._friends.push(friend);
  },
  greetFriends: function() {
    alert('Hi '+ this._friends.join(', ') +'!');
  }
});

Just to make sure that there’s no risk of a shared array. You might even skip the declaration at the top, but I’m used to looking there for property declarations, so I set them at the top.

I’m sure that you already thought about this by know, but this feature in Javascript makes it possible to have “static” properties that are shared between all instances of the same class. I would advise you to use such a strategy sparsely though, as it’s not very obvious that it’s a shared variable. But the good thing about it is that this Javascript version of static properties doesn’t suffer the same problems that statics do in Java/PHP, since the static can be turned into a local just by resetting it in the constructor, without it affecting other objects. Something like:

var User = Class.extend({
  _friends: [],
  _name: '',
  init: function(name, share_friends) {
    this._name = name;
    if(!share_friends) {
      this._friends = [];
    }
  },
  name: function() {
    return this._name;
  },
  addFriend: function(friend) {
    this._friends.push(friend);
  },
  greetFriends: function() {
    alert('Hi '+ this._friends.join(', ') +'!');
  }
});

var fred = new User('Fred', true);
var mike = new User('Mike', false);
var jennifer = new User('Jennifer', true);
var sara = new User('Sara', true);

fred.addFriend(jennifer.name());
fred.addFriend(sara.name());
mike.addFriend(fred.name());

mike.greetFriends();
sara.greetFriends();

This code now tells us that Mike only has Fred as a friend, whereas Sara shares friends with Fred, and has both herself and Jennifer as her friends.

Happy coding!

You can see it here (it’s a work in progress, please be gentle).

After quite a lot of tweaking, bug fixing and making sure it works in popular browsers, I’ve now released version 1.0.0. If you find any bugs, or have any features you’d want for it, please don’t hesitate to send a comment here.

Happy coding!

It basically takes the best of an input field, and a select box/list, and mixes it together. It takes a real select list and transforms it to an input field with options, and mimics most (if not even more) of the features of a real select box. Since it’s a real select list from the start, it degrades nicely for those without Javascript.

You can find the code and an example here:
http://coffeescripter.com/code/editable-select/

In some languages, a closure may occur when a function is defined within another function, and the inner function refers to local variables of the outer function. At runtime, when the outer function executes, a closure is formed, consisting of the inner function’s code and references to any variables of the outer function required by the closure; such variables are called the upvalues of the closure.

That can be a bit of a dry explaination, so here’s an example.

function testClosure() {
  var foo = 'bar';
  return function() {
    alert(foo);
  }
}
var callback = testClosure();
callback();

This code will alert “bar”, even though there’s no “foo” variable in the anonymous function that testClosure returns. This is because the anonymous function we have created has access to its parent scope (that is, a closure has been created when the testClosure function executes). So when we alert the foo variable, Javascript will check for a variable called foo in the current function scope, and it won’t find it. Then it goes up to the parent scope, the scope of testClosure. It finds a variable called foo there, so that’s the variable that will be used. And you’ve probably seen this, perhaps without realizing that it’s a closure. Here’s some more explainatory code:

function testClosure() {
  var foo = 'bar';
  return function() {
    var foo = 'baz';
    alert(foo);
  }
  alert(foo);
}
var callback = testClosure();
callback();

Instead of just alerting “bar”, this will alert “baz” as well as “bar”, since there’s a variable “foo” in the inner function, and the testClosure also alerts the foo variable. So here’s a gotcha for you:

function initEvents() {
  for(var i = 1; i <= 5; i++) {
    var element = document.getElementById('element'+ i);
    element.onclick = function() {
      alert(i);
    }
  }
}

One might hope that this code will result in alerting “3″ when you click on the element with the id “element3″, but it doesn’t. It alerts “6″ for all elements. And that’s because the value i is set to 6 in the last cycle of the loop. So by the time the element is clicked, the variable i will have the value of 6. The further prove the point, look at this code.

function initEvents() {
  for(var i = 1; i <= 5; i++) {
    var element = document.getElementById('element'+ i);
    element.onclick = function() {
      alert(i);
    }
  }
  i = 'foo';
}

Now all element clicks will alert “foo”. So how would we solve this, because we need the current value of i in the click event. There are of course more than one way to solve this, but in the context of closures, this is how we can solve it.

function initEvents() {
  for(var i = 1; i <= 5; i++) {
    bindEvent(i);
  }
}
function bindEvent(i) {
  var element = document.getElementById('element'+ i);
  element.onclick = function() {
    alert(i);
  }
}

Now that we’ve moved the event binding code to another function, we’re no longer bound by the latest value of i in initEvents. The value of i is passed to the bindEvent function. We’re still creating closures though. Everytime bindEvent is called, a closure is created between bindEvent and the onclick handler function. But since bindEvent is called five times, five closures are created, and every closure has a different value for i. This was not the case in the first example, because there was only one function call, thus only one closure was created, and there was only one value for i.

Now, closures aren’t just between a function and it’s direct parent scope only. The closure recurses up the tree, like in this code.

function topLevel() {
  var root = 'root';
  function level1() {
    function level2() {
      function level3() {
        alert(root);
      }
      level3();
    }
    level2();
  }
  level1();
}
topLevel();

When the level3 function tries to access the foo variable, Javascript looks for it in level2’s scope, then in level1, and then it finally finds it in topLevel.

A word of caution though. Since closures lets different functions share variables, you can accidentally override a variable in a function, and that will affect other functions that also has a reference to that variable. Something like:

window.onload = function() {
  var foo = 'bar';
  for(var i = 1; i <= 5; i++) {
    var element = document.getElementById('element'+ i);
    element.onclick = function() {
      foo += ' clicked! ';
      alert(foo);
    }
  }
}

For everytime you click one of those elements, the foo variable is changed, even if you click on different elements.

Using closures in OO Javascript

When you’re writing OO in Javascript, you really, really need closures. For these examples, I’m using John Resigs
Simple Javascript Inheritance.

So you have a User class, perhaps, like this.

var User = Class.extend({
  name: 'Andy',
  init: function() {
    var context = this;
    document.getElementById('show_name').onclick = function() {
      alert(context.getName());
    }
  },
  getName: function() {
    return this.name;
  }
});

Since “this” will have special meaning inside the onclick handler function, we define a “context” variable that holds the reference to the User object, and that will be available in the onclick handler thanks to the closure that is created. Some prefer to name that variable “self”, but I prefer “context”, since that’s really what it is, the handlers context.

So this enables you to access the User object inside the handler function without having to set the User object as a property on the DOM element, like this.

var User = Class.extend({
  name: 'Andy',
  init: function() {
    var element = document.getElementById('show_name');
    element.User = this;
    element.onclick = function() {
      alert(this.User.getName());
    }
  },
  getName: function() {
    return this.name;
  }
});

function thisTest() {
  alert(this);
}
thisTest();

This will alert “[object Window]“. That’s because the thisTest function is a global function, and all global variables are assigned to the window object. So the code above is the same as:

window.thisTest = function() {
  alert(this);
}
window.thisTest();

The only difference is that in the latter example, our function is an anonymous function that is assigned to a variable, and the first one is a named function.

So now that we know that a global function is assigned to the window object, we can take it a step further. Take this code:

var color = 'red';
function tellColor() {
  alert(color);
}

It can be written like this instead:

window.color = 'red';
function tellColor() {
  alert(window.color);
}

This is better, because we clearly state that it’s a global variable we’re using. Since you should be very careful about using global variables, we want it to be very obvious in the code that the variable is global. But we take it even a step further, by doing:

window.color = 'red';
function tellColor() {
  alert(this.color);
}

So why is this better, you might wonder? Because we’re not explicitly using a global variable, and here’s why:

window.color = 'red';
window.tellColor = function() {
  alert(this.color);
}

var other_colors = {};
// Could also be var other_colors = new Object();
other_colors.color = 'green';
other_colors.tellColor = window.tellColor;
other_colors.tellColor();

This code will alert “green”, because of how Javascripts “this” reference work. So let’s go through the code. First, we define an object, “other_colors”. Then we assign the color property to that object, and then we assign the function. Now that part may be a bit strange, since we’re working with a function without calling it, we’re passing it around. This works because everything in Javascript is an object, even functions. And we can pass objects around, and assign them to variables, which is just what we’re doing here.

And when were assigning other_colors.tellColor to window.tellColor, it’s still the same function, but the “this” reference points to different objects in other_colors.tellColor and window.tellColor.

This allows you to write highly reusable code, since you can use the exact same function, but assign it to different objects and get different results. So if you’re familiar with the concept of inheritance, mixins and traits in OO, you can see how you can implement it in Javascript, it’s basically just copying function pointers from one object to another.

Iterating over this

Since everything in Javascript is an object, basically everything can be iterated over, and especially the “this” reference. Like this:

// Just a simple namespace
var ns = {};
ns.foo = 'bar';
ns.baz = 'foo';
ns.iterator = function() {
  for(var k in this) {
    alert(k +' => '+ this[k];
  }
}
ns.iterator();

This code will alert:

foo => bar
baz => boo
iterator => function() {
  for(var k in this) {
    alert(k +' => '+ this[k];
  }
}

Because of how Javascript works, you can access object properties both with object.property, and object['property']. So this code will iterate over all properties in the object which the iterator function is attached to and alert the property name and the property value, even our iterator function gets alerted.

To really get the best from Javascript, you should also read up on how closures work.

I decided from the start that I wanted to use jQuery, and Object Oriented Javascript. To mimic OO inheritance, I once again used John Resigs Simple Javascript Inheritance.

So the first thing to do was to model the entities I needed in the game. I started out with the obvious one, the Unit class. Added a few methods to it, and moved on to the Map class, because I wanted to get something at least partially working very fast. So I made a Map class that generated a map of tiles that could hold units. I greated a Tile class, and the Map class would hold all instances to the tiles. A tile has a “height” property, which defines the altitude of it (1 is deep water, 6 is low land, and 10 is oh-my-god-that’s-high-mountains). For now, I’m just randomizing the heights of the generated tiles, but that doesn’t make a very realistic map, so that’s on my TODO-list.

To get something working, I needed a way to connect unit to tiles. At first, I thought about letting the Unit hold an instance to the Tile it was on, but soon realized that it wouldn’t be a good idea. Instead, I created a UnitLocations class, which holds all units and all tiles, and connects them.

I also needed to be sure that units can’t move over the map as they like, land units can move over water (except the JesusUnit, which will be covered in part 23 of this series). So I created a LandUnit, and a WaterUnit, derived from the Unit base class. For now, when you try to move a unit, the game.Tile::canTake(game.Unit unit) method is queried to see if the unit can be moved to that tile. I’m pretty sure I have to move that logic to somewhere else at a later stage, but it’s good enough for now.

So I had a map, and I had a couple of units on it, that could move around. Then I remembered that Civilization is turn based. And my ambition is to let players play against each other over the series of tubes that we call the Internets. But sitting and waiting for other players to make their move can be tiring at best, so I needed another solution. Instead, i decided that Units has a “move_points”. Let’s say that LandUnit has 3 move_points, and moves over three tiles. Then move_points becomes zero, and that unit has to rest for a couple of seconds before it can move again. Right now, it’s accomplished by an interval running in every unit that adds move_points every two seconds. Each unit type also has a “max_move_points” property, so you wouldn’t be able to move the unit over a gazillion tiles if you waited long enough.

So I was quite excited about this, and wanted to move on and make more features. But then I stopped and thought some more about it, and realized that I need an event architecture to move on. And I hear you, Javascript already has events, and jQuery allows you to trigger custom events that you define on your own, but I wasn’t quite satisfied with how that worked. So I’m going to get cracking on a way to define and trigger my own events, and that will be part 2 of this series.

You can find the game here for now: http://dev.online.nu/game/.
When you want to move a unit (a unit is one of those pretty red squares), just click on it, then move it by using your keyboard arrows.

Til then, happy coding!

I’m using John Resigs Simple Javascript Inheritance to emulate class inheritance in Javascript, so you might want to check that out.

So the first step is to create a base class that takes care of the getters and setters for us.

var DomainObject = Class.extend({
  init: function() {
    /**
     * Generating getters and setters for the domain object by looping over
     * all properties that start with _ and automatically creating getters/setters
     * If the property is "_first_name", the getter will become "firstName()", and
     * the setter will become "setFirstName()"
     */
    for(var key in this) {
      createGettersAndSetters(key, this);
    }
    function camelize(str) {
      var ret = '';
      for(var i = 0; i < str.length; i++) {
        var chr = str.charAt(i);
        if(chr != '_') {
          ret += chr;
        } else {
          i++;
          ret += str.charAt(i).toUpperCase();
        }
      }
      return ret;
    }
    function createGettersAndSetters(key, context) {
      if(key.indexOf('_') === 0 && typeof context[key] != 'function') {
        var set_method = 'set'+ camelize(key);
        // Make sure we don't override an existing setter
        if(!context[set_method]) {
          context[set_method] = function(value) {
            context[key] = value;
          }
        }
        // Using substr to remove the starting _, since we don't want the
        // string to start with a capital letter, as we do with the setters
        var get_method = camelize(key.substr(1));
        // Make sure we don't override an existing getter
        if(!context[get_method]) {
          context[get_method] = function() {
            return context[key];
          }
        }
      }
    }
  }
});

So now that we’ve got our class that handles the magic, we need to test it!

var User = DomainObject.extend({
  _id: false,
  _name: '',
  setId: function(id) {
    if(validUserId(id) {
      this._id = id;
    }
  },
  sayHello: function() {
    alert('Hi! My name is '+ this.name());
  }
});

var usr = new User();
usr.setName('Anders');
// Will alert "Hi! My name is Anders"
usr.sayHello();

So what is does is that it takes all properties of the “class” that begins with an underscore, and generates getters and setters for them, if a getter/setter isn’t already defined. The format for the methods are setProperty() and property(), so if you have a property called “_first_name”, the setter becomes “setFirstName”, and the getter becomes “firstName”.

Happy coding!