Been bitten by Dojo bugs or have feature requests? Going to a conference any time in the next month or so? Odds are you'll be able to get your very own pound of flesh. The rundown:
- AjaxSeminar (yesterday): Ok, so not really helpful...but it did happen! And no, I don't have the talk text cleaned up sufficiently that I feel comfortable posting it yet...but I promise I will soon.
- The Ajax Experience (May 10-12): This one is a doozy. I'm signed up to blither on for 3 full hours. If you can't get your Dojo question answered in that time, then something is seriously wrong. Also, tons of other Dojo contributors and users will be presenting. One of the tracks is very nearly "Dojo all the time". Super rad.
- Dojo Developer Day (May 13th): This is our first foray, aside from the various "dojo.dinner"s, at getting everyone in one room to discuss, hack, and otherwise move Dojo forward. Big props to AOL for generously donating a facility and food. It wouldn't have happened if they hadn't stepped up on short notice.
- XTech Ajax Day (May 16th): Ajax in Amsterdam....w00t! Also, don't miss the scheduled Bar Camp happening directly after the conference. A good hack should be had by all.
- JavaOne (our talk on the 18th): I'd love to link to the details of the presentation I'll be giving with Greg Murray, but the JavaOne website is so nearly useless as to make me wonder if they actually paid people to put it together...I think I know someplace they could get a kickass Wiki instead...
- USENIX 2006 (May 31st): This one will be an all-day tutorial covering responsive webapp technologies, soup-to-nuts. Not the traditional venue for this kind of stuff, so I'll be very interested to see if and/or how it goes over.
That people keep asking us to talk about Dojo and are using it to build truly awesome apps is humbling. I always learn so much by talking to people at conferences, and I'm looking forward to doing that a lot in the next month.
See you there, wherever "there" may be!
Apparently a new XUL app called "ajaxWrite" was just launched. I think this thing is going to be my poster child for what's wrong with single-renderer markup languages from now on. It might be a fine app, I haven't used it long enough to have a strong opinion, but its marketing is truly reprehensible. I'm sure someone assured Michael Robertson that they couldn't launch a web-ish app without tacking the word "ajax" in the title and the folks with sense were shouted down. A pity.
This thing is appropriating the necessarily amorphous terminology of "Ajax" for an implementation that is directly at odds with why Ajax is an important technology. A XUL app being billed as "Ajax" is just as laughable as a Flex or XAML app suddenly growing the same moniker. That it's Mozilla's walled-garden language doesn't really excuse the gaffe.
But, I hear you ask, aren't Firefox/MoFo our only hope?
Perhaps, but only insofar as Firefox is a good HTML and SVG renderer. XUL is not a standard. No one else implements it, and it's not likley that anyone else ever will. And that's OK. What's not OK is when these walled-garden-web technologies start getting passed off as somehow being more open, more cost-lowering than they really are. The unspoken promise of Ajax is that it makes cross-browser apps that are more responsive possible. Stunts like "ajaxWrite" not only break the contract locally, they start to cast aspersions on the efforts of scripters everywhere who are dedicated to an open application platform.
The web has succeeded in part because in trade for control over UIs, businesses gained the ability to deploy to everyone everywhere. In a world where the web is how business gets done, "cross platform" really means "cross browser". Single-render apps are bad for the web and bad business. What (aside from a larger potential to succeed as an app) would have the functional "open vs. closed" difference been if this thing had been written in Flex? Or XAML? All of these platforms are highly capable. More capable than the Open Web is today, but they are not the Open Web. The term "Ajax" is a proxy and an ambassador for Open Web technologies today. The message that "javascript works now" means that the same kinds of universal access to information that the static web made possible is now available to application authors. But not if shameless marketing shills co-opt the term to mean something that's harmful to the web. "ajaxWrite" is just such an abomination.
So I'm calling on Michael Robertson to do the right thing and rename this product. A quick check shows "xulwrite.com" as still being available. There's still time to change course. Still time to avoid giving the Open Web the bird.
What follows is a janky hack. If you do not have the stomach for things that are useful in the real world, please stop reading here. "But it's not standards compliant!" comments will receive no sympathy. Validatorians, you've been warned.
If you're still reading, you're probably aware of the crappy primitives that the W3C has bestowed us with for scripting arbitrary collections of nodes. Things like Microsoft's HTC and Mozilla's XBL allow for browser-specific markup-upgrade paths but these aren't really feasible in the "real world" since they require lots of code branching and different semantics for attaching a behavior. Tools only succeed where they lower our costs. This is why Dojo and Behavior (and even netWindows, back in The Day) work so hard to provide a portable basis for applying behaviors.
Given that the W3C has f'd us in the ear and that the browser manufacturers can't get it together enough to come up with one non-standard way to apply scripts to collections of nodes, we're back to iteration. Updating the collection to which a behavior should be applied when a DOM is updated presents a particular challenge. IE doesn't throw mutation events for DOM changes nor does it provide client-side XSLT. Both hands our tied behind our back.
So we need something else. document.getElementsByName() would work quite well if the browsers paid attention to name attributes for any element. Alas, they don't. Which brings us back to the one fast query browsers will support on any element: document.getElementById(). With it we can build a fast, efficient query function for every browser but Safari:
function elementsById(id){
var nodes = [];
var tmpNode = document.getElementById(id);
while(tmpNode){
nodes.push(tmpNode);
tmpNode.id = "";
tmpNode = document.getElementById(id);
}
for(var x=0; x<nodes .length; x++){
nodes[x].id = id;
}
return nodes;
}
A permutation of this that caches the results and does not set the IDs back to the original value allows re-runs of the function to determine if new elements have been added to the group and/or if a node should be removed:
var groupCache = {};
function elementsById(id){
if(!groupCache[id]){
groupCache[id] = [];
}
var nodes = groupCache[id];
for(var x=0; x<nodes .length; x++){
if(nodes[x].id != ""){
nodes.splice(x, 1);
x--;
}
}
var tmpNode = document.getElementById(id);
while(tmpNode){
nodes.push(tmpNode);
tmpNode.id = "";
tmpNode = document.getElementById(id);
}
return nodes;
}
Obviously, getting a list of added/removed nodes from this function might be preferable to receiving the full list, but I'll leave a better API for this as an exercise. Safari is the only browser which appears to not support this method of constructing queries, but we can fall back to iteration. It's certainly not going to be any slower than current methods. The hack is also made somewhat less useful by the W3C's bone-headed decision to limit elements to a single ID.
The jury is still out as to whether or not this is going to prove useful, but I can already imagine it being an optional optimization for Dojo users looking to make their apps go like hell on pages with complex DOMs.
If only it weren't necessary.
Update: After reading much WebCore source code, I'm not aware of a way to make elementsById() work on the current Safari. There is good news, however. On the latest Konqueror release and nightly Safari builds this hack works flawlessly. In short, this will very soon the the most widely available, fastest DOM query method. More news regarding elementsById() to follow shortly.
My last attempt to rebuild my mail client of choice on the old Powerbook was something short of thrilling. It was with some trepidation that I moved my data to the new MacBook and attempted to fire up kmail. Thanks to the magic of rosetta, it worked. I was, in a word, stunned.
But I just can't leave well enough alone. Having read encouraging notes about fink on 10.4+Intel, I backed up my data and /sw directory plunged in, foolishness first.
Unlike my previous attempt at building KMail, the process was absolutely painless. Not only is the "ssl vs. non-ssl" war apparently over, dependencies satisfied themselves in the right order and the only input needed from me was the occasional mirror selection. An hour into the process things were well enough under way that I went to bed and just left the build running. When I came back to the terminal this morning, lo-and-behold, it had built cleanly. On firing it up, i can attest to the difference that native compilation makes. My mail has never been so speedy. As someone who lives-and-dies by the mailing traffic that flows into my laptop, all of this makes me one extra-happy camper.
The fink folks (particularly Benjamin Reed, the KDE maintainer) have clearly spent some quality time polishing the dependency code since last I had to preform this operation. My sincerest thanks go to them for the painless install this go 'round. Not only do I have the latest-and-greatest KDE available, I now feel comfortable recommending fink again to folks who want a better alternative to Mail.app.
I tend not to take a lot of pictures at conferences. Or blog much when I'm at them. In fact, it's usually not discernible that I'm at a conference except that I'm not doing all the other stuff I normally do. I'm not sure why. I always bring a camera (sometimes more than one), I just don't use it.
That's a long way of saying that FOSDEM and ETech were wonderful, but I don't have a lot of photographic evidence to support that assertion or even to prove that I was really there. It might be to the best though. My ETech demo crashed-and-burned thanks to my foolish assumption that we'd have a working network. Lesson learned.
As this was my first ETech, I was (and still am) in awe of the people I met and how they would even actually talk to me if approached! Whether or not they'll talk to me after having met me is another question entirely. At ETech I got to meet some users of Dojo and folks who are implementing Comet apps small and large. It drove home my suspicion that we do need a new name; one that will let us discuss old concepts with people who may not yet be familiar with them. The sheer number of "and our product has been doing that since X" replies to one of my previous posts also makes the point better than I ever could. Comet is useful, the solutions to the technical problems are becoming more widely distributed, and a set of patterns for how and when to use Comet will soon emerge.
On that front, Douglas Crockford's new JSONRequest proposal was announced. Maddeningly, there's still no link to the various ongoing conversations about it from the document itself, but it does seem worthy of discussion. The provision for duplex communication is particularly interest as it would provide the first known way to do cross-domain Comet without resorting to Flash. James Burke, Dojo's newest commiter, has great comments on the proposal.
Something I hope to come back to soon is something Bruce Sterling mentioned during his keynote at ETech: that augmenting human intelligence is as better goal than replacing it and that language has been our stumbling block to describing what we should be working toward. My recent introduction by Brad to Doug Engelbart's seminal work and the realization that Jot is little more than a conceptual descendant of Augment delivered via the web has made these words ring in my head that much more acutely.
Older Posts
Newer Posts