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.

European VAT Number Validation API

EU-based businesses are required to obtain valid VAT numbers from VAT-registered entities.

Unfortunately, especially for e-commerce systems, there isn't a simple way to check the validity of a European VAT number. The European Commission provides a web site where you can validate VAT numbers by entering them in an HTML form. This is not practical, of course, for web applications.

Enter, the European VAT Number Validation API that I just hacked together on Google App Engine.

You can hit a URL like http://isvat.appspot.com/GB/802311782/ and get a true or a false back as a simple JSON boolean.

Check out the European VAT Number Validation API.

I hope you find it useful.

Displaying “Pay” instead of “Continue” on the PayPal site with PayPal Payments Pro UK Express Checkout

By default, PayPal Express Checkout for PayPal Payments Pro UK displays a "Continue" button and sends the user back to your site expecting a confirmation page before actually making the payment.

This differs from other PayPal checkout procedures and, in my testing, I found that users expected to complete the transaction once on the PayPal web site.

PayPal allows this but it's not well documented.

The catch is that you need to add a query string parameter, &useraction=commit to the end of the URL that you forward your user to after your initial SetExpressCheckout call returns.

Then, call the DoExpressCheckout method directly after the user returns to your site (or you can call GetExpressCheckoutDetails and follow it up with DoExpressCheckout if you want to get all of the order details.)

Via: Ollie Ready's post on the PayPal Developer's Forum.

ISO 3166 Alpha-2 codes for EU countries

For businesses based in the EU, it's important for VAT purposes to know whether your customers are also based in the EU. As usual, a quick Google search did not reveal a usable list of EU countries by ISO 3166 Alpha-2 code, so I whipped up my own.

european_union_countries = ('AT', 'BE', 'BG', 'CY', 'CZ', 'DK', 'EE', 'FI', 'FR', 'DE', 'GR', 'HU', 'IE', 'IT', 'LV', 'LT', 'LU', 'MT', 'NL', 'PL', 'PT', 'RO', 'SK', 'SI', 'ES', 'SE', 'GB',)

Take a look at Open Country Codes if you want a constantly up-to-date list of all ISO 3166 Alpha-2 codes and country names as data structures and components for various languages.

Enjoy! :)

Yahoo! to fix GeoPlanet JSON API today

As I posted last week, a backwards-incompatible API change to the JSON version of Yahoo!'s excellent GeoPlanet API caused the new teaser site for the Singularity web conference to fail.

Today, I got an email from Eddie Babcock from the Y! Geo team informing me that this was due to a regression and that they will be issuing a fix today that will revert the API to its original state.

Looking on the yws-geo forums, I saw that Eddie had posted a longer reply to my forum post, in which he states:

We apologize for introducing a regression bug in our JSON response for the places collection and causing a disruption of your application. The place elements should be part of the place array and not part of the places associative array.

The proper way to access a place in a collection is using result['places']['place'][i].

We will fix this bug in the next release of the API. Since the bug fix will restore the original behavior, it will also break your client-side fix. We suggest that you first look for a place array in the JSON response, and if one is not returned, then use your client-side fix to find the place elements.

I'm also happy to hear that they will henceforth be posting release notes on the Yahoo GeoPlanet API documentation and informing developers of updates on the forums.

I've already implemented the conditional check for the 'place' key in the result so the site should hopefully not suffer any more downtime when they switch the API back.

As they say, regression happens! Thanks for fixing this, guys, and for keeping us in the loop.

Update: Sorry, everyone, the update _did_ break the site again (just fixed it) because another method changed behavior. A call with /belongtos('Time Zone')?format=json used to return just a places array with string indices. After the update which reverted query call return values, belongsto return values also changed. This is actually a good change as it means that the API is now consistent in what it returns but, again, I would have appreciated a heads up.

Alessandro Crugnola and Sephiroth.it join Pistach.io Flash Pack

It's my pleasure to welcome ace Flash developer and author of SE|PY, Alessandro Crugnola and his site sephiroth.it, to the Pistach.io Flash Pack in July.

Buying an ad on the Pistach.io Flash Pack puts your ad on all of the following web sites: Alessandro Crugnola (sephiroth.it), Andre Michelle, Aral Balkan, Chad Udell, Flash Magazine, Grant Skinner, Keith Peters, Marco Casario, Mario Klingemann, OSFlash, Peter Elst, and Seb Lee-Delisle.

