Crisis Averted!

Over the past few weeks I've noticed forums and blogs near and far having discussions on how to safely parse JSON in JavaScript. Most of these conversations hinge upon something like "because eval is simply not enough." And they are right.

So, how do you safely parse JSON in JavaScript? Luckily for us, Doug Crockford has done the work for us. Simply include his json.js in your project, and all String objects will have a safe parseJSON method. It uses a regular expression to weed out malformed and possibly malicious JavaScript.

In addition, you'll also find that the Array, Boolean, Date, Number, Object and String types have a toJSONString method that converts a JavaScript value to a JSON value.

Here's a quick and dirty example:

var json = {
  'foo': 12,
  'bar': 'beer',
  'baz': ['fish', 'fleas', 'fools']
}.toJSONString();

console.log(json); // Prints JSON string

// Safely parse JSON string
json = json.parseJSON();

console.log(json); // Prints JSON object

When I first mentioned JSONQuery, I actually posted the core functionality of a more comprehensive parser. While I tried to keep things simple by writing queries in JavaScript, the task at the time required a tiny slice of custom syntax. Because JSONQuery grew in size, and in order to keep things simple, I stripped out the custom bits before writing up the original post. In hindsight, I realize the original code may be more complex than it needs to be.

If JSONQuery accepts queries written in JavaScript, why should we waste time with a custom parser when JavaScript has a built-in parser, namely eval? That all depends on how you feel about eval. For example, Douglas Crockford famously frowns upon eval:

The eval function (and its relatives, Function, setTimeout, and setInterval) provide access to the JavaScript compiler. This is sometimes useful for parsing JSON text, but in virtually all other cases it indicates the presences of extremely bad coding. The eval function is the most misused feature of JavaScript.

JSONQuery is at its core a JavaScript parser. Since any JSON text has presumably already been parsed and converted into an Object, what we're actually building is a general purpose Object query. So, assuming you're comfortable with eval in this context, JSONQuery evolves into Object.query and becomes even simpler. Here is the new Object.query in action:

Object.prototype.query = function(query) {
  var result = eval('this.' + query);
  return !!result ? result : null;
};

var json = {
  'name': 'Bob',
  'address': [{
      'street': '1234 Main St.',
      'city' : 'New York',
      'state': 'NY',
      'zip': '10101'
    },{
      'street': '5678 First St.',
      'city' : 'San Francisco',
      'state': 'CA',
      'zip': '94126'
    }]
};

json.query('address[1].zip'); // 94126

Of course, there are still issues present in this minimalist implementation. Are we certain query is a String? Are we certain query is safe to eval? Are there other sanitizations we should perform? What can be done about any parse errors during eval? These are basic issues that can be easily corrected before putting Object.query into the wild.

These issues aside, the evolution of JSONQuery to Object.query has several benefits. It's much easier to understand what's happening. By its nature, eval is much faster than the original parser. Finally, it's more useful as a method present on any Object. All of this assumes, of course, that there is a need to retrieve the value of a specific property of an object at any given depth dynamically, using queries generated at run-time.

The object oriented features of PHP 5 are leaps and bounds more complete than PHP 4. In fact, PHP 5 could almost pass for a true object oriented language in many ways: visibility, overloading, reflection, etc. Yet there are quite a few holes in its implementation that can make it painful to work with compared to similar languages. One well-known issue is that parent constructors are not implicitly called in derived classes; you must explicitly call parent::__construct().

I recently stumbled into a similar hole in PHP 5's OO implementation: class methods and members declared as static do not behave as one might expect with respect to inheritance. Given a base class, Animal, and two derived classes, Dog and Cat, let's assume that all Animals have a color and that it defaults to black.

<?php
class Animal
{
  protected static $color = 'Black';

  public static function getColor()
  {
    return self::$color;
  }
}

class Cat extends Animal
{
  protected static $color = 'Brown';
}

class Dog extends Animal
{
  protected static $color = 'Grey';
}
?>

Nice and simple, short and sweet. Animal has a color that defaults to black, and we've extended Animal with a Cat that defaults to brown and a Dog that defaults to grey. All fine and good. That is, until I want to ask the Dog or Cat classes what their default colors are.

<?php
echo Animal::getColor(); // Black
echo Dog::getColor();    // Black (huh?)
echo Cat::getColor();    // Black (what?)
?>

It turns out that static methods are called within the scope of the class where the method is defined. In this case, Animal. So, even though Dog and Cat both inherit the static method getColor(), its scope is bound to Animal. In fact, the PHP Manual attempts to explain this little 'feature':

... static method calls are resolved at compile time. When using an explicit class name the method is already identified completely and no inheritance rules apply. If the call is done by self then self is translated to the current class, that is the class the code belongs to. Here also no inheritance rules apply.

This issue has been a pain point for me lately, and I've resorted to some horrendous and clumsy workarounds to mimic the expected behavior. Until now, there has been very little standing in my way of accomplishing most anything with PHP with relative ease. This is by far one of the most annoying dealings I've had with PHP in over 8 years.

I stumbled on a job listing at Meebo today, calling for a JavaScript Ninja. The job description poses a few JavaScript puzzles for candidates to solve and submit along with their résumés.

Perhaps the trickiest puzzle of the lot would be #3, since its topic is only recently becoming more well known: using a double-bang (!!) in a boolean test. I found the rest of the puzzles, however, to be fairly straight forward, and not very tricky at all. I would imagine that a true JavaScript Ninja would be subjected to a more rigorous test of skill than these small puzzles.

