Monday, December 17, 2012

getters, setters, and redefining javascript

Given enough time, I'm sure every browser will support proper JavaScript getters and setters. Whether getters and setters are truly good is another matter. Let's assume they're good. And let's pretend we want to use them ... right now.

I'd posit there's a potential solution. And while I can't offer a full or fool-proof solution at this time, an intriguing thought struck me. That is, getters and setters are effectively nothing more than a compiler rewriting code that looks like this:

console.log(obj.property);
console.log(obj['property']);

Into something that looks more like this:

console.log(obj._get("property"));
console.log(obj._get("property"));


I'm not entirely sure why we feel better treating obj.property like any other property. Why don't we want to explicitly acknowledge the "work" that must be done each time we hit it? Perhaps it affords us some debatably necessary ignorance. Perhaps it allows for greater laziness. Perhaps we think the thinking or the characters we save by using the property notation all the time, rather than only when we're referring to actual properties, significantly outweighs the performance cost of preprocessing our code.

... awkward silence ...

Nevermind. Back to pretending getters and setters are unequivocally good ...

I've seen a lot of folks, including myself, trying to hack getters and setters (and even "dynamic" getters and setters) into JavaScript without fully recognizing that JavaScript is a dynamic language. It's compiled at runtime. And segments of every script can even be compiled mid-stream using fancy things like eval(). (Contrary to the scary stories you may have heard, eval() is not evil unless it is abused. And in my opinion, this is precisely the sort of rare case in which eval() is an acceptable solution.)

So, without spending a great deal of time trying to produce a perfect solution, let's just prove the concept with some basic getters and setters using some very simple self-improving script.

When an object property is referred to, we want our self-aware script to look for mechanisms to interact with that property, going from most specific to least specific. That is, when property obj.prop is referred to, we want to use the first available mechanism on our short, ordered list of possible mechanisms.

  1. obj.prop.(get|set(v)) - the property-specific getter or setter
  2. obj.prop - the property itself
  3. obj.(get(n)|set(n,v)) - the class-level getter or setter
  4. undefined - though not a getter or setter, explicitly acknowledge this as the default

Implemented as getter/setter wrappers, our logic looks like this:

Object.prototype._get = function(n) {
  // first, infinite recursion prevention
  this.__gotten = this.__gotten || {};
  if (this.__gotten[n]) {
    return this[n];  // even if it's undefined.
  } else {
    this.__gotten[n] = true;
  }

  // then, call getters
  var rv;
  if (this[n] == undefined) {
    if (this['get'] && typeof(this.get) == 'function') {
      rv = this.get(n);
    } else {
      rv = undefined;
    }
  } else {
    if (this[n]['get'] && typeof(this[n].get) == 'function') {
      rv = this[n].get(n);
    } else {
      rv = this[n];
    }
  }

  // unset the "gotten" flag so the getter works properly in
  // subsequent calls
  this.__gotten[n];
  return rv;
}

Object.prototype._set = function(n, v) {

  // first, infinite recursion prevention
  this.__setted = this.__setted || {};
  if (this.__setted[n]) {
    return (this[n] = v);  // even if it's undefined.
  } else {
    this.__setted[n] = true;
  }

  // then, call setters
  var rv;
  if (this[n] == undefined) {
    if (this['set'] && typeof(this.set) == 'function') {
      rv = this.set(n, v);
    } else {
      rv = undefined;
    }
  } else {
    if (this[n]['set'] && typeof(this[n].set) == 'function') {
      rv = this[n].set(n, v);
    } else {
      rv = (this[n] = v);
    }
  }

  // unset the "setted" flag so the getter works properly in
  // subsequent calls
  this.__setted[n];
  return rv;

}

With or without any fancy rewriting, we can we then build getter/setter endowed objects like this:

var o = {
  a: 1,
  b: {
    get: function() { return 2; },
    set: function() { /* do nothing */ }
  },
  get: function(n) {
    if (this[n] == undefined) {
      this[n] = 0;
      return this[n];
    }
  },
  set: function(n, v) {
    this[n] = v % 2;
  }
};

And we can interact with them like this:

console.log(o._get('a'));
console.log(o._get('b'));
console.log(o._get('c'));
o._set('d', 123);
console.log(o._get('d'));

And, we'll see precisely what we expect to see in our console. But, our goal is to see the same output by writing this:

console.log(o.a);
console.log(o.b);
console.log(o.c);
o.d = 123;
console.log(o.d);


Well alright. So, let's just have our script rewrite itself a little before it executes. And the best way to do that, I'd argue, is to wrap our code in a function that make some minor edits and eval()'s the result. So, here my first simple working implementation:

var F = function(f) {

  var _f = f.toString();
  _f = _f.replace(/\.([a-zA-Z0-9_])+\s*=\s*([^=].*)\s*;/gm, "._set('$1',$2);");
  _f = _f.replace(/\[(['"a-zA-Z0-9_]+)\]\s*=\s*([^=].*)\s*;/gm, "._set($1, $2);");
  _f = _f.replace(/\.([a-zA-Z0-9_])+(\.|\s|;|\n|\))/g, "._get('$1')$2");
  _f = _f.replace(/\[(['"a-zA-Z0-9_]+)\]/g, "._get($1)");

  eval("var rv = " + _f + "");
  rv._original = f; // for debugging, curiosity, etc.
  return rv;
} // F()

Using our modifications to the Object prototype, and our fancy F() function, our getter/setter endowed object works as intended like this:


F(function() {
  var o = {
    a: 1,
    b: {
      get: function() { return 2; },
      set: function() { /* not allowed */ }
    },
    get: function(n) {
      if (this[n] == undefined) {
        this[n] = "no.";
        return this[n];
      }
    },

    set: function(n, v) {
      this[n] = v % 2;
    }

  };


  console.log(o.a);
  console.log(o.b);
  console.log(o.c);
  o.d = 123;
  console.log(o.d);
})();


As expected, our console shows:

1
2
NaN
1

Remember, when pondering line 3 of our output, that our dynamic getter is returning the result of an assignment, which works through our dynamic setter, which expects the assigned value to be a number.

Also bear in mind, this little example is fairly simple, and our F() can tend to mangle more complex syntaxes. Our regular expressions are simple and inflexible. For instance, we can throw it off by hiding an assignment in conditional or by simply using the increment/decrement operators.

Consider this awkwardly written loop.

var app = F(function() {
  var o = {i:0};
  var rand = false;
  while (o.i = rand) {
    console.log(o);
    rand = Math.random();
  }
  o.i--;
  o.i += 5;
});

Now, we wouldn't expect to see such a silly loop in a real application. But, we should expect it to work nonetheless. And it doesn't. The F() rewritten function subverts some getter/setters and replaces others with invalid code. The rewritten, broken function looks like this:

function () {
  var o = {i:0};
  var rand = false;
  while (o._get('i') = rand) {
    console.log(o);
    rand = Math.random();
  }
  o.i--;
  o._get('i') += 5;
}

Multi-line assignments break too. This won't work:

var app = F(function() {
  var o = {};
  o.i = "This"
    + " assignment spans"
    + "multiple lines.";
});

So, F(), as I have defined it above, is limited. But, it illustrates the concept: JavaScript is a dynamic, compile-as-needed programming language. If you want getters, setters, operator overloading, a fancy short-hand syntax, or anything else, implement it!

Please feel free to suggest improvements. My latest getter-setter rewriter will be available here, and will include any suggestions I find significant and valuable. http://www.thepointless.com/js/accessors.js

Tuesday, October 16, 2012

building custom tags in html5 and javascript

If you've had the chance to work with Facebook's Social Plugins, you've likely come across the option to embed their widgets using XFBML. They offer a similar "HTML5 compatible" option, but I tend to think the custom, name-spaced tags option is neat. So, let's explore one way to do that.

As an example of the usefulness, I'll use my recently completed book of small potatoes (wisdom of the ancients) from thepointless.com. With each wise guy quote, we see markup in the following format, which renders a voting widget, with the help of some fancy JavaScript:

<tpdc:voter method='/ajax/pointlisting_vote' record_id='37' vote='1'
 fb_like_url='http://www.thepointless.com/pointlistings?id=37'>
  <tpdc:vote>vote<tpdc:vote>
  <tpdc:unvote>unvote<tpdc:unvote>
  +<tpdc:count>1<tpdc:count>
<tpdc:voter>


(Rather the post the full script that does the magic here, I'll be using some trivial simplified JavaScript here for conciseness. You can take a peek at it in action if you're interested.)

To prevent Internet Explorers 7 and 8 from giving us the silent treatment come script-time, our custom tags need to live in a namespace. (Other browsers, as far as I know, ignore the namespace altogether.) And the namespace must be defined in the opening html tag:

<html xmlns:tpdc="http://www.thepointless.com/ns/tpdc">

Now, as you might imagine, a little JavaScript magic is needed to work with these nodes gracefully. And although a touch hacking, it may not be as hackish as you'd expect! As seen on the thepointless.com, here is the function we use to grab these nodes and "import" their attributes correctly:

var getNodes = function(n, q) {
    try {
        // i think "r" stands for "return" here.

        // in any event, our first step is to try to find the nodes
        // by their full names -- that is, with the namespace.
        var r = n['getElementsByTagName'](q);
        if (r.length < 1) {

            // ... and if we don't find anything, omit the namespace,
            // if present.
            var p = q.split(":");
            if (p.length == 2) {
                r = n['getElementsByTagName'](p[1]);
            }
        }

        // import attributes, for each node
        for (var i = 0; i < r.length; i++) {


            // for each attribute in r[i]

            // first, make sure we're not attempting to RE-import attributes.
            var ri = r[i];

            if (!ri.__attributes_imported) {

                // so, we basically iterate through each attribute and
                // "re-attach" it to the node directly. seems silly, but
                // it allows our scripts to operate on these attributes
                // later much more naturally.
                for (var ai = 0; ai < ri.attributes.length; ai++) {
                    var att = ri.attributes[ai];
                    if (!ri[att.name]) {
                        ri[att.name] = att.value;
                    }
                }
                ri.__attributes_imported = true;
            }
        }

        // and finally, give that list of nodes back.
        return r;
    } catch (e) {
        return [];
    }
} // getNodes()


This getNodes() implementation works in recent versions of Chrome, Firefox, Safari, and IE7+ (not tested in IE6). One-off use of the function works similarly to (but not exactly like) the normal getElementByTagName() function. So, if we want to work with all the tpdc:voter nodes, we could do this:

// get an array of tpdc:voter nodes.
var voterNodes = getNodes(document, "tpcd:voter");

// for each one, let's add an onclick event that simply displays
// the method attribute.
for (var i = 0; i < voterNodes.length; i++) {

  // to be clear, the "this" here is the node itself
  voterNodes[i].onclick = function() { alert(this.method); }
}


Pretty simple. And working with child nodes is just as easy. Suppose we want to loop through all the tpdc:voter nodes and make each tpdc:count node with a value of 10 or more bold. Now, with this trivial example, we could do this globally, like so:

// get all the tpdc:count nodes.
var countNodes = getNodes(document, "tpdc:count");

// make each one with an innerHTML value >= 10 bold
for (var i = 0; i < countNodes.length; i++) {
  if (parseInt(countNodes[i].innerHTML) >= 10) {
    countNodes[i].style.fontWeight = 'bold';
  }
}


Or, we can work within the context of a single tpdc:voter node, as we might in a voter node's class method. A trivial example again, but this works as expected:

// assume we already have a tpdc:voter node, voterNode
var countChildren = getNodes(voterNode, 'tpdc:count');
// act on all tpdc:count nodes found.
for (var ci = 0; ci < countChildren.length; ci++) {
  if (parseInt(countChildren[ci].innerHTML) >= 10) {
    countChildren[ci].style.fontWeight = 'bold';
  }
}


Neat.

But, we're not done yet. What we really want is the ability to treat these custom tags like instances of a real class. And we can! We can define a namespace (empty object) with some classes (functions) and bind them semi-automagically to the DOM nodes.

Let's consider a TPDC namespace with two very simple classes:

// the namespace
var TPDC = {};


// class Simple
TPDC.Simple = function() {
  // we can do things at object "instantiation" time
  this.innerHTML = "Simple";
} // class TPDC.Simple()

// class LessSimple
TPDC.LessSimple = function() {

  // we can also define object methods
  this.makeSimple = function() {
    this.innerHTML = "Simple";
  } // TPDC.LessSimple.makeSimple()

  this.onClick = function() {
    this.makeSimple();
  } // TPDC.LessSimple.onClick()

  this.innerHTML = "Less Simple";
} // class TPDC.LessSimple()


Simple. And so is binding our whole TPDC "namespace" to the appropriate document nodes:

for (var k in TPDC) {
  var tpdc_nodes = getNodes(document, 'tpdc:' + k);
  for (var i = 0; i < tpdc_nodes.length; i++) {
    TPDC[k].apply(tpdc_nodes[i]);
  }
}


And, if we want to stuff our getNodes() function stuffed neatly away in a shared library, we can also add a convenient little binder method:

var BindNS = function(ns_name, parent) {
  // "find" the namespace within its parent, given its name
  var p = parent || this;
  var ns = p[ns_name];


  // apply the class constructors to the document nodes
  for (var k in ns) {
    var ns_nodes = getNodes(document, ns_name.toLowerCase() + ":" + k.toLowerCase());
    for (var i = 0; i < ns_nodes.length; i++) {
      ns[k].apply(ns_nodes[i]);
    }
  }
} // BindNS()


And then bind our simple TPDC class with one line:

BindNS('TPDC');

And at this point, any tags in our document that look like these will operate as though they're instances of our Simple and LessSimple classes:

<tpdc:simple>weeeeee...</tpdc:simple>
<tpdc:lesssimple>...eeeeee!</tpdc:lesssimple>


They also operate as generic DOM nodes too, of course. Your JavaScript classes are, in many respects, subclasses of the Node class.

Two things to remember though:

1. Most browsers ignore the namespace. So, this approach doesn't grant you an ability, so far as I know, to create namespaces with identical class names. You can work around this by including the namespace again as a prefix in your class names if you need to.

  and

2. It's invalid markup! It's served up with a text/html content type and an HTML5 doctype, which explicitly forbids tag namespaces. So, you might even call it grossly invalid! That said, of all the custom tag variations I tested, this syntax actually provided the most consistent behavior.

In any event, I like the way this works. I can simplify and minimize both my markup and my script using this approach. And I definitely plan on playing with it more. One thing I'm pondering is an elegant way to automagically attach custom child tags to custom-tag parents in a helpful and meaningful way.

So, if anyone has any thoughts on that (or any of this), I'd be interested in your feedback.

And of course, I encourage you to check out the working examples of this concept at thepointless.com, starting with the book of small potatoes!

Wee!

Wednesday, May 16, 2012

building tables in IE7 with JavaScript

The documentation on this is a little old and hard to find, since IE7 is old and on rapid decline. But, for those still plagued with a significant percentage of IE7 users, please note that building tables in IE7 can require a step not required by other browsers.

We can normally build tables using HTML and omit the tbody tag without issue. Browsers are supposed to assume a single tbody when none is explicitly given. So, we may naturally assume we can do the same using the DOM methods:

var table = document.createElement('table');
var tr = document.createElement('tr');
var td = document.createElement('td');
td.innerHTML = "oh hi.";
tr.appendChild(td);
table.appendChild(tr);
document.body.appendChild(table);

And indeed, this works perfectly in Chrome, Safari, Firefox, and IE8+. However, IE7 silently adds the table to the body, but refuses to draw anything. IE7 fails to assume the tbody in this case. You need to explicitly add it, like so:

var table = document.createElement('table');
var tbody = document.createElement('tbody');
var tr = document.createElement('tr');
var td = document.createElement('td');
td.innerHTML = "oh hi.";
tr.appendChild(td);
tbody.appendChild(tr);
table.appendChild(tbody);
document.body.appendChild(table);

This will correct the issue in IE7 in without impacting other browsers. And, it'll provide a more accurate representation of the table in your script, which does include a tbody, even when not explicitly given.

Friday, March 16, 2012

javascript namespaces

Well, I lied already: JavaScript doesn't really have namespaces — at least not exactly. But, we can fake it quite easily using objects, which readily serve the same purposes:

var com = {};
com.google = {};
com.google.www = {};
com.google.www.search = function(s) {

  // since we're actually working in the context of an object,
  // we can refer to "this" to set static-ish variables, like a search history:
  if (!this.search_history) {
    this.search_history = [];
  }
  this.search_history.push(s);

  // perform the actual "search" ...
  alert("No results for " + s + "! Try searching with svidgen.com instead!");

} // com.google.www.search()


// you can then use "with"
// even though you shouldn't generally be using "with" ...
with (com.google.www) {
  search("for something");
  search("for something else");
}

// we should be able to see the search history in the
// namespace now
alert(com.google.www.search_history.length);

And there you have it. Namespaces in JavaScript.

Saturday, May 21, 2011

small updates

We've made a few small changes in the past few days. Some of them are invisible to most users, backend changes. A few of them are stylistic changes that we feel are steps in the transition to a prettier bookmarking tool.

First, we cleaned up our bookmarks lists a little bit:


As you can see, we added some space between bookmarks, floated the info and edit/save links to the right, and replaced the single-color english links with colorful icon-based links.

  • Green links with pencil icons have already been saved by you: click the pencil to edit the link.
  • Click a heart to add the link. 
  • Click the pencil to add or view comments.
We also simplified our add bookmark dialogue (and fixed a unicode bug):


The top action bar, search bar, and lower action links have been removed. And a cancel link has been added. Much less cluttered than before.

We've got plenty of other updates in queue. But, we're certainly not opposed to taking a detour if you find any bugs or have any great suggestions. And if you like what we've done so far, we'd like to hear about it!