Tuesday, February 12th, 2008

Dojo Roundup: A/V, Animation, and a lot more

Category: Dojo

A lot of news came together at the Dojo Developer Days event.

Below is my meta-roundup based on Alex’s wrapup, and other news.


Eugene Lazutkin (SitePen) has been a busy man. His impressive work on dojox.gfx, dojox.gfx3d, and dojox.charting made Dojo 1.0 the best tool around for portably drawing vector graphics in a browser without plugins, and for 1.1 he’s updating dojox.gfx to include animations, based loosely on easy-to-use Dojo Core animation APIs. Shapes, transformations, colors, and other dojox.gfx properties can be animated, chained, and eased on any 2D drawing object in Dojo 1.1, all using the high-performance, single-timer animation system from Dojo Core.

Speaking of animations, Peter Higgins gave us a tour of some of the great components he’s been whipping up now that Robert Penner’s awesome easing function set has landed under CLA in dojox.fx.easing. Of course, you can plug these great easing functions into any Dojo animation, but examples like dojo.moj.oe really give them life.

Adobe AIR and Dojo

Rob Christensen and another of his colleagues from Adobe were kind enough to give us a thorough walk-through of Adobe AIR as well as showing off Dojo 1.1’s comprehensive support for AIR. This work was done by SitePen and Chris Barber with financial support from Adobe. Not only does the Dojo package system work as expected in AIR, new dojox.storage providers for AIR give a simpler interface onto AIR’s database, including for encrypted data. The demo showing a full Dojo-based application inside of AIR for quickly taking notes started to show the potential.


  • DojoX A/V: Starts as a way to embed flash and quicktime, but will also have a Jukebox and a Tuner. The bigger news here is that there is the beginnings of a partial port of some of the Dojo base to AS2 (including console pass-throughs, the event system (i.e. connect), and a number of the lang constructs) in order to support some of the A/V stuff well, all compiled using MTASC.
  • CSS Selectors: a new tutorial on how to use dojo.query to get fast selection fun. Also, Dojo 1.1 already has a patch that uses the new WebKit native selectors
  • Crypto: Blowfish now performs about 4 times faster than it used to
  • Charting: curves… mmm
  • DojoX Sketch: We reported about the Comet version
  • Color: In addition to adding conversion methods to HSL, HSV, CMY and CMYK, there is a Generator that allows you to create a palette of colors based on several well-known generation rules
  • Flash storage: Brad Neuberg started hacking and found that Adobe has fixed the serialization problems with Flash’s ExternalInterface, so a clean up is coming for dojox.flash, and Dojo Offline
  • A next-gen JSON-RPC for Dojo which supports pluggable back-ends

Posted by Dion Almaer at 8:01 am

3.8 rating from 34 votes


Comments feed TrackBack URI

Definitely some cool technology. I really wish that the excellent vector graphics and charting libraries could be used with other frameworks though ;-).

Comment by Andy Kant — February 12, 2008

Andy, without too much work, they could be. They don’t rely on that much Dojo code currently (Dojo base, 23K compress, gzipped), and someone could of course remove the dependencies that are there. You could of course use Dojo and another toolkit in the same app in most cases, though you do spend an extra 23K.

From our perspective, writing a neutral compatibility layer would probably take almost the same amount of code. We could define some standard interfaces I suppose, but at what point is it just easier to rip out what you don’t need and port it, etc.?

Comment by Dylan Schiemann — February 12, 2008

I did a scan of all Dojo Core usage in the dojox.gfx package and have been working on a slim Mootools bridge to see if I can get it to work. There are Mootools equivalents for most of the calls but there are some features that don’t really have any simple equivalents (like dojo.declare and dojo.Color) that need to get included so I’m not sure that its going to gain much in the end anyways. Just wishful thinking I suppose.

Comment by Andy Kant — February 12, 2008

Any reason you might feel compelled to just not use the Dojo core for loading it up and using it? It’s not a knock on Moo or a lack of desire to see a port, but just from an expediency standpoint I would think that it wouldn’t be too hard (and shouldn’t create a major conflict) to simply load the Dojo core and consume (philosophy aside)? I suppose that would depend on how anal (no offense intended) you might want to be about downloads…

Comment by Tom Trenka — February 12, 2008

@Andy: dojo.Color you could probably grab wholesale, and dojo.declare is just a convenient wrapper for inheritance/mixins/instantiations that can be unrolled or mimiced-ed pretty easily.

@Tom: while I’d personally love everyone to use Dojo Core, I think it would be pretty cool to see other toolkits be able to use some of the great stuff in DojoX such as gfx, charting, and grid.

Comment by Dylan Schiemann — February 12, 2008

@Dylan: I would too, I was just suggesting a quick fix for the short term without having to dive into the mechanics of dojo.declare :)

Comment by Tom Trenka — February 12, 2008

I don’t really have any reasons other than wanting to avoid duplicate functionality being downloaded. The other thing I want to avoid is the dynamic package downloading system, but that could be solved by creating a custom build.

Comment by Andy Kant — February 12, 2008

Just for comparison, the bridge I have written so far (for dojox.gfx only) is 2kb compressed/gzipped, missing dojo.declare/Color/connect functionality.

Comment by Andy Kant — February 12, 2008

@Andy: understood. If you need any help or direction, feel free to ping us over on the dojo forums (http://dojotoolkit.org/forums) and either Eugene or I can point you in the right direction. One of the key things is the conditional loads for the various renderers, and I’m not sure how you’d want to do that without asking people to include a specific script tag (the package system handles that for us).

Comment by Tom Trenka — February 12, 2008

I have support for require/requireIf in the bridge, but will probably look into a setting for bypassing that. If I have any more questions I will post on the dojo forums, thank you.

Comment by Andy Kant — February 13, 2008

Leave a comment

You must be logged in to post a comment.