I have an Actionscript 3 book lined up to tackle at some point, but generally my interaction with Actionscript is having to modify someone else’s SWF, most commonly old code from the 1.0 days. When I open one of these source files it sometimes takes time to even figure out where the code is. When I do find it, it’s not obvious when this code executes and in what scope. The object model of a Flash movie may not be much more complex than the browser DOM, but they’re quite different. I think part of my problem is that the structure of a movie (and the IDE navigation) is still foreign to me. The programmer in me wants to dig in with a spec in hand, and that often works with the projects I have to work on, but it would probably benefit me greatly to spend some time doing the boring beginner Flash tutorials.
Month: July 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?