Cartographer Plugin for Rails 3/Google Maps 3 support

Maps are integral part of any application with spatial data. In the past, I’ve utilized Google Maps interface with the YM4R plugin. It was always a little cumbersome in spots but did the trick. There was also the restriction of having to register a key for use in each API call.

But what if you wanted to take advantage of great version 3 features like Street View or Driving Directions? You’d be a little wanting as the YM4R plugin only supported V2 of the API.

Enter the cartographer plugin ( This plugin provides both v2 and v3 API support, as well as clean Rails 3 integration. I feel the code is a little cleaner too. Here’s a brief tutorial of how to add it to your application.


Either install the plugin for via:

rails plugin install git://


git clone git:// vendor/plugins/cartographer


Next, you will need to add some basic code to your controller to create the map object. I prefer to create a helper to do this as it will be used frequently.

module GoogleMapsHelper  
  def map_init'map')    
    @map.icons <<  

I typically add code to the model to be mapped to create the geomarker and info window.

class Site < ActiveRecord::Base  
  def geomarker> 'site', :marker_type => "Building", :position => ll)  

  def ll    
    Array.[]( location.y, location.x )  

From within the controller, call the initialization method and add a marker.

class HousesController < ApplicationController  
  include GoogleMapsHelper
  def index        
    if @site      
      @map.markers << @site.geomarker    
  # and more code...  

Finally to your view, add the necessary code to render the map to a div with the specified id.

<div id='map'>  
  <%= raw %>    
  <%= raw @map.to_html %>  

And that’s it! Pretty simple and very clean in my estimation. I’m now not dreading the upgrade of my mappable applications to Google Maps v3.


exception_logger gem 0.1.8 supports jQuery

There’s an older but popular plugin called exception_logger that I’ve encountered in a few different Rails 2.x project. I found it a useful little tool for tracking uncaught exceptions in your production application, including views for managing them and supporting an RSS feed. The plugin fell into a state of disrepair and was showing signs of age. It would no longer run under Rails 3 due to changes to the way that exceptions are rendered in a production environment. As well, it used older Rails remote calls and prototype.js on it’s management page.

Enter Roland Guem (git user name QuBiT) who undertook the task of converting the plugin to a gem and made it Rails 3 compatible. The only issue left was that it meant you still had to include prototype support in your application. In an effort to try to contribute a little more to Open Source, I undertook my second project and converted the calls to unobstrusive jQuery. Needless to say, the code looks a lot cleaner and is easier to maintain going forward. With the release of the gem today (0.1.8), I’ve been able to upgrade a couple of production applications. I’m looking forward to tackling a little more in the Open Source domain as github really makes it a straight-forward process.

iCal support for Rails

I’ve been pretty busy this week making a ton of headway on a significant project. Said project has support for both events and contacts within it and it made a lot of sense to let users get these out seamlessly to other applications. I’ll write about the vCard support tomorrow and will focus on calendar support tonight.

I’d used the iCalendar gem before so it was only a matter of minutes to get it up and running with my application. In brief, here’s how I would suggest using it.

Add an ical method to the model that will be exporting events. You’ll need to require ‘icalendar’ in order to get access to that class within your model. Here’s an example of the mapping I did between my object and the Icalendar::Event.

def ical
  e.dtstart=DateTime.civil(self.date_start.year, self.date_start.month,, self.date_start.hour, self.date_start.min)    
  e.dtend=DateTime.civil(self.date_end.year, self.date_end.month,, self.date_end.hour, self.date_end.min)    

Take notice of the UID field. You’ll want to ensure you have some sort of permanent UID identifying your event in the application so that subsequent exports (or RSS feeds) of the event will be updates.

You’ll want to handle the request to export the event in your controller. You could map it to the show method, but in my case, I added an export method.

def export
  @event=Event.where(:id => params[:id]).first
  respond_to do |format|

You’ll notice that the format is set to ics, the extension for a calendar file. You’ll need to make a modification to your config/initializers/mime_types.rb to add ICS support, like so:

Mime::Type.register_alias "text/calendar", :ics

Finally, in order to send the event to a calendar file, you’ll need add a view for the export method (in my case views/events/export.ics).

<% %>
<% @calendar.add @event.ical %>
<% @calendar.publish %>
<%= @calendar.to_ical %>

That’s all there is to it – it’s really dead simple and should be an easy addition to any app. You can see how you might expand on this to share entire calendar feeds rather easily.

