Entries tagged “javascript”

While working on a Javascript interactive for the diaBeaters project, we stumbled across an interesting problem with jQuery UI draggables. To wit: if you have draggable items inside a div with overflow:hidden, they're stuck. You can't drag them out of the container -- the div just scrolls out to infinity. (Try it sometime, it's awful.)

Here's the original drag-and-drop setup. The game involves dragging magnets from a menu on the left-hand side onto a refrigerator on the right.

jQuery(".magnet").draggable({
  revert: 'invalid'
});

jQuery("#fridge").droppable({
  drop: function(event, ui) {
      jQuery(this).addClass('dropped');
  });
This is a strongly-opinioned fly-by review of the evolving web framework ecosystem for Node.js.

I'm a big fan of Javascript, and write a lot of it for browsers.  So I've been excited about the prospects of server-side javascript which opens up a lot of possibilities for sharing code on the client and server side.

Node.js seems to have exploded server-side javascript development, as it was fast, easy to setup, and provided a niche-advantage in handling requests asynchronously.

But Node.js is a low-level runtime which brings a good standard library and scripting environment for deployment. We don't want to re-write cookie and session handling for every project.  For web development we need a framework that organizes code and brings the old lessons that Rails brought to projects like Turbogears and Django in python.

One of the primary tenets of agile development is test first, test often. After working in a small XP shop doing mobile development, I came to believe strongly that quality code hinges on a test-driven approach.

Coders, impatient with paper specs and endless product meetings, often rush to their keyboards and push out half-baked, poorly implemented solutions that don't meet anyone's needs. Writing tests -- especially in a test-first approach -- provides time for thoughtful inquiry into an application's overall design and specific functionality. The coder can express herself in her own comfortable environment and language. The resulting tests become permanent artifacts, able to verify functionality as the application is enhanced and refactored.

And, in less altruistic, more self-serving terms: good tests mean good code, and good code makes the coder look good. Why wouldn't you want to write tests?

Still, I was a little apprehensive when asked to setup a test infrastructure for the Mondrian JavaScript components. (Mondrian is our snazzy new web-based, multimedia, annotation environment). I've tackled many server-side testing tasks, but have managed to circumvent the swampy land of JavaScript. JavaScript generally does not lend itself to testing. Most JavaScript code I've seen is poorly organized, fragmentary and tightly-bound to the browser. I've often lamented the lack of good JavaScript testing tools, but also was loathe to tackle the seemingly messy, difficult task.

We are very excited to announce the release of our latest iteration on a web-based, multimedia, annotation environment - code named: Mondrian Mediathread ( source code ). Mediathread builds on the strengths and experiences of our long history of annotation projects here at CCNMTL.

Mediathread is a collaborative multimedia analysis environment that supports deep critical exploration of primary multimedia source material, i.e. participatory education, research, democracy, and culture. The Mediathread platform supports a robust access control model with multiple analysis spaces and a variety of workflows (solo projects, collaborative projects, versioning, private projects, public projects, etc). The community portal also organizes streams of activity notifications to help the participants track each other's (net)work.

Participants in the analysis space collect multimedia assets from around the web, clip/annotate these assets, organize their clips, and create a multimedia composition where their clips are directly embedded inline in their analysis/argument. The upcoming release supports video clipping (quicktime, flowplayer, and youtube), and drawing on images (using the fabulous OpenLayers viewer).

In March, CCNMTL shipped a laptop to a South African AIDS clinic as a part of a multimedia health-care intervention.

We're not that experienced with desktop application development, so the main discussion was how do we bundle a web application on a stand-alone laptop with no connection to the Internet. The first proposal was to run a virtual machine (Xen or VMware) which would run the web server on the Windows desktop.

I was less sanguine about diagnosing problems with a web server across continents and timezones, and looked for a way to store state information from static web pages. Firefox's DOM Storage was close to a HTML5 standard (now finally implemented in Firefox 3.5), and seemed to work with URLs visited as "file://localhost/C:/..." so this made the following process possible:

  1. Put static HTML files on the laptop
  2. All state is stored by the browser (in a file called webappsstore.sqlite)
  3. All application storage is accessed and modified by javascript (see code)
  4. Login state uses sessionStorage which works similarly but disappears after the browser closes (like a session cookie)

Instead of supporting a virtualization and web server stack, all that's left to support is the browser--something very familiar to all computer users by now. It's worked out great.

I should note that our application is not secure from a javascript hacker who has access to the computer--they could access and change all account information on our system. Fortunately, that's not an attack vector we're worried about.

OK, there's a dirty secret behind my not posting about this previously--it no longer works! There's a laptop in a South African clinic that's not getting any Firefox updates, security or otherwise, and that's a very good thing. Now, it seems, all browsers, remove the 'localhost' from file:// URLs. The new HTML5 standard localStorage does not work for local files, and the deprecated globalStorage[hostname] doesn't work without a hostname!

HTML5 taketh away, but it giveth ath well. Instead of relying on file:// URLs, in the future we can label our site as an offline resource and then use the now standardized and implemented localStorage.

The one issue with this future approach is if we need to update the application while it's in the field. We haven't needed to do that on this project, but it's a comfort to know that if they discovered a critical bug, we could email them a single HTML file to replace, and the computer running the application does not need to be connected (to anything other than the USB key the new file is on). I sent our use cases for localStorage over to the HTML5 mailing list, but there's still work on the standards side and for the browser vendors.

Feed Subscription

If you use an RSS reader, you can subscribe to a feed of all future entries tagged “javascript”. [What is this?]