DI is about pushing object creation and wiring as high up in the application as possible, which gives you one central location for the flow of logic.

Code components have dependencies, whether you’re using Java or Javascript. When your UI widget needs to make a server request to fetch some content, you depend on some code to carry that out. There are usually three approaches.

1. Use a global symbol, such as $.ajax in the world of jQuery.

2. Use a service locator, something like:

function updateCustomer(locator) {
  var server = locator.server();
  server.get("...");
}

Or having the locator being a global variable.

3. Only pass in what you need, like this:

function updateCustomer(server) {
  server.get("...");
}

The first option is the simplest. $.ajax is just a global function that anyone can use. This is also why it’s the most problematic, because if anyone can use it anywhere, you will end up with no idea of which parts of your application is making Ajax calls. You’re basically saying “use any tools you like, I don’t care” to your function.

The second alternative passes in a service locator instead, which is better because you have control over what functionality you expose through your locator. It’s like saying “here’s a bag of tools, you can’t use any other than these, but do what you want with any of these in the bag”.

The third is the most straight forward. It’s like saying “here’s a screwdriver, it’s what you’re gonna use”. Since we’re just exposing the server object, there is no risk that other features using other objects will be added to our function. That is a risk with the other two solutions, since they expose more functionality than needed. Another benefit is that it’s very easy to spot what dependencies your objects have, since they are declared in the constructor. With a locator or with globals, you might have dependencies hidden in large chunks of code that are easy to miss. You are forced to think very hard about how your application is layed out, because it becomes very easy to spot if an object is doing to much, if it requires too many dependencies. You also have to think about how to pass these dependencies around.

Dependency injection is hard

So if the third solution is so great, how come most people use the first two? Simply because it’s hard to achieve. Using a locator is simpler, since you just pack a bag with lots of things and pass it around. But if you use the third option, you have to keep track of who wants the different tools, and make sure that they get them. You also need to make sure that everyone can’t ask for anything.

In other languages, there are frameworks that help you with these things. Automating object creation in a language like Java or C# is somewhat simple, because you have type hints in the constructors. You can inspect a constructor and find out what it wants. But there is no way to do that in Javascript, since it doesn’t have types or type hints. Because of this, making a DI container in Javascript is bound to get messy, because you need to define construction rules for all objects. This is problematic because new objects can’t be added to your application without modifying the wiring code.

A shot at an automated container in Javascript

So we now basically know what we need. A container that is semi-smart and can assemble hierarchies of objects. It needs to be able to create objects by convention instead of configuration.
To achieve this, we have a few options. First off, we can cast a constructor to a string which gives us the whole method body and then parse out the argument variable names and use them to map to objects. This is a brittle and error prone idea, since someone might rename a variable and that might take down the entire application. Another option is to add a sort of type hints. Something like this:

function Server() {
  return {
    get: function(...) {}
  };
}

function updateCustomer(server) {
  server.get("...");
}
updateCustomer.dependencies = ["Server"];

It’s a little unorthodox and perhaps not so Javascripty, but it makes our object more self contained. Our function still isn’t grabbing Server direcly as with a Service Locator, it’s merely saying that it would like to get some implementation that behaves like Server does. But it isn’t very pretty, because the type hints are below the function body, which can be an issue with a more lengthy function. So here’s some syntactic sugar:

var updateCustomer = dependant(
  ["Server"],
  function(server) {
    server.get("...");
  }
);

The dependant function just maps the function together with the type hints, and it also gives you a simple way to check who has which dependencies.

So now it’s just a matter of inspecting the dependencies array of a constructor to be able to map it together. Here’s a proof of concept:

var dependant = function(dependencies, func) {
    func.dependencies = dependencies;
    return func;
}

var Container = function() {
    var namespaces;
    var instances;
    var constructors;

    return {
        _init: function() {
            namespaces = [];
            instances = {};
            constructors = {};

            return this;
        },
        addNamespace: function(namespace) {
            namespaces.push(namespace);
        },
        get: function(klass) {
            if(!instances[klass]) {
                if(constructors[klass]) {
                    instances[klass] = constructors[klass]();
                } else {
                    instances[klass] = this.create(klass);
                };
            };
            return instances[klass];
        },
        create: function(klass) {
            for(var i = 0; i < namespaces.length; i++) {
                if(namespaces[i][klass] && typeof namespaces[i][klass] == "function") {
                    var constr = namespaces[i][klass];
                    if(constr.dependencies) {
                        var args = [];
                        for(var j = 0; j < constr.dependencies.length; j++) {
                            args.push(this.get(constr.dependencies[j]));
                        };
                        return constr.apply(namespaces[i], args);
                    } else if(constr.length == 0) {
                        return constr();
                    };
                };
            };
            throw "Cannot create '"+ klass +"' because there isn't a registered instance or \
                   constructor, and there was no way to auto wire it.";
        },
        registerConstructor: function(klass, creator) {
            constructors[klass] = creator;
        },
        registerInstance: function(klass, instance) {
            instances[klass] = instance;
        }
    }._init();
};

