Archive for the 'Javascript' Category

Delaying Ajax-based validation triggers

When you're doing Ajax-based validation on a text input control, you really don't want your data calls firing off at every keyup event as this will put unnecessary load on your server. Instead, the thing to do is to wait a little while after the user's last key release to see if she's stopped typing before firing off a request.

I'm sure that there are hundreds of code snippets lying about for doing just this, and that JQuery probably already has something built in or a plugin for it, but a quick Google search didn't turn up anything for me so here I am, sharing my simple solution for delayed Ajax validation in JavaScript.

// A simple mechanism to handle delayed validation based on keyboard entry.
// Copyright (c) 2008, Aral Balkan, All Rights Reserved.
// Released under the MIT license.
validationFunctionRefs = [];
timers = [];
function callAfterDelay(fnRef, duration){
 
	// Check if a timer for this validation function is already in effect
	// and reset it if it is.
	for (i = 0; i < validationFunctionRefs.length; i++) {
		fnToCheck = validationFunctionRefs[i];
		if (fnToCheck == fnRef){
			timer = timers[i];
			clearInterval(timer);
			timers.splice(i,1);
                        validationFunctionRefs.splice(i,1);
                        break;
		}
	}
 
	timer = setTimeout(fnRef, duration);
	timers.push(timer);
	validationFunctionRefs.push(fnRef);
 
	return timer
}
 

To use it, simply call callAfterDelay from your event handler for the keyup event. e.g., in JQuery:

$("#id_vat_no").keyup(function(){callAfterDelay(checkVatNumber, 500)})

In this case, 500ms after the user stops typing in a text input, the checkVatNumber method will make a JSONP call to the European VAT Number Validation service to see if the entered VAT number is valid.

FlashAid version 1.0 released

FlashAid logo

Executive Summary: FlashAid enables Ajax/JavaScript to find out if a user's screen reader is currently communicating with the browser and turn off the JavaScript functionality accordingly to make their sites accessible. It only works on Internet Explorer on Windows.

And now the full story...

I just released an update to FlashAid that, well, actually makes FlashAid useful.

You can see a live demo of FlashAid here.

(FlashAid only works on Internet Explorer on Windows. Make sure you have your screen reader on before testing.)

Version 0.1, the previous release, was a proof-of-concept that I hacked together after a talk with Jeremy. All it did was pass the value of the System.capabilities.hasAccessibility property from Flash to JavaScript.

The Adobe Flash docs for System.capabilities.hasAccessibility states the following:

A Boolean value that is true if the player is running in an environment that supports communication between Flash Player and accessibility aids; false otherwise.

What the documentation should state, is:

A Boolean value that is true if the player is running in Internet Explorer on Windows.

Essentially, that's all hasAccessibility appears to show. The Flash player uses MSAA to talk to screen readers but it only works in Internet Explorer (FireFox has MSAA support but the Flash player returns false for hasAccessibility on that platform, for example.)

So, the FlashAid proof-of-concept was essentially useless (you can check for IE on Windows with one line of code in JavaScript.)

Version 1.0, though, does have an important use. It's a one trick pony that communicates the value of Flash's Accessibility.isActive property to JavaScript. This one's useful because, on Internet Explorer on Windows, it tells you whether the user's screen reader is actually communicating with the browser.

Why is this important? Because it allows Ajax developers using progressive enhancement to detect whether the user is using a screen reader and turn off the Ajax/JavaScript functionality to allow these users to access their sites and applications.

Again, keep in mind that this only works for Internet Explorer on Windows but it's still an improvement on what was previously possible.

I hope you find FlashAid v1.0 useful.

Doodle schmoodle

I came across an article on Webreference yesterday about a Canvas-based JavaScript sample for drawing lines. It's a huge script and the sample runs like a dog. So this morning I thought I'd churn out a dozen lines of code to do this in Flash but Richard Leggett beat me to it. Read his blog post on choosing the right tool for the job.

BarCampLondon: Jeremy Keith on Hijax

I'm sitting in Jeremy's session, hearing about his Hijax system for "progressive enhancement". Progressive enhancement takes a new look at what we used to call "graceful degradation". Basically, it's starting with the content/symantic layer and layering on additional functionality on top of that.

He's currently talking about how best to implement JavaScript behavior into your HTML application and the method he's showing me is so close (in intent and implementation) to the code behind method I advocate in Flex and Flash development.

The Hijax approach:

  • Begin using traditional page refreshes
  • Data sent to server via links and form submissions
  • Intercept (hijack) those links and forms using unobtrusive javascript
  • Send that to XMLHTTPRequest
  • Server returns just the information that's required

Server side requirements:

  • Back-end architecture must be modular
  • Web pages must be modular (components/APIs)

The paradox:

  • Plan for Ajax from the start
  • Implement Ajax at the end

When to use Ajax:

A page includes a form. When the form is submitted, the same page is returned with just part of the page updated (eg. blog comments.)

Clicking on a link returns the same page but with a different view on the data (on thing has changed.) Product ratings, filtered product set, etc.

Jeremy's method uses the XMLHttpRequest as a dumb waiter. Client-side processing is kept to a minimum.






Bad Behavior has blocked 0 access attempts in the last 7 days.