Find out more on the Pistach.io web site.

Announcing Singularity’s latest platinum sponsor: Adobe

Adobe

I'm happy to announce that Adobe is sponsoring the Singularity web conference as a platinum sponsor. Our sponsorship agreement also gives Adobe global rights for venue sponsorship.

A big thank-you to Kevin Lynch, David Mendels, Michelle Turner, and Ted Patrick who kindly gave me their support and encouragement from the earliest days.

As global venue sponsors, Adobe can now be involved in organizing local conference hubs anywhere in the world and we are going to be working closely with Adobe and the various Adobe User Groups around the world to this end.

Adobe joins Influxis and Lynda.com as the third and final platinum sponsor for Singularity. We do still have regular sponsorship and venue sponsorship positions available. See the Singularity web conference sponsorship page for more information.

Thank you for supporting Singularity :)

Singularity ticket sales starting this Monday

To give ourselves a bit more time to test things, we're pushing tickets sales for the Singularity web conference to Monday, July 7th.

I also have an exciting announcement to make but that requires it's own post...

Yahoo! GeoPlanet API makes backwards-incompatible change, keeps it secret?

I just noticed that the Yahoo! GeoPlanet API made an API change to its JSON API that breaks existing apps. (I noticed because it broke the sign-up process for the new Singularity teaser site.)

Googling around, I couldn't find any announcements from Yahoo! about this. I don't know if there's a notification feed somewhere that I'm missing -- if so, I'd appreciate it if someone could point me in the right direction. Otherwise, in case any other developres are using the Yahoo! GeoPlanet JSON API and are affected by this, here's a summary of the change from the post I just made on the yws-geo forum:

I just realized that you removed the 'place' array from the JSON object returned from places.q() calls (e.g., of form http://where.yahooapis.com/v1/places.q('city
name');count=0?format=json
) and that the returned places object now has the
place indices as strings.

This requires code to be changed from, for example, result['places']['place'] to result['places'] and also requires that numeric indexed loops be changed to use string indices.

It's quite baffling that a change like this (which, really, isn't even necessary) was made and not communicated. Even more so considering that the API is versioned properly (you access it from /v1/), so a change like this should really have gone into (/v2/).

I would love to hear from someone on the Yahoo! GeoPlanet team about the rationale behind this change and where we can find out about similar changes in the future.

I love the Yahoo! GeoPlanet API -- it is awesome and very simple to work with -- but please, guys, pay a bit more attention to backwards compatibility, communicate better, and don't break existing apps! :)

On online security and password policies

Writing the post on del.icio.us's password policy got me thinking about passwords and online security again.

Having a strong password policy such as "passwords must be longer than six characters and must contain a number or a symbol and a mix of uppercase and lowercase characters" is great in theory but let's take a moment to follow Joe User as he encounters such a policy and chooses his password:

Joe User: Ah, it won't let me use my normal password, I need to create a new one... ok, done!

Joe User: Hmm, I'm never going to remember this, let me just write it down on this Post-it note.

Joe User: Better not lose this, let's stick it on my monitor.

Joe User: Cool, now that's done, I can leave for lunch.

See the problem?

The weakest link in online security is not password strength but the human being who owns the password. Having a complicated password policy that enforces strong passwords may actually become a security issue if it results in the user writing her password down to remember it as that becomes the weakest link in the chain. (By the way, this isn't fiction, I’ve actually seen passwords on Post-it notes stuck to monitors — good, honest, strong passwords — completely compromised.)

It's a balance, for sure, but not always between security and usability as it is often portrayed. It's a balance between security and security. Specifically, beyond a certain point, increasing the complexity of password policies may actually start compromising the overall security of the whole system where the user, not the password, is the weakest link.

It's also a matter of psychology. Different applications handle data of varying sensitivity and users have varying expectations of what comprises adequate security. You expect a bank to have a strong password policy. Twitter? Not really.

Usability, of course, is also a very important consideration. There are some applications where you spare nary a thought for the authentication system, it just works and stays out of your way. Yet there are others were it seems you are always filling out the forgotten password form. Guess which ones users like more.






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