And some usage code:

var ns = {};
ns.Alerter = function() {
    return {
        alert: function() {
            alert("Mjello!");
        }
    }
}

ns.MyObject = dependant(
    ["Alerter"],
    function(alerter) {
        return {
            doStuff: function() {
                alerter.alert("Mjello!");
            }
        }
    }
);

var cn = Container();
cn.addNamespace(ns);

var o = cn.get("MyObject");
o.doStuff();

I haven’t used this type of DI in a Javascript application yet, so I can’t really say if it’s any good, but I get a good vibe from it so I’m planning on using it for a Javascript application that I’m about to create.

An added benefit here is that the dependencies array can contain anything, not just strings with function names. It could contain CSS selectors to let you decouple DOM access, and maybe even remove the tight coupling with a library such as jQuery or YUI. It could also contain an array of method names, something like:

ns.MyObject = dependant(
    [["alert"]],
    function(alerter) {
        return {
            doStuff: function() {
                alerter.alert("Mjello!");
            }
        }
    }
);

This says, “I need one object, and I need it to have an alert method”, which is basically a flirt with a structural type system that is a very good fit for Javascript.

Conclusion

Javascript is a very open language. You can choose to go OO or procedural, and you can even choose which type of OO you want to use, classical, prototypal or parasitic. It’s only natural then that there are also a number of different ways to manage dependencies in an application. So when you start a new project in Javascript, you have a smörgåsbord of ways to write code. There’s no wrong or right, there’s only what is appropriate for your application. But when you’ve decided which way to go, stick with it.

By using parasitic inheritance, you can avoid using the new operator all together. The new operator isn’t evil, but it’s problematic in that if you write a function and you expect it to be called with the new operator but someone forgets it, wild thing can happen, and it can be really hard to debug. Let’s take an example:

function greet() {
  alert("Welcome, everyone!");
}
function Greeter(name) {
  this.name = name;
}
Greeter.prototype.greet = function() {
  alert("Welcome " + this.name);
}
function Person(name) {
  this.name = name;
  this.greet();
  return this;
}
Person.prototype = new Greeter();
Person.prototype.toString = function() {
  return "I am " + this.name;
}

// Example 1
var name = "Andy";
var person = new Person("Coffeescripter"); // alerts "Welcome Coffeescripter"
alert(name); // alerts "Andy"

// Example 2
var name = "Andy";
var person = Person("Coffeescripter"); // alerts "Welcome Andy"
alert(name); // alerts "Coffeescripter"

This way of writing a class and saying that Person inherits from Greeter is rather ugly, so check out John Resigs implementation for some eye candy: http://ejohn.org/blog/simple-javascript-inheritance/

If you’re not familiar with how this works in Javascript, this may blow your mind. But it’s perfectly valid code, it’s just that the this variable points to different places depending on whether you used the new operator or not. When the new operator is used, this points to the new instance that was created. When you’re not using the new operator, this points to the object that the function was executed in, which in this case was the window object, and that is why this.name = name is overriding the value of the global variable name. This because var name = "Andy"; here is technically the same as window.name = "Andy";.

You can’t tell from inside the function if the new operator was used or not, so you can’t throw an exception if the new operator was omitted. You could just say that “all functions that begin with a capital letter should be called with the new operator, or else you’re stupid” and be done with it. And while that might be true, you’re still going to be the one debugging for an hour or so when the new guy who doesn’t know Javascript that well forgets about the new operator.

Parasitic Inheritance

So how about that parasitic inheritance then? It works like this instead:

var Greeter = function(name) {
  return {
    greet: function() {
      alert("Welcome " + name);
    }
  };
};
function Person(name) {
  var obj = Greeter(name);
  obj.greet();
  obj.toString = function() {
    return "I am " + name;
  }
  return obj;
}

// Example 1
var name = "Andy";
var person = new Person("Coffeescripter"); // alerts "Welcome Coffeescripter"
alert(name); // alerts "Andy"

// Example 2
var name = "Andy";
var person = Person("Coffeescripter"); // alerts "Welcome Coffeescripter"
alert(name); // alerts "Andy"

The behaviour is the same if you call Person with the new operator or not. And because of that, it simpler just to forget about the new operator. To me, this code is more straight forward and less magical than the first example, which is always a good thing. One issue people is having with this approach is that for every Person you create, you also create new versions of the greet and toString functions. With the first example, all Person objects share the exact same greet function. That of course means less memory usage, but it also introduces a somewhat scary thought. If all Person objects share the same greet function, what happens when someone decide to replace a persons greet function, it doesn’t just affect that object, it affects all person objects.

This trouble with parasitic inheritance

Something I kept running into with parasitic inheritance was how I didn’t have access to the created object in the beginning of the function, like this:

function Person() {
  var bazooka = Bazooka(this);
  return {
    shoot: function() {
      bazooka.shoot();
    }
  };
}