End before the start? validates_timeliness

It’s been a busy last few days working on a new project that has forced me to produce some of the best work (cleanest) work I’ve produced. Along the way, I’ve come across a few new gems that I’ve utilized to great effect. One of the things I love about Rails is that if you think of a problem, you can be assured it’s not unique to you. I was developing a model today that had a start and end date associated with it. Of course, I could written a custom validator to ensure to the end date was after the start date, but I realized I needed a few variation on this and decided to look for a gem. I found validates_timeliness, which fit the bill perfectly.

Installation and usage of the gem is as simple as advertised. In my case, I had some quick validations in place, such as:

validates_datetime :date_end, :after => :date_start, :if => :date_end

The gem provides a host of options, is Rails 3 ready and works on ActiveModel (meaning you aren’t restricted to ActiveRecord). I can see making good use of this in the future and wouldn’t be surprised if it made it’s way into Rails.

accepts_nested_attributes_for and _destroy without checkboxes

I’ve never been a fan of using check boxes on a form to mark child records for deletion. It seems a little counter-intuitive for most users. While I do use accepts_nested_attributes to mark items for deletion upon save, I don’t use checkboxes.

On my forms, I prefer to delete any list item or table rows that are to be destroyed (after prompting the user to confirm they want these deleted) and then figure out what needs to be deleted upon save. Take as an example Organizations that have many PhoneNumbers associated with them.

We update an organization object as follows:

@organization=Organization.where(:id => params[:id]).first    

And then, before saving, perform the following for the nested attributes:

@organization.phone_numbers.each {|phone| phone.mark_for_destruction unless params[:organization][:phone_numbers_attributes] && params[:organization][:phone_numbers_attributes].detect {|k, v| v.detect {|fld, value| fld=="id" &&}} }

This effectively marks for deletion any phone numbers which belong to the organization, but were no longer present on the form when submitted (because the user asked to remove them with confirmation). I find it makes for a cleaner interface. Two caveats to note in the inner detect call:

  1. Make sure you compare your ID field as a string because the params hash will represent the values as strings.
  2. You want to compare the field name to “id” and not :id as it is not a symbol in the incoming params hash, but a literal string.

jQuery HotKeys

Today was spent refactoring a lot of code on a soon to be released project and trying to optimize some data entry screens. It’s important to try to keep the user on the keyboard as much as possible with as few trips back to the mouse if it can be avoided. On the screen in question, they are often going to be adding a lot of new rows to a table. I had refined the data entry down to a pretty quick process but was left with the problem of having to click the “Add xxx” button to add a new row, a very disruptive process.

Enter jQuery HotKeys. This a pretty slick jQuery plugin that allows you to associate a keydown (or keyup etc) event for a given object with a function.

$(document).bind(‘keydown’, ‘ctrl+a includeInput’, function() {add_game(); return false;});

The version I’ve shown has a small modification to allow this happen even when inputs have focus (thanks to Phil Mickelson for that addition!). It added the final refinement I was looking for to allow for really quick data entry.


jQuery live()

I’ve been working with jQuery for a little while, but because I didn’t read the API from start to finish, I’ve managed to discover some little things along the way. In my Rails apps, I typically have links/button that invoke an Ajax call to the server to render a partial and add it into the DOM somewhere (such as adding an Address partial to a Contact form). Often, I would have some masked entry fields (using jQuery Masked Input) or date pickers or something else that needed to be adorned  with the appropriate JS. Typically I would write some Javascript at the end of the partial rendering that would call some functions to go and reapply the right bindings, such as $(‘.time_field’).mask(’99:99′) for all of the  inputs of class .time_field or adding click functions for links.

The problem I typically ran in to was that I was continually binding the same event handlers on top of already existing handlers every time the Ajax was invoked. In those cases, I had to unbind the event handlers before binding the new event handler which seemed like a lot of extra work for no good reason: $(‘.some_class’).unbind(‘click’).click( function… or $(‘.time_field’)unmask().mask(’99:99′).

That lead me to my discovery of the  live() handler. live() allows you to bind events for all objects matching a selector at the time of execution AND for any new items added to the DOM. This lead to further simplification of my code. No longer did I need to tack on a little JS function when returning my rendered partial to adorn the fields needing extra behaviours when live() would take care of that for me. I really wish I knew about that before.