Dynamically load combobox using jQuery

Giganews Newsgroups
Webpages easily contain a lot of duplicate content. This however, can hurt your Google pagerank. Duplicate content can also slow down your pages.
Currently I’m building a new site with some friends. This site has a sign-up form with all the usual fields like name, email, country and so on. Now, to make sure the new user enters a correct country, they are presented with a complete list of countries in the world. This list was, until a few days ago, loaded into all the pages on the site = bad for performance!

This is how I solved it:

First off, the signup form in hidden until the user decides to sign-up – clicking a button. When the form is presented the countries select-box is almost empty. It only contains one option “Please select a country”. When the user clicks the select box, all the countries are dynamically loaded through AJAX and inserted into the select box.

Below is how the countries are loaded using jQuery

$(document).ready(function()
{
     $('#country').click(function()
     {
     // only load the list if not already loaded
     if($('#country option').size() > 1 )
          return;
     url = 'http://www.zoon.dk/countries.json';
     $.getJSON(url, function(j)
     {
          var options = '';
          for (var i = 0; i < j.length; i++)
          {
               options += '';
          }
          $("#country").html(options);
     })
});

As you can see, the countries list is in JSON format. Usually people store this kind of information in a database… but why? How often do we see a new country in the world? Why do you want the extra database overhead? I can’t come up with a single good reason… but perhaps you can?

You could choose to store the list in pure HTML, and just load it with

$("#country").html(j);

That would be even faster 🙂

Anyways, nothing beats a demo…

Find a demo using this technique right here, and please leave a comment if you know of a better or faster way 🙂


One Response to “Dynamically load combobox using jQuery”

  • Dan Says:

    You opened up a can of worms with that “extra database overhead” comment :). Typically, all static/lookup content is stored in DB lookup tables. If I hard coded any data like that in a file or HTML, my clients would fire me on the spot… it’s a no no. The middle tier (i.e. Java, .NET, etc.) would cache this kind of data a reload a specific interval. Caching is also another can of worms, but I’m just using it generally speaking. Having said that, I do agree with overhead, but a robust framework could handle situations like this. BTW, love the completion checker!

Leave a Reply

You must be logged in to post a comment.