var Bazooka = function(parent) {
  return {
    shoot: function() {

    }
  }
}

Disregarding that we have a cyclic reference here between Person and Bazooka, the problem is that this in var bazooka = Bazooka(this); isn’t pointing to the person object that we are creating, but the object that the Person function is running in; the window object. So how do we get around this? We could do something like:

function Person() {
  var obj = {
    shoot: function() {
      bazooka.shoot();
    }
  };
  var bazooka = Bazooka(obj);
  return obj;
}

But that’s about as pretty and clear as VB’s let’s-use-a-variable-with-the-same-name-as-the-function-as-the-return-mechanism-because-function-names-never-change-and-nobody-will-forget-to-update-all-references-to-the-return-variable-when-the-function-is-renamed. So yeah, we can do better. Something like this:

function Person() {
  var bazooka;
  return {
    _init: function() {
      bazooka = Bazooka(this);
      return this;
    },
    shoot: function() {
      bazooka.shoot();
    }
  }._init();
}

It looks a lot better, and if you’re used to classical inheritance, you’re probably used to looking for property declarations at the top, a constructor right after that, and methods down below. If you’re the suspicious type, you might have noticed that by doing this, we are exposing the _init function to be called again. Which is true, there is nothing stopping you from doing: var p = Person(); p._init(); But if this means the end of the world for you, you can always add this._init = undefined; as the first line in the _init function, which makes it impossible to call it twice.

Privileged functions

In the first example, there is no way to have a private function that all your public functions can call, not even with John Resigs prettier version. But with parasitic inheritance, it’s very natural to hide variables and functions through closures, like this:

function Person(name) {
  var bazooka;
  var greet = function() {
    alert("Hi! I'm " + name);
  };
  return {
    _init: function() {
      bazooka = Bazooka(this);
      if(name == "Andy") {
        greet();
      }
      return this;
    },
    shoot: function() {
      if(name != "Andy") {
        bazooka.shoot(name);
      }
    }
  }._init();
}

Through the closure that the function call to Person creates, both shoot and _init has access to greet, bazooka and name.

Conclusion

The key difference between classical and parasitic inheritance is that the classical way is much more focused on an objects type. Change one object, and all other objects of that same type get’s changes. Parasitic inheritance doesn’t care about types. It’s more about assembling functions and properties to create a logical unit. Instead of caring if an argument to your function is of the type Person, you only care about whether or not it has the function greet. There is no right or wrong here, and the two can happily co-exists, but the thing that makes me use parasitic inheritance is how it’s aligned with the dynamic nature of Javascript.

But even with ASP.NET MVC, and Django, I still come back to doing web development in PHP in the projects I do on my spare time. And the reason is definitely not language elegance, but it’s very much because of the framework/library Konstrukt.

Most of the other MVC-ish frameworks out there use the idiom of “/controller/action/id/some/other/parameter”, and it just doesn’t feel right. It feels right in simple cases like “/users” and “/users/12″. But what about “/users/edit/12″? The url should – if you ask me – be hierarchical, and it should always be possible to remove the last url segment, and still get a logical response. But if you remove 12 from “/users/edit/12″, what do you get? A bunch of forms, so you can edit all users at the same time?

Instead, Konstrukt handles this by using hierarchical controllers/components. So instead of mapping a request to one specific controller, one controller handles each url segment. So if you have a url like “/users/12/comments”, you’d start of by having the root controller handle the “/” part. That controller sees that the whole url isn’t just “/”, so that controller is responsible for mapping forward to another controller, to handle the “users” segment. That controller also sees that there’s more in the url, and maps forward to a controller that handles “12″, and then – last but not least – the controller that handles the “comments” part. That controller sees that it’s the last part, so it’s responsible for rendering the result. You might think that ends up being an awful lot of controllers, and it sure does, since one controller basically does just one thing. But that’s a good thing. Instead of having a User-controller with Add, Remove, List, Edit-actions. It also lets you reuse controllers very elegantly. You might have both “/comments”, and “/users/12/comments”, for which you can reuse the same controller. Each controller has access to it’s parent controller, so the controller can use it’s parent as a way to filter out comments per user, or display all comments.

I know that I can use routing in most other frameworks to get almost the right result, but it just ends up feeling like I’m wedging it in, it’s not as elegant as with Konstrukt, mostly because of the “one controller with many action methods” thing.

This, together with having control over controller creation which allows you to use a DI container to create them, together with excellent support for different content types, together with the fact that it’s very (almost extremely) loosely coupled, makes me love PHP. I like PHP, but Konstrukt makes me love it. If I start a new web project in Python or C#, I start of with a great feeling of how elegant those languages are, but I always end up really missing PHP because of Konstrukts elegance. If I could just find the time to port Konstrukt to C# and Python…

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';
  var fn = function() {
    var foo = 'baz';
    alert(foo);
  };
  alert(foo);
  return fn;
}
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!