As one blogger has put it: “we cannot avoid testing javascript anymore”…especially when it comes to testing sophisticated client-side web apps that integrate with our servers via various APIs. As we begin to build more complex interactive functionality and web applications, making sure that our JS code is working correctly becomes central to our QA process. Tools like Drupal’s SimpleTest implementation are great for unit testing our server-side code and basic input-output expectations, but effective testing of advanced client-side functionality requires a robust, fast, JavaScript based solution.

Following up on our recent post introducing the Backbone module for Drupal, this post will cover how to test Drupal JS apps using the QUnit module. We’ve chosen QUnit in large part because its GPL lisence makes it a good fit for Drupal development, and the QUnit module is a mature, well designed implementation.

I am tremendously, overwhelmingly, and kind of absurdly excited to announce the alpha release of the new Backbone module for Drupal. Why? Because the oddball combination of new-kid-on-the-block Backbone with venerable-ol'-stallwart CMS Drupal is actually a suprisingly well matched and powerful one.

With Backbone.js, Drupal is no longer a drag when making dynamic, JS-based functionality...in fact, it's kind of awesome. Backbone works by creating lightweight model objects in the browser that are then easily bound to the vast array of interaction events and views using a flexible client-side templating system. Drupal is a great tool for producing the sort of structured JSON data that Backbone consumes: we get the full power of Drupal's Field API and content administration tools on the server side, but don't have to deal (much) with Drupal's theme layer and rendering stack, getting Backbone's lightweight awesomeness in our UI code. It's kind of a marriage made in web development heaven.

The Backbone module for Drupal provides a foundation for building Backbone apps within Drupal sites. Following the Backbone philosophy, it extends Backbone's Model, Collection and View objects to work with Drupal nodes, views and templates, respectively, via the Services module's REST server functionality. While a few default views and example templates are also included, the rest is left up you, the developer, to build on as you please.

While working on a recent project involving an embeddable JavaScript widget, I discovered a lot of useful techniques for creating widgets and for working with JavaScript in general. One of the latter is to use Douglas Crockford's JSLint to syntax- and quality-check your code.

Without a tool like JSLint, the only way to really check your code for syntax errors is to run it in every browser you plan to support.

Jeff Atwood has an interesting discussion of the HttpOnly flag and how it can help protect your site from cross-site scripting attacks. For those hoping for a quicker rundown than Jeff's excellent explanation: XSS attacks are based upon the injection of third-party Javascript into your site. This usually happens via a comment or search form — really, it can be anything that accepts user input that is then rendered as part of the site's HTML. If that user input isn't properly sanitized it can trick other users' browsers into running the attacker's Javascript as if it were part of your site.

Once that happens the attacker has access to all sorts of goodies. The most valuable is the document.cookie object, which will generally contain the string that identifies your session to the site. They'll shuttle its contents off to their own server, and with your session in hand they can pretend to be you (at least until the session expires), doing whatever sorts of authenticated tasks you have access to on the site.

The HttpOnly flag tells most modern browsers that scripts shouldn't be allowed access to the cookie — it's for the webserver's eyes only. Handy! So what would it take to get this into Drupal?

Well, with the caveat that I haven't previously dug into Drupal's session-handling code, it looks like a relatively simple fix. In both d5 and d6 there's a function called sess_regenerate that's called at login and which sets the session cookie. This seems to be the only call to setcookie() in core, in fact, making me think that it's the whole enchilada as far as HttpOnly support goes. The line in question looks like this:

It's been too busy around these parts for me to put together a post about the exciting things happening in the DC tech community, particularly in the hobbyist electronics space (short version: they're exciting!). But I can at least share this tip.

Many of you are probably using the newly-released Firefox 3 release candidate, and it seems likely that some of you are running into the same problems with Firebug that I was, particularly when using its Javascript console. Big, angry errors with "NS" and "SECURITY" in them? Yup, that's the one.

Well, get thee over to the firebug downloads page and grab the latest alpha. It solves this problem, but introduces a new one for those debugging a jQuery-enabled page: the jQuery object is nowhere to be found.

Actually, it's not that bad: you just need to do something like this

$ = window.$;

Before you start mucking around with scripting from the console. It's irritating, but I'm sure it'll be fixed soon. And in the meantime, you could always whip up a Greasemonkey script to do this job automatically.

Hello, World.

That seems appropriate as an opener for my first post on Labs. Usually I find myself on the less-technical, more client-management focused side of things here at EchoDitto, but I was encouraged to join the discussion here, so here I am!

So I was tasked yesterday with adding a graphic button to a client’s site and they wanted the image to change when you mouse over it. A rollover image. Simple enough. Except that I didn’t want to use Javascript. It would have been possible, sure, but I would have had to snag one of my friends on the tech team and it would have been a hassle. So I wanted to see if I could make it work without Javascript.

Luckily, the rollover image the client wanted to use simply involved changing the color of a particular part of the original image. In a flash of resourcefulness, I thought: CSS can do that! Five minutes later, I had what appeared to be a working rollover image.

First, I edited the original image so that the part that needed to change colors was transparent. Then, placed the image in my blog post on a white background. Finally, created a CSS class such that the background changes color on hover.

Voila! Instant fake rollover image.

Maybe it’ll help you next time you can’t, or don’t want to, bother with Javascript.

I'm kind of a jQuery fanboy. Nontechnical friends following my Twitter feed are sick of hearing about it; my colleagues at EchoDitto have learned to avoid mentioning competing JS libraries around me, lest they be subjected to a long and increasingly enthusiastic speech about why they should be using jQuery instead. It's a bit embarrassing. I've used script.aculo.us, moo.fx, and read enough of the Dojo docs to become deeply confused. But jQuery's the one for me.

And, excitingly, a new version was released on Monday. Let's have a look at the biggest changes, shall we (or at least the ones that seem most immediately relevant to me)?

A free flash-based 3D globe? That's scriptable? Neat! Throw in some IP-based geocoding courtesy of hostip.info and you've got yourself a demo.