XBLinJS

XBLinJS 0.4.1 is released.

In the unlikely event your browser has SVG support built in, see the SVG Widget demo. Simple, but real.

One of the promises of XBLinJS was that you'd be able to use it for more than just HTML. I have to admit that at the time, I was only about 80% certain that I could do that. But I saw this article, and combined with the recent market successes of Firefox and some personal projects of interest that could be used there, I took a few hours tonight and tried to create an SVG Widget. (Note that the real story with FireFox is they plan to "turn on" the SVG support for everybody in 1.1; it has existed for a while, but in a highly experimental form.)

XBLinJS 0.4 is released now.

The promised "interesting widget" turned out to be a conversion of a Javascript Shell from elsewhere on the net; see the demo page, at the bottom.

The main point of this release, aside from the aforementioned Javascript Console, is the big internal changes in the release. Be sure to read the CHANGELOG.

One of the side effects of this big change is that XBLinJS can now actually be used as a replacement for XBL; see the Advanced Uses page.

I finally have a job, a real job, though I don't start until May 9th. For a while after that I will have an overlap between my real job and my last contract job, but after that, I hope to finally have some time to spend with a clear conscience on my open source projects that I want to work on, especially Iron Lute which has been seriously neglected (though not quite ignored).

There is a very nice Javascript Console available at http://www.squarefree.com/shell/shell.html; I've ported it into XBLinJS to replace the hacky little one I had written. I've tweaked it up a bit and also removed a little bit of functionality; in particular you can't start up the Console from a bookmarklet in the context of the original page, and it is easier to create subclasses with customized shell commands and keyboard shortcuts.

This is in CVS, though I have not tested it in IE, which typically means it won't work there yet.

During a bit of development downtime here, I've been working on making XBLinJS work on any ol' DOM nodes, not just HTML ones. Which, most notably today, means that you can in theory use XBLinJS as a drop-in replacement for the actual, factual XBL. It also means it can be used with other document structures that use DOM and the same basic event structure, like perhaps SVG someday. If we're extra good developers, we may someday see widgets that successfully integrate both XUL and SVG at the same time. Maybe even cross-browser...? Please?

Features are always in flux until such time as the release occurs, but here is the current plan for 0.4:

• XBLinJS currently is built on the assumption that if node is a Javascript-reflected DOM node, node.setAttribute(name, value) is the same as node[name] = value. Nope. I thought I was setting up a system whereby you could always say blah.setAttribute(name, value) and it would Just Work whether or not blah was a node or a Widget. Guess not.One way or another, I intend to resolve this in 0.4. I need to research what browsers do with what elements, with what attributes, and figure out what to do. The good news is that much of that should be automatable, the bad news is that it could produce some huge data files, the good news (again) is that huge data files are better than crashing Javascript. A pity it isn't this easy.Egregious example: In IE, node.style is a complicated object, and at least in my copy of IE, node.style = "background-color: #FFFFFF"; doesn't work. (I qualify that because it either worked for other people, or worked in past versions of IE, but it definately does not work for me.) You have to set the attributes in Javascript directly: node.style.backgroundColor = "#FFFFFF";. In Mozilla, you can use direct .style access just fine. I can flatten this difference out pretty easily, but if it gets much more complicated than that, things could get interesting.
• There are of course other widgets that can be included. A version of the drop-down widget that works in both IE and Mozilla should be included as I'm working on that right now. I might put out a simple ButtonWidget, just because I keep using buttons and it'd be nice to have an easy ButtonWidget for use in .content specifications. Depending on time, a Rich Text editor widget may get included, which could be interesting. (I'm actually converting somebody else's rich text widget, and it's serving as a good example of how XBLinJS can in theory provide a single unifying framework for a lot of extant Javascript libraries for various capabilities that currently do not integrate well.) I think that with either of those two, maybe even both, it'll start turning some heads on the demo page.
• Event handling at the moment is questionable. I had to get wacky to work with IE 6, and I'm not yet convinced things will work across frames like they are supposed to, or that widgets can attach to other widget's events like they are supposed to. Simple cases work. That will be better tested in 0.4.
• Finally, I intend to have some sort of tutorial up, which will also serve as a better explanation of what XBLinJS is if you don't already know what XBL is. I haven't worried too much about that up to this point because the library wasn't necessarily ready for that bunch of people, but I think it is getting there.

XBLinJS version 0.3 is released; get it at SourceForge.

A demo page is available, though at the moment I think it will still only impress serious Javascript programmers.

For people who don't really care about XBLinJS per se, but do care about web development issues, you may wish to check out my dangerously-close-to-rant statements about my experiences with Mozilla's technologies. (The only things saving them from being a rant is that I propose that XBLinJS, or at least something like it, is a solution to the issues I raise; I tend to think of rants as things with little or no constructive value.) This is why an XBLinJS release announcement is posted also on my blog's front page.

JSON is pretty cool for what it is; in a mix of dynamic languages where Javascript (most likely in a browser) is involved it may not be a bad choice. It's even a great choice if you're firing structured data back and forth from Javascript and something else.

But for it's "core competency" of interfacing with Javascript, I've found there is a better approach, though it may integrate JSON into the mix. Code is data and data is code; instead of transferring data, transfer code to replicate structures. There seems to me to be two basic techniques, each useful in their own way.

I've released XBLinJS 0.2, which includes some example widgets and much better documentation.