Please visit my new campsite listing site ukcampingmap.co.uk


Archive for the ‘Javascript’ Category

Geocoding in the UK

Sunday, August 16th, 2009

The art of geocoding addresses in the UK, as I previously explained, is a soul-destroying process, frought with inaccuracy, bugs and convoluted workarounds. And for all that work you end up with a set of points of which a great deal are probably somewhat inaccurate and at least some of which are completely wrong. UK addresses (and probably those elsewhere in the world) are complicated creatures, which Google’s geocoding engine often interprets wrongly.

Postcodes, on the other hand, are rather easier; there is a well-defined relationship between a UK postcode and its corresponding (usually pretty small) piece of the British countryside. But google’s geocoding api will only return a geocode for the postcode sector (ie will give a geocode for LL12 5 when you searched for LL12 5TH). However, someone did figure out a way of using Google’s local search API combined with google maps to geocode UK postcodes. Since he blogged about it the API has changed, so below is an outline of how to geocode a batch of postcodes in the UK using just some simple php, the current google ajax search API and a little javascript (jQuery isn’t essential, but cuts down on coding a bit). The javascript is the crucial step.

Assuming you have a database full of postcodes and id numbers, and 2 empty columns to store latitude and longitude values, this is how it’s done. (Download source geocode.zip).

1. Create a html page geocode.html with the following content:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >

<head>
<title></title>
<meta name="description" content="" />
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<link rel="stylesheet" href="" type="text/css" media="screen" />
<script type="text/javascript" src="jquery-1.3.2.js"></script>
<script src="http://www.google.com/jsapi" type="text/javascript"></script>
<script type="text/javascript" src="geocode.js"></script>
</head>
<body>
<div id="counter"></div>
</body>
</html>

(Make sure you specify the correct location for your local javascript files)

2. Create a php file (in the same directory), geocode.php, with the following rough structure (it will only be accessed via ajax, so is very stripped down):

<?php
require_once ('mysqlConnect.php'); //or other database connection details
if($_GET)
{
 //var_dump($_GET);
 update_record();
 send_new_data();
}

//gets the next record without a geocode and sends the id and postcode to the browser
function send_new_data() {
 $query = @mysql_query("SELECT id, postcode FROM geocode_table WHERE lat = '' AND postcode != '' ORDER BY id LIMIT 1");
 if(($query) &&mysql_num_rows($query)) {
  $row = mysql_fetch_array($query, MYSQL_ASSOC);
  echo $row['id'].','.$row['postcode'];
 } else {
  echo 'stop';
 }
}

//updates the last record with data sent from browser
function update_record() {
 $id = $_GET['id'];
 $lat = $_GET['lat'];
 $lng = $_GET['lng'];
 if($id > 0)
 {
  $update = "UPDATE geocode_table SET lat = '".$lat."', lng = '".$lng."' WHERE id = ".$id;
  $result = @mysql_query($update);
  if (!$result) {
   die('Invalid query: ' . mysql_error());
  }
 }
}
?>

3. Create a javascript file geocode.js, saved in the same directory again (I would paste it here but it keeps breaking wordpress)

4. Running the code

Once you’ve altered the database connection details, and SQL query to suit your setup, simply open geocode.html in your browser. A counter will tell you which record you’re on. To stop the code simply close your browser/browser tab.

How it all works

In a nutshell (ignoring the special case of starting off the loop) the code repeatedly performs the following process:

….in geocode.php, send_new_data() finds a record which has no latitude value and sends it’s id number and postcode as an ajax response to set_and_get_next(). This keeps track of the id in a global variable and sends the postcode to getPointFromPostcode(), which uses google’s local search to get a geocode. Once it’s found a geocode it passes it to set_and_get_next(), which sends it to geocode.php in an ajax request. There update_record()… well… updates the record, and send_new_data() finds a record which has no la….

Compared to my previous approach iterating a script over large sets of data, using ajax is very sleek. Similarly to a pure php script I can load from a browser, though with much of the resource intensive scripting taking place on my or google’s server. But with ajax there’s no problem with the browser timing out from time to time, or baulking at the number of times a page is requested. It’s a little harder to code, and probably less efficient… but I like it. And I’ll definitely be using my shiny new geocoded postcode data.

To splice or not to delete

Friday, August 14th, 2009

I haven’t blogged much about programming recently due to being too busy… too busy to blog, not too busy to program.

This is just a swift post to highlight an important distinction that I haven’t seen mentioned anywhere else, and which recently I realised the siginificance of.

In javascript, what’s the difference between

delete my_array[i];

and

my_array.splice(i, 1);

Superficially they’re the same – they each remove the ith element from an array. But the crucial difference is that delete leaves a gap in the array, so there will no longer be an ith element – the array jumps straight from the (i-1)th to the (i+1)th element. But splice moves the (i+1)th element into the ith place in the array, and so on, shortening the array by one but moving everything along to fill the gap.

Why is this important?

If your code relies often on iterating through an array thus:

for(i=0;i<my_array.length;i++)
{
    //some code
}

then any future iterations over the array will throw errors if you used delete to remove the ith element. But the iterations should still work if you used the splice method.

One note of caution, if you carry out

my_array.splice(i, 1);

within a loop over i, you should add the line

i--;

immediately after, to make sure you don’t miss out the next array element (which is now, of course, not in the (i+1)th place, but in the ith place).

jQuery.each() for single objects

Thursday, July 9th, 2009

While refining  jQuery.crossselect.js recently I was briefly faced with a problem which often rears its ugly head, though this time I found a solution.

Consider a function alters_item(), which can be applied to certain DOM elements. Further, consider that it can be triggered in two distinct ways:

  1. By a click (or other event) on the item to be altered, so the DOM element is the context and can be accessed via the pseudo-variable this
  2. Just applied like a normal javascript function, which means the DOM element needs to be passed in as a parameter, i.e. you need to call the function using alters_item(element)

So to have a function usable in both circumstances I would write some conditionals at the start which check if an argument has been passed, if it hasn’t then set var element = this, etc…

But there is another way.

For the second case instead of

alters_item(element)

we can write

$(element).each(alters_item)

because jQuery.each works even on jQueries that return only one object.

Doing this is a bit of a trade off – the second line of code I bet takes measurably longer to execute, but it does mean my functions get to be simpler, so it’s my weapon of choice at the moment.

But it does make me think that jQuery should have a call() method, that runs a function on an object, but also setting the object as the context.

Incidentally, if anyone knows of a better way of dealng with this isue than the one I’ve found, please let me know.

Optimize how?

Thursday, July 2nd, 2009

Yesterday and today I’ve been rewriting my jQuery crossSelect plugin (probably over half of the code has changed) to; a) Fix the serious bugs brought about by trying to bring my plugin closer in line with how it’s supposed to be done, without fully understanding the implications in advance; b) make the code more efficient, in part applying the ideas in this excellent article; and c) prepare the code for bringing in more functionality in later releases.

With regard to c), the main thing I needed to do was rewrite all my selection and removal functions so that moving many items into the selected column at once could just be the move one item function iterated a number of times. I’ve now ( I think) found a pretty efficient solution (each move many function is only 3 lines long), but along the way I came across an interesting dilemma.

My selectOne() function essentially moved a list item and then checks how many items are in each list before adjusting the buttons appropriately. Now, to do a selectAll() or a selectMany() the obvious thing to do is just to iterate that selectOne() function over all list items – just a handful of lines of code – … but this unfortunately leads to a less efficient (and probably slower) function. Writing a selectAll()/selectMany() function from scratch would enable me to only adjust the buttons once and, in the selectAll() case, not have to care about tracking which list item I’m dealing with as they all get moved over in the end… but this way would not only be less elegant, I feel, but also lead to more lines of code.

I’d always assumed that optimising code meant two things – faster and smaller – and I’d always thought that one more or less implies the other. Turns out I was wrong.

In the end, the escape from this trade off involved removing the button adjustment from selectOne() and putting it in selectNow(), a new function triggered by a click. But this required a feature of jQuery which I’ll talk about in some other post.

It’s all about context

Saturday, May 30th, 2009

One big selling point of jQuery – so everyone says – is the ability to nest/chain selectors, so that using oen string you can, in theory, pick out any element in the DOM. But this has eluded me somewhat until today; until I realised the usefulness of setting a context for jQuery selectors.

I noticed a few days ago that my new crossSelect plugin was a bit inefficient, in that it queried the DOM far too often. It used to have something like the following code:

$(this).parent().parent().find('.target1').children('li')...
$(this).parent().parent().find('.target2').children('li')...

But the next iteration was going to have something like this instead – far sleeker.

var context = $(this).parent().parent()
$(context).find('.target1').children('li')...
$(context).find('.target2').children('li')...

But it bugged me that I couldn’t pick out the <li>’s with a string selector. This is because context is an object, not a string, and therefore can’t be a part of a selector string. But then I discovered setting the context on selectors (easy to miss as it’s not linked to from the selectors bit of the documentation site). So that led to the following:

$(context).find('.target2').children('li');

is equivalent to

$('.target2', context).children('li');

which can be rewritten

$('.target2 > li', context);

Far more elegant, I think you’ll agree. So it’s jQuery context setting all the way for me. From now on I will only use find when I need to find a child element on the same line that I’ve already done something to the parent; it really has no place at the begining of a line of jQuery code.

crossSelect jQuery plugin

Wednesday, May 27th, 2009

I thought I should write a short post to say I have written another jQuery plugin, for making multiple select form elements more intuitive to use. It’s called crossSelect, and here is a demo.

One of these days I will make a proper portfolio site/subsite which collects all the stuff I make together.

I will, I will, I will!

In defence of jQuery browser detection

Friday, May 22nd, 2009

I read somewhere the other week that jQuery is deprecating its jQuery.browser method, which means that in the future (though not yet, as the method still works but will not continue to be developed/supported, and will eventually be dropped) you will not be able to directly ask jQuery which browser it is being run in.

The rationale behind doing this is on the face of it sound: The reason you want to check what the browser is is that you want to check if a feature of javascript is available in that browser… so why not just ask if that feature is available, then the question of which browser it is becomes irrelevant. This will enable your script to continue to function (most probably) even in the unlikely event that eg Microsoft bring out a patch for ie6 that makes it fully support javascript.

But there is a flaw in this reasoning. It assumes that the only reason you would want to serve some different script to a browser is because of flaws in the browser’s javascript implementation, but in fact there are other reasons for doing this too, principally the browser’s failure to render CSS correctly.

While the new jQuery.support method does include tests for boxModel (ie6 and 7′s incorrect rendering of the CSS box model being the principle reason behind serving different CSS to different browsers) and one or two other CSS bugs, this simply isn’t up to the task. The box model is broken in ie6 and ie7, but broken in different ways, so normally to fix a layout bug I will want to serve different CSS to both.

Using various combinations of jQuery.support, eg

!jQuery.support.boxModel && jQuery.support.objectAll

you can still detect ie6 and ie7… but is this really an improvement on jQuery.browser?

jQuery.browser.msie && jQuery.browser.version.substr(0,1)=="6"

With jQuery.browser it is wholly transparent what you’re trying to detect, and if the code within the conditional’s braces contains a hefty amount of CSS rules your average developer should be able to work out the reason for the browser detection is to fix CSS bugs.

One other reason for explicitly detecting a browser (which I need at the moment as I’m developing a jQuery plugin) is that different browsers render form elements differently (the most obvious black sheep is safari’s making most elements look blue and glossy, but there are subtle differences in other browsers too). If I, say, want to fake a <select> element  by using a <ul>, and want it to look convincing in all browsers I need to supply each browser with differentiated CSS. jQuery.browser would be the obvious way to do this. No matter how many CSS bugs get fixed in browsers, how to render form elements by default isn’t specified by CSS/html, so there will always be this reason to want to detect browsers.

jQuery.browser is a very useful feature and it’ll be a shame when it goes.

fullTextArea jQuery plug-in

Friday, April 17th, 2009

I’ve just written it, and have to provide a homepage for it. will add more details later.

Demo: fulltextarea.html

Current release

jqueryfulltextarea031

Release details:

  • Tidied up and optimised code

Previous versions

Better jQuery plugins search

Tuesday, April 14th, 2009

Everyone wants one and, let’s face it, anyone cool already seems to have one.

I’m talking of course about overlays, or modal windows, those dialog boxes that grey out most of the browser screen to focus your attention on a  short but important form that needs completing, or to show you an image gallery, or basically make things which could look cooler, look cooler.

So I needed to make one of these for work, and off I went to the jQuery site to search its plug-ins.

However, to give an indication of how good the jQuery site search is, the top result for “overlay” is

IE6 crashing when you click an image

… and this is when the search is restricted to the plug-ins subsite!

So I did what any other person who is me would do in a situation like this – I searched Google, restricting the search to site:plugins/jquery.com/project, and was so impressed with the results that I created the Better jQuery plugins search.

jNice styled forms fix for select change event

Saturday, March 21st, 2009

I’m working so can’t be bothered writing out in full, but in case anyone else spends hours trying to work out why their fancy looking jQuery select boxes don’t seem to have a change event, add this line near the end of the selectUpdate function, just before return false;

$select.trigger(“change”);