As you may or may not have seen by now, we’ve released the new Yahoo! Widgets/Konfabulator 4.5. This version was a major undertaking, and there are four particularly cool and important features in it for developers.

• HTML
• Flash
• Full W3C DOM
• Fine-grained Security

HTM… something or other

Yes, you can now embed HTML into your Widget, thanks to the magic of WebKit. If you wanted, you could pretty much write all of your Widget in HTML. You can also just grab some AJAX code off the web and with a few modifications get it running inside Konfabulator. Your HTML code has access to all the features of the Konfabulator engine if it’s all contained in your Widget bundle. If you are accessing remote sites or scripts, you are restricted to the typical web sandbox. Just add a attribute to your Widget and point it at an HTML file and you’re off! Not only can the HTML view see Konfabulator, but Konfabulator has access to the innards of the web view itself via the ‘base’ attribute of the web object.

Flash! Ahh-Ahhhhhhhhh!

After HTML, there’s Flash. Like HTML, you can deploy a Flash Widget in Konfabulator. If Flash is your favorite language, have at it. Unlike HTML though, Flash cannot access Konfabulator itself, but Flash does provide a number of its own useful functions to get things done. In theory you could write yourself a video-based-community-type Widget now

Both HTML and Flash run just as any other view inside your Widget. You can inter-mix them with other Konfabulator objects and control their opacity and rotation, as you’d expect.

Wait? What are you saying?

I’m sure many of you might be asking whether this means we are favoring HTML or Flash for writing Widgets. It does not. We are merely offering them as alternatives. Many developers want to deploy something in HTML to allow them to run a Widget on the Web. Now they can also get a desktop presence in Konfabulator without having to rewrite the code. The same thing applies to Flash. Would I recommend this way of writing Widgets for someone just starting to use HTML? Probably not. It’s way too heavy for most Widget needs - it will consume more resources for not a lot more bang on average. If you don’t require features specific to HTML, or you aren’t porting AJAX code, I still recommend you stick to the native language.

DOM, da-DOM DOM!

Another big change is the introduction of the full DOM. This means the entire structure of a Widget is now accessible via DOM APIs. You can even run an XPath expression across your Widget. Rob does this to find all elements with tooltips in one of his Widgets, for example. You can locate all your Windows simply by saying document.evaluate( “/widget/window” ). Simple. As you are developing, you can also look at your DOM by merely executing document.toXML() in the debug window to see if things are as you expect them to be.

Fine-Grained Security

The new release has an expanded Security Block. It’s enforced if your Widget has a minimum version of 4.5 or later. It lets you specify the things your Widget might want to have access to, such as the file system, http, etc. This information is shown to the user in the new security dialogs. The dialog can now be expanded to display the information in (hopefully) human-readable form.

If your Widget ventures beyond the contract of your security block, an alert is presented and your Widget is terminated with extreme prejudice.

Under The Hood

The DOM really caused us to change our entire infrastructure. This might cause some compatibility issues with some Widgets. For example, one of our own Widgets had a property of an object called tagName. This is unfortunately an official property of a DOMElement these days, and so there was a conflict and the Widget had to be fixed. So as you try your Widgets out on the new engine, be on the lookout for issues like that.

We also have a new JS engine in this release. It’s the first time we’ve upgraded SpiderMonkey since the original Konfabulator release, as far as I know. Like the DOM, this might also cause some subtle issues for your Widgets. One example we ran into with two Widgets in particular is that there’s a class called Block in the new JS, and these two Widgets tried to create their own variables called Block.

We ran about 1000 of the most popular and recently-added Widgets when we tested this version of the product. We fixed everything we found, and when we found something we couldn’t fix (like the issues mentioned above) we reached out to the developer of the Widget to tell them what needed to be changed so they could resubmit their Widget with the fix so that users could hopefully get uninterrupted service.

The good thing about this infrastructure change is that we now have an excellent, solid foundation on which to build. We can add features faster now than ever before. For example, our new Display object took me literally 20 minutes to add. Granted, it was a simple feature, but it would have taken hours previously. This is going to make a huge difference for us. It also means we can start to implement things we never could before.

With our infrastructure out of the way, the next releases are going to focus on features to allow developers to build some amazing Widgets faster and easier than you could in the past.

Bonus!

One other thing: there’s a rudimentary debugger accessible from the debug window now. It’s not 100%, but it’s a start. Eventually there’ll be a UI for it. /help should let you know what the commands are… it’s somewhat akin to gdb. I’ll likely post another entry explaining how to use it.

Until then, enjoy the new features!