To play along at home, you’ll need your own Google Maps key or you can just aim your mobile browser to my example code at http://kickasslabs.com/examples/gmap_events.html. (Note that this will not work in a regular desktop browser.) Besides a <script> tag importing the GMaps JavaScript, you should not need any other libraries or tools besides Mobile Safari to view and use the example page. If the page is zoomed way out when you start, just double-tap the map tile in the upper-left corner – it should zoom to fill your viewport.

What you should see is a map tile with a line painted on it. If you touch the screen, you should see one end of the line follow your finger.

It looks simple but I had a bit of trouble getting it to work, because touch events are not like mouse events (curious as to why?), and GMaps doesn’t respond to touch events by default.

Step by Step

First, you need 2 divs:

    <!-- This div holds our map -->
    <div id="map" style="width: 320; height: 320px"></div>
 
    <!-- This div lies on top of the map and acts as an event proxy -->
    <div id="mapoverlay" style="height:320px; width: 320px; position: absolute;"></div>

And you need to position one div over the other:

    mapDiv = document.getElementById('map');
    mapOverlayDiv = document.getElementById('mapoverlay');
    mapOverlayDiv.style.top = (mapDiv.offsetTop + 0) + 'px';
    mapOverlayDiv.style.left = (mapDiv.offsetLeft + 0) + 'px';

You set up the map div like you would for any other GMaps-enabled page:

    // the map
    _map = new GMap2(document.getElementById("map"));
 
    // coordinates for home base
    _lat = 37;
    _lng = -95;
    mapCenter = new GLatLng(_lat, _lng);
    _map.setCenter(mapCenter, 15);

Set up the overlay div to respond to touch events by firing a custom event for your map, e.g.:

    mapOverlayDiv.ontouchstart = function(e) {
      GEvent.trigger(_map, 'customTouchStart',
        (e.touches[0].pageX - mapDiv.offsetLeft),
        (e.touches[0].pageY - mapDiv.offsetTop));
    }

Now have your map respond to that event:

    GEvent.addListener(_map, 'customTouchStart', mapTouchStart);

…where mapTouchStart is a callback function that does something useful in response to a touch:

    function mapTouchStart(xPixel, yPixel) {
      redrawLine(xPixel, yPixel);
    }

And… well, then you’re done. My example also responds to the touchMove event and has a little code for drawing lines, but you’ve seen all you need to know to get event proxying up and running for your app.

Got a question? Got working code for an easier way? Drop me a line in the comments!

The Context: We had a table of records were using remote_form_for to output an edit form for each row so that we could allow inline editing of any row via AJAX. The code looked something like this:

-remote_form_for(person) do |f|
  %tr
    %td
      =f.text_field :first_name
    %td
      =f.text_field :last_name
    %td
      =f.submit 'Save'

If you prefer straight HTML, the relevant code looked something like this:

<form>
<input name="person[first_name]" type="text" />
<input name="person[last_name]" type="text" />
<input type="submit" value="Save" />
</form>

The Problem: When submitting an edit on any of the people rows, we would see an ActionController::InvalidAuthenticityToken exception in the server log. This error is usually a sign of a configuration problem with your environment, but our case seemed different. Firebug showed us that the browser didn’t appear to be passing any params to the server during it’s update post and the server log didn’t show any params coming through, either. So, it wasn’t an invalid authenticity token being passed; no token was being pased at all. I would prefer if Rails gave us a MissingAuthenticityToken error instead but I digress.

The Discovery: After whipping up a test case where we had a remote form on a page working fine with no errors, we discovered that the problem only occured when the form was wrapping the record’s table row tag in the view. And, well, this makes a good deal of sense. Here’s what the HTML 4.01 spec says about FORMs and TABLEs (relevant lines from the spec have been pasted below in a convenient order):

<!--ELEMENT TABLE - -
     (CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)-->
<!--ELEMENT TBODY O O (TR)+   table body  -->
<!--ELEMENT TR       - O (TH|TD)+          table row  -->
<!--ELEMENT (TH|TD)  - O (%flow;)*         table header cell, table data cell -->
<!--ENTITY % flow "%block; | %inline;"-->
<!--ENTITY % block
     "P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
      BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS"-->

If you’re not used to looking at DTDs, all that synax can be hard to grok. Here’s what the relevant parts of it say, in plain English:

• TABLEs must have a TBODY
• TBODYs must have a TR
• TRs must have THs or TDs
• TDs can have any elements inside them as long as those elements belong to the flow group
• The flow group consists of elements inside the block group and the inline group
• FORM elements are part of the block group.

So, what was happening was that the browser saw our FORM element defined as a sibling to the TR. That’s not allowed in the spec, so it makes some bit of sense that the browser wouldn’t pass the form data to the server the way we expect it would. After all, the browser is dealing with invalid markup here.

The Solution: The solution we found was to wrap the form input controls inside one big table that’s wrapped by the form tag, like this:

%table
  -@people.each do |person|
    %tr
      %td
        -remote_form_for(person) do |f|
          %table
            %tr
              %td
                =f.text_field :first_name
              %td
                =f.text_field :last_name
              %td
                =f.submit 'Save'

Again, in HTML:

<table border="0">
  &lt;% @people.each do |person| %&gt;
<tbody>
<tr>
<td>
<form>
<table border="0">
<tbody>
<tr>
<td>
<input name="person[first_name]" type="text" /></td>
<td>
<input name="person[last_name]" type="text" /></td>
<td>
<input type="submit" value="Save" /></td>
</tr>
</tbody></table>
</form></td>
</tr>
&lt;% end %&gt;</tbody></table>

Note: at this point we’re using a table for layout, and it’s nasty as all hell. I don’t recommend that you structure your markup this way.

But, this example illustrates is how you can use a FORM element inside of a TABLE and have it actually work. And, more importantly, now we know why we were getting an InvalidAuthenticityToken error when everything seemed like it should have worked.

Hope this helps anyone else in the same situation.