adamlogic

Last week, I gave a presentation at the Columbus Ruby Brigade meeting about metaprogramming JavaScript. Although I posted that presentation here, the slides were short on text, so I thought it would be more helpful if I wrote a series of tutorials to discuss these concepts. Also, I want to take my example a bit further with more extensions and refactoring.

But before we dive into what metaprogramming is, why it is important, and how we can bring it to life in JavaScript, let’s start with an example that we can build on throughout the tutorial: Say we’ve got a really basic form with select boxes for country and state, and we have a requirement to only show the state when the selected country is “United States”. [example]

Event.observe(window, "load", function() {

  Event.observe($("country"), "change", function() {
    if ($F("country") == "United States")
      $("state-field").show();
    else
      $("state-field").hide();
  });

});

The code I have used to implement this behavior is pretty basic, but it does use a bit of Prototype that I should explain. If you’re a Prototype guru, you can safely skip this paragraph. 1) Event.observe is Prototype’s version of the addEvent method every JS developer has in their toolbox. 2) The dollar-sign method is a shortcut for document.getElementById, which is handy since I seem to do this *everywhere*. 3) $F is a similar shortcut which grabs the current value of any form element. 4) One of the many things that Prototype provides is a set of extension methods available on all HTML elements - show() and hide() are two examples of this which simply modify the “display” style property of an element.

This code works just fine, and there is certainly nothing wrong with it for such a simple requirement. Unfortunately, things get hairy as requirements change. Let’s see how our code scales when we want to do the following:

add province field
show province when country is “Canada”
show state when country is “United States”
show Brutus when state is “Ohio” or “Michigan”

Check it out in action: [example].

Event.observe(window, "load", function() {

  Event.observe($("country"), "change", function() {
    var country = $F("country");
    if (country == "United States") {
      $("us-state-field").show();
      $("province-field").hide();
    } else if (country == "Canada") {
      $("province-field").show();
      $("us-state-field").hide();
    } else {
      $("us-state-field").hide();
      $("province-field").hide();
    }
  });

  Event.observe($("us-state"), "change", function() {
    var state = $F("us-state");
    if (state == "Ohio" || state == "Michigan")
      $("brutus").show();
    else
      $("brutus").hide();
  });

});

Using the same style of event handling and field checking, I have attempted to meet the new requirements. Unfortunately, we have several problems. First, the code has two bugs: everything is shown when the page initially loads, and hiding the state field doesn’t automatically hide Brutus. I refer to the latter as the “domino” bug, since fields that are dynamically shown and hidden will create a domino effect if other elements are dependent on them. Knowing that these bugs exist, let’s put them off for a just a bit.

Our second problem in the code is readability. I’d like to be able to glance at the code and instantly know what it’s trying to accomplish. I’d like to be sure that I haven’t left out or misunderstood any requirements. When a requirement changes, I’d like to know exactly where my code needs changed. And when I make those changes, I’d like to have confidence that I’m not breaking something else. This is where the concepts of metaprogramming come into play.

The Pragmatic Programmer describes metaprogramming as pulling the details out of your code and into metadata. Often this metadata comes in the form of a configuration file or some other data source, but there is no reason it can’t be executable code, as long as you enforce a clean separation of the “what” and the “how”. The idea with this approach is to write your code with a vocabulary that mirrors your problem domain (the “what” you’re trying to describe). This kind of mini-language is where we get the term “domain specific language”, or DSL.

Now, in our case, the details - or the “what” - are the actual rules for when to show and hide form fields. Right now we have the rules intertwined with the implementation of those rules, and we have felt the pain from it - pain that will only continue to worsen as requirements change and features are added. What would be great is if we could pull those rules out so we can modify them independently of the implementation. What would be great is if those rules were written in a language that looks more like our problem domain than JavaScript. What would be great is if we built a DSL for dynamic form behavior.

That’s exactly what we’ll do… in part 2.