Realistically, the puzzles are a great way to weed out those who've seen JavaScript from those who know JavaScript. In fact, they have given me some great ideas for new interview questions to add to my aging bag of tricks.

Let's assume you have a JSON object with a predictable structure. Let's also assume you need a way to retrieve the value a specific field, at any given depth, dynamically. That is, you don't know ahead of time exactly which field's value you need. The query will be generated at run time.

JSONQuery allows you to access the value of a specific field of a JSON object by applying a query string written in JavaScript syntax.

Here's a simple example of JSONQuery in action:

var json = {
  'name': 'Bob',
  'address': [
    {
      'street': '1234 Main St.',
      'city' : 'New York',
      'state': 'NY',
      'zip': '10101'
    },
    {
      'street': '5678 First St.',
      'city' : 'San Francisco',
      'state': 'CA',
      'zip': '94126'
    }
  ]
};

var query = 'address[1].zip',
    val   = jsonQuery(json, query);

console.log(val); // 94126

I realize at first glance it may seem silly to even go down this path. But the need arose recently where I needed something just like this. It may still be silly, but it works damn well. If you have suggestions or improvements, please share.

Full JSONQuery code:

function jsonQuery(json, query) {
  var params = query.split('.'),
      result = json;

  for (var i = 0, length = params.length; i < length; ++i) {
    var parts = params[i].split('['),
        index = null;

    for (var j = 0, len = parts.length; j < len; ++j) {
      index = parts[j].replace(/\]$/, '').replace(/'/g, '');

      if (!result || !result[index])
        return null;

      result = result[index];
    }
  }

  return result;
}

I've been putting it off for a few years now, but I recently found myself the proud owner of the Pickaxe book. (Thanks Ryan!) What once seemed as mindbending as hardcore Perl is now very much less so, and a pleasure to work with so far. Though only a week into learning Ruby, I'm happy to have made the leap.

Recently while working on a few Swing applications at work, I realized that one of the most frustrating aspects of developing Swing apps (and perhaps GUI software in general) is also one of the most mundane: user preferences. Building out the main application is tremendously rewarding, but providing users with preferences can be a huge pain.

Most GUI applications provide some way for a user of the application to modify how the application behaves at run time. In fact, users expect some level of control over the application's behavior. As a user, I like having options, even options I know I won't need right away but might like at a some point in the future. But users — myself included until recently — don't realize that, as a developer, providing users with options is often a huge pain.

First, the preferences need a place to live. As developer, I need a way to retrieve preferences from somewhere and store them back again. This storage system could be a text file of key-value pairs, more complex XML data, an OS-provided data store (e.g. Windows registry), a relational database, or umpteen other possibilities. Choosing the proper way to handle the storage of user preferences depends on the size of the project, but is by no means a simple matter. Simple applications with many options can quickly outgrow a simple storage system.

Once I've decided on a storage system and implemented an API for manipulating it, it's time to give the user a way to see and modify the current configuration - a user interface. As luck would have it, there are no standard conventions for creating preferences UIs. Because the preferences for a unique application are, well, unique, there is no one generalized UI that will work in most situations.

It was at this point in the development of one Swing app that I had an epiphany.

A user preferences UI and storage system is a complete project in and of itself, with a purpose entirely separate from that of the application to which it provides configuration abilities.

It was also at this point in the development of one Swing app that I began to gently rock back and forth in my chair, mumbling incoherently as I realized exactly what I was up against.

The preferences UI has to make sense. The user has to be able to quickly find where a setting can be changed. If the preferences UI is too convoluted the application becomes difficult to configure, and the overall experience using the application can be adversely affected. Sometimes this is a task best left to designers or so-called information architects. I would advise against letting a strictly developer-type build your preferences UI. This is something that a user will see from time to time. It needn't be pretty, it need be easy to use.

Once I've sufficiently sketched the UI (or reviewed a designer's sketches) and feel I'm confident I understand how it will work, the biggest pain begins. I must now translate thoughts and drawings into code. This is perhaps the most time consuming step in the process. The preferences system I create must present a simple UI to the user and also be easily maintained when preferences are added, removed or modified.

Creating the UI itself isn't terribly difficult, but because preferences often use a myriad of UI controls such as text fields, select lists, drop downs and check boxes, the logic behind each control must be fleshed out and properly bound to the storage system. In some cases, controls will also have unique validation requirements such as a minimum character length or specific punctuation to avoid configuration errors. It's the 'controller' logic that is the real killer of moods. Creating this layer of the user preferences system is the most tedious and time consuming and can also be the least rewarding. It's just fluff, but it's important fluff. Therein lies the rub.

Finally, after I've designed and created the UI, bound the controls to the storage system, validated certain new values, after I click 'Save' and the the modified values are written out to the storage system, after the application responds to me changing preferences, my job is complete. I've just spent a few hours, likely days, and potentially weeks allowing Joe User to change his text color from Medium Quasar Blue to Metallic Pearl Shine. And because my application is not a Medium Quasar Blue to Metallic Pearl Shine font color changerator, I've just spent many hours on code that does not help accomplish my applications main goals.

At this point, my user is happy, and if I happen to work on another application that needs a Medium Quasar Blue to Metallic Pearl Shine font color changerator, I've already got some code to work with. However, I'll still need to decide upon the proper preference storage system, create a unique UI and write the tedious controller logic fluff. There's got to be a better way.