JASPA.DOM is now an open source project on SourceForge
I’ve decided to set up an open source project for the jaspa.dom package; it is to be found on SourceForge.
http://sourceforge.net/projects/jaspa-dom. It’s my first attempt at anything like this, so I’m bumbling around a bit, but the downloads are there and the CVS repository is also up and running. Any developers who are serious about helping develop this API should put a request to join the project on SourceForge.
What?
The main JASPA project is a platform which allows you to write a grown up language (practically identitcal to AS3), and have it compiled into regular JavaScript. If you don’t know why this is really cool, then you may as well stop reading now.
japsa.dom is the name of the DOM scripting package which allows you to compile browser-based code with JASPA. It’s a completely separate project, and is quite possibly larger and more complex. It is certainly less mature. The JASPA compiler is behaving pretty well, but the API code base is very much incomplete.
Language vs API
The thing about JavaScript is that it’s pretty much an empty shell. You can’t actually do anything without an API of some sort. Your web browser provides one such interface – it lets you access window, and document and generally lets you do stuff. Likewise the Flash Player provides MovieClip et al.
JASPA is API-neutral. That is to say that it just compiles code, but has no idea what document is until you tell it. This is actually quite easy, because JASPA supports native class definitions, so you can create a sort of class template and state that there’s an object called document which has a property called body, and so on. In ActionScript these are known as intrinsic classes. In JASPA they are called native classes – (native is a reserved word in ECMAScript, so I thought I’d play ball).
Anyhow, this is all very well for Flash, because it knows there’s going to be a MovieClip. In fact it’s all very well for most environments that support JavaScript – except of course web browsers. You can’t just call document.addEventListener, because our old friend MSIE doesn’t have such a thing. It’s known as attachEvent instead, and it’s not just a naming issue either – the differences run deep, but that’s another blog.
A poor solution would be to create a loosely typed global object. If the Window class was declared dynamic you could merrily type anything you wanted. The application would compile just fine, and if you’re code is flawless your app would run fine too. But if you’re going to do this then there’s little point in using JASPA. You won’t get code hints in your “as” editor, and you won’t benefit from the compiler picking up your mistakes.
Total abstraction
A better solution would be to take this opportunity to build a complete abstraction layer. Wouldn’t it be great if you only ever had to call the standard API functions, just like in ActionScript, and on any browser your code would just work. That, in a nutshell, is the purpose of the jaspa.dom package. To achieve this, the API consists of wrapper classes for practically every object in the browser environment. When writing your JAS code you will be largely unaware of this.
Some parts of the API go even further than just abstract the objects. due to the huge differences between the IE and the standard event model this is completely abstracted too. That is to say that event flow is emulated so the standard model works identically cross-browser.
As this article has become rather long, I’ll go into some of the abstraction techniques in future posts.