16 2007

Thoughts on a Javascript “validator”

(X)HTML and CSS have their own validators, but we need one for Javascript as well. JSLint could be part of it, but what I’m imagining would flag the use of “native” objects/interfaces not defined by W3C or ECMA standards. E.g., document.layers or window.ActiveXObject.

The hard part in doing this is finding a full Javascript interpreter with W3C DOM interfaces, but without the proprietary features that browsers have to support to remain usable on the web. A couple ways come to mind:

1. Rhino

John Resig has just implemented “window” for the Javascript interpreter Rhino, which, supposedly, is already based strictly on the ECMAscript standards. The short term goal of his script was to give Rhino enough of a browser interface to pass jQuery’s test suite, but the code could be branched to implement all current W3C DOM recommendations (and none of the proprietary interfaces). A Java app would set up Rhino, run John’s script, then run your script and simply report any errors.

2. A stricter browser

Most modern browsers are pretty malleable as far as letting user code clobber native functions/objects; in fact it’s a real problem. But this is convenient if you want to, say, overwrite all the proprietary features with your own code! With a whitelist in hand, you could use for-in loops to sniff out non-standard functions/properties and either delete or overwrite them with functions of your choice.

The advantage of the browser solution is that you could still provide the non-standard features (so the script would continue to run) while logging them. Using closures you could, in theory, “wrap” each non-standard function so that each of its calls would also call your logging function before returning the expected value. A crude example:

// may fail spectacularly
var _parseInt = window.parseInt;
window.parseInt = function (str) {
    alert('parseInt was called.');
    return _parseInt(str);
};
parseInt('2');

In practice, you’ll be at the mercy of the browser to allow native functions to be stored in variables like this. Sometimes it works, sometimes not. As for properties, you may be able to similarly log their usage with Javascript’s relatively new getters and setters.

So any idea where to get such a whitelist?

One Comment on “Thoughts on a Javascript “validator””

  1. About intercepting method calls in JS using closures: You can store the overwritten object in a closure, that way its possible to intercept is as often as you like. The typical pattern is this:


    (function() {
    var reference = window.parseInt;
    window.parseInt = function() {
    alert("parseInt was called.");
    return reference.apply(this, arguments);
    };
    })();

    Using apply(this,arguments) makes the interceptor much less obtrusive, your implementation would drop all additional arguments passed to parseInt.

    I’m currently evaluating jQuery on the serverside, to replace view techonologies as JSP at first, eventually to build a complete web framework (focus on web ui, no backend stuff). Quite a bunch of jQuery plugins could be useful on the server too, and in that case a validation framework like you propose would be quite useful.

Leave a Reply

Elements allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>