Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Firefox 3 Arrays: No, You're Not Insane

I just spent 20 minutes in IRC with Wolfram staring down one of those situations where you keep swearing under your breath "println isn't broken....println isn't broken....println is NOT broken".

Catch this fun gem from FF3b2:


>>> typeof []
"object"
>>> var a = [];
>>> var b = new Array();
>>> a.constructor == b.constructor
false
>>> c = [];
[]
>>> c.constructor == a.constructor
true
>>> d = new Array();
[]
>>> b.constructor == d.constructor;
true
>>> b.constructor == a.constructor;
false

WTF?

Extending dojo.query()

As you probably know, Dojo is layered, extensible, and our philosophy of "build with, not on" means that we give you all of the same tools and extension points that we use in our code for use by your app.

Dojo's got 2 "sides", namely the bits that make working with the DOM better and the bits that make writing idiomatic JavaScript faster and easier. Where the package and language utilities enable you to extend and modularize your JavaScript work, the widget, behavior, and query systems make working with the DOM similarly extensible. Writing widgets and behaviors is well-understood in the Dojo community, but extending the results of a dojo.query() call haven't seen as much attention. To rectify that, here's the two-minute version of how to write your own dojo.query() extension.

Step 1: grok dojo.NodeList

dojo.NodeList is the Array subclass which all dojo.query() calls return an instance of. Therefore, to extend the results of a dojo.query(), we really want to extend the dojo.NodeList class. Both dojo.query() and dojo.NodeList are available as soon as dojo.js is included in your page.

Step 2: extend NodeList the old-skool way

Instances of dojo.NodeList pick up properties from the prototype object of the dojo.NodeList class. Lets add an inspect() method which logs out the innerHTML of the nodes in the list to the Firebug console:


dojo.NodeList.prototype.inspect = function(){
    this.forEach("console.debug(item.innerHTML);");
    return this;
}

// now we can call it: dojo.query("#container > p").inspect();

// or via a direct instance: var nl = new dojo.NodeList(dojo.byId("container"), document.body); nl.inspect();

A couple of small things to note:

Step 3: modernize and package it up

We want to be able to use dojo.require() to manage this module, so we'll assume that our Acme module lives in the acme/ directly which is a peer of the dojo/ and dijit/ directories from the Dojo distribution.

Lets add a provide() so that we can require() our module and use a bit of Dojo's language tools to extend dojo.NodeList more tersely:


// this file located in:
//    acme/ext-dojo/NodeList.js

dojo.provide("acme.ext-dojo.NodeList"); // require() statements go here

dojo.extend(dojo.NodeList, { inspect: function(){ this.forEach("console.debug(item.innerHTML);"); return this; }, ... });

We can now include this module at runtime via dojo.require("acme.ext-dojo.NodeList") and use it as a part of a build which will significantly improve the performance of the application which needs the file. Dojo's infrastructure makes doing what's easy pay off in the long run for your application.

Note that the file name is acme/ext-dojo/NodeList.js, which might seem a bit odd at first glance, but the intermediate "ext-dojo" directory makes it blindingly obvious to anyone who sees the require() statement what's going on. You can't dot-access a variable named "ext-dojo", so we know that this isn't a "normal" module. Instead, it's an extension, which extends the dojo.NodeList class. Subclassing is often more trouble than it's worth, and discouraging people from extending the Dojo core objects seems lame. Instead, we use this convention to make it easy to understand what's happening when you look at any given Dojo project.

And that's it! Writing powerful extensions for query results is easy, and because your project is using Dojo, you can structure your extension as a module and gain the benefits of optimization for deployment via the Dojo build system and the ease of use that comes from not having to worry about what order you're including your files in. It's good to be using a tool that you can build with, not just on.

Big Questions On IE8's Big Progress

So IE is the first browser out of the gate to do something sane about rendering engine locking to content…and good on them for it.

Now we need to know a couple more details to see if it’s going to have real legs:

These questions need to be answered, and soon. If the IE team has just replaced one scarce resource for another, we’re not much better off over the long haul. It’s great news that the IE team is really implementing the “renderer selection switch” which many of us have dreamed of for so long…but having it continue to be global to the page or in other ways encourage contention on yet another single element in the document wouldn’t be stepping forward enough.

Roxer Goes Live!

So once upon a time, back when I had a "real" job, I used to do security (specifically webappsec) for a living. One of the shining lights in that world for a long time has been Jeremiah Grossman, and as I moved out to the Bay Area, I was lucky enough to meet him in person. We've kept up here and there, and while his company has grown at a furious rate, he's somehow found time to continue to publish important original research, travel more than any human really should, and generally kick ass....oh...and build an awesome Dojo-based product on the side.

Jeremiah and Lex must really not sleep, 'cause their new Roxer app makes me all giddy to play with. Yes, yes, you should separate style from content...oh fuck it all. When it's this easy and fun to build a web page, who cares? I loathe wikis, mostly because traditional wikis try to be "half-pregnant" about how what you write gets displayed. Roxer solves that essential failure in one easy step, and makes it enjoyable to boot.

Think of it as the anti-blogging tool. It's not set up with expectations that you'll be doing this or that with it, it's there for you to do stuff. I literally cannot wait until it's hooked up with some dojox.data love to access web services and the like. It's not a programming platform, and maybe that's what's great about it. Can't wait to see how it evolves and how they'll open up the (apparently pluggable?) content type system.

Great work guys!

Dojo Needs Your Projector (and room, and network, and...)! (updated)

The votes have just come in, and the next set of Dojo Developer Days will be in the San Francisco Bay Area Feb 7-8 or 8-9, but as of now we don't have a venue.

In years past, IBM and AOL have graciously hosted these events, provided network connections and projectors, and generally made us feel at home.

This is where you come in! If you're working at a Bay Area company who is using or otherwise benefits from the work we're doing in Dojo and can spare a room for 20-30 people (with working network) for a couple of days, this is a great chance for you to meet the community of folks building the toolkit, put faces to names, and do your bit to help ensure that Dojo continues to succeed.

If you can spare some space on either of those sets of dates (Feb 7-8 or 8-9), please send me mail.

Update: Our friends at Google and Mozilla have both generously offered their spaces, and so it looks the Feb DDD will be in Mt View. I'll update this post once more once dates and locations are final. Thanks Google/Mozilla!

Update 2: Thanks to Google, Dojo Dev Day will be Feb 7-8th at Google's Mt. View campus. The agenda is being constructed here, and we can use all the help and feedback we can get on what to discuss, particularly if you plan on attending. It's always hard trying to address every concern at these meetings, so now's the time to make your voice heard! We'll be posting logistics details and the RSVP address to that page in the next couple of days.

This DDD is going to rock! Can't wait to see everyone there.

Older Posts

Newer Posts