Bad Code: Google Maps API and Arrays

There was a web site project that went live about 15 months ago.  For resource reasons, the code was pulled together by an external consultant and based on a WordPress site plus some plugins.  One of the elements we asked for was a Google Map that plotted all of the family law courthouses in Ontario.  They provided this and, post engagement, non-technical staff were asked to update it.

The staff did update it but almost every time there was some problem.  The page that created the Google map was based on the Google Maps API, which is well documented.  It is also generated almost entirely using Javascript and this is where the problems entered the mix.  A non-technical person was opening up a Javascript file and trying to make minor changes to a courthouse address or phone number.  Anything that caused the Javascript to throw an error blanked out the map.

The first file looked like this – a repeating Javascript function for the Maps API, one for each courthouse:Old Version, with Repeating Google MapsThis is pretty fiddly looking.  If you know your way around code, you’d probably be fine.  But a missing semi-colon can be a problem and digging through that HTML can be a challenge if you don’t realize you’ve deleted part of a bracket.

What also became clear was that that huge HTML block starting on line 201 was custom.  Even though each courthouse entry contains essentially the same elements, the HTML was a cut-and-paste job from the Attorney General’s site.  It contained all sorts of extra and different code.  As you can also tell, it was not even good HTML5.  The more I looked at it, the more it appeared to have just been slammed together in order to get the job done, but not well.

I decided to pull it apart to try to use arrays to make the file easier to edit.  In part, the array would allow the data elements to stand by themselves and it would be clearer where each one started and ended.  This would also mean that any HTML used to build each place marker would only be located in one place, so any changes could be made there rather than doing a find-and-replace over inconsistent HTML.

The arrays ended up looking like this:

One Ontario Courthouse Array

This is an array of arrays.  And if it sounds like I know what I’m talking about, I don’t.  This was all new to me, other than that I understood the concept of arrays:  you can create a list of elements and run the list through a function.  There was a good bit to learn, but it was pretty straight forward in the end.  The only thing that was odd in an array of arrays is that, apparently, the last array does NOT have a trailing comma, as Internet Explorer sometimes doesn’t like that.

I parsed out all of the elements in the courthouse entries to figure out what went where.  As you can see, it’s pretty basic stuff.  However, there were some automatic links based on a court identifier, or whether or not it had French services.  These became if/then statements in the function that generated each placemark:


This is pretty standard stuff.  I assigned each element in the array to where it needed to appear in the HTML output.  Then I strung them all together to generate the final file.  You can take a look at the source of that file to see the whole set or arrays, the function and variables at the bottom.  Even the bit of closure that I had to learn about in order to stop the function from causing errors!

F12 was my friend.  With all of the commas in the arrays, I inevitably put some in the wrong place!  Hitting F12 in my web browser brought up the Javascript console so I could see what and where the error was.  In one case, I’d placed a comma inside a square bracket rather than outside.  The console returned a TypeError on the LatLng, so I looked at the code, when it fact it was the bad comma.

All in all, the time spent fixing the file was worth it.  I dropped the file size from over 160 Kb down to just under 40 Kb.  Also, the data is now reusable.  I can open up the file again in a text editor, chop out everything but the array, and then import it into a spreadsheet. Most importantly, anyone with a text editor – the screenshots above were done in the Bluefish editor on Ubuntu – can open the file, edit a line, make sure the single quotes and a comma are there, and close the file with some confidence that it will work properly.

Since we have a second project similar to this one in the hopper for delivery in 2015, I’m hoping we can use this data as a starting point for a second map.  It was also a good learning experience from the perspective of understanding when a developer has “finished” a project rather than doing it well.

Leave a Reply

Your email address will not be published. Required fields are marked *