Support multiple markers with individual infowindow text

I am using GoogleMapPlugin to display multiple markers on a single map. I have implemented the code below and it does give the following result:

---

%STARTSECTION{"generatedmap"}%
%GOOGLEMAPS{
  height="450px" 
  width="450px"
  zoom="6" 
  center="34.1334, -109.2859"
  markeraddress="Canyon de Chelly National Monument
    Casa Grande
    Organ Pipe Cactus National Park"
}%
%ENDSECTION{"generatedmap"}%

The markers are displayed fine, but the text shown when the marker is clicked is always the address of last marker in the list: "Organ Pipe Cactus National Park". I can change the text by adding the infowindow parameter, but that supports, as far as I can acertain, only a single content.

What I would like to see is for each address listed as a markeraddress an associated window that, as a minimum (default), displays the actual address text given.

There are many examples on the web, that implement a JQuery interface with gmap3. The typical implementation to achieve what I am trying to do is:

values: [
{ address: "266 George St, Brisbane QLD 4000", data:"Welcome to Brisbane City Council" },
{ address: "Surfers Paradise QLD", data:"Welcome to Surfers Paradise" }
]

inside a larger implementation:

<div class='gmap' style='height:570px;width:870px' id='my_map'></div>

$(document).ready(function() {
$('#my_map').gmap3({
marker:{
/////////////////////////// infowindow follows
events: { // events trigged by markers
click: function(marker, event, context){
var map = $(this).gmap3("get"),
infowindow = $(this).gmap3({get:{name:"infowindow"}});
if (infowindow){
infowindow.open(map, marker);
infowindow.setContent(context.data);
} else {
$(this).gmap3({
infowindow:{
anchor:marker,
options:{content: context.data}
}
});
}
}
},
//////////////////// end infowindow
//////// add addresses
values: [
{ address: "266 George St, Brisbane QLD 4000", data:"Welcome to Brisbane City Council" },
{ address: "Surfers Paradise QLD", data:"Welcome to Surfers Paradise" }
]
////// end addresses
}
//////////////// zoom follows
,
map:{
options:{
// zoom: 16
}
}
///////////// end zoom
}, "autofit");
})

Question 1:
What is the best way to extend the GOOGLEMAP macro? I can see two ways:

1. Extend the current markeraddress parameter to support lines of the form: "address_test, associated_infowindow_text"
2. Add a new parameter markertext, with the same format as the old markeraddress parameter and assuming a one for one correspondence

My second question relates to the implementation of GoogleMapPlugin:
The GoogleMAP macro expands to:

<div class='gmap3' data-marker='{"values":[{"address":"Canyon de Chelly National Monument"},{"address":"Casa Grande"},{"address":"Organ Pipe Cactus National Park"}]}' data-map='{"options":{"zoom":7,"navigationControl":true,"center":["34.1334","-109.2859"],"scrollwheel":true,"streetViewControl":true,"mapTypeControl":true}}' id='mygmap3708' style='height:500px;width:800px'></div>

In short:

<div class="gmap3" data-marker='...' data-map='...' ... ></div>

This structure is then translated by jquery in the appropriate JavaScript to display the map.

Question 2: Is this method superior over the direct translation into JavaScript, which is then placed in the header, with a simple

<div class='gmap3' id='mygmap3708' style='height:500px;width:800px'></div>

returned in the location of the GOOGLEMAP macro?

-- BramVanOosterhout - 09 May 2017

To answer your question #2, Generally, it is easiest to manipulate Javascript using Javascript. So most of the JQ or JS plugins in Foswiki follow that code pattern you describe. The Perl handler executed by the macro drops an html placeholder tag into the page with some sort of metadata attached (either a class or data attribute), and then the JQuery livequery plugin is used to install event handlers that respond to the tag insertion (or removal). Conveniently, this pattern deals with multiple MACRO executions seamlessly (because it is event driven), so you don't have to explicitly support that. You CAN generate the Javascript in your Perl handler and manually update the page header using addToZone, but this is usually pretty messy and hard to maintain.

To answer your question #1, Based on your description (I haven't looked at the code for that plugin myself), it will probably be easiest to extend the markeraddress parameter expansion to something like this,

  markeraddress="address1=details1, address2=details2"

You process the parameter by first splitting on the comma, and then on the equals. Turn it into a JSON string (ex: "values: [{ address: "address1", data: "details1" }, { address: "address2", data: "details2" }]"), and drop that into your data-marker attribute. The advantages of this are:

1. It will be a minimal code change (markeraddress expansion already creates a JSON string, you just need to add an additional field), and
2. it will be backwards-compatible ("data" fields will be ignored if they are empty, so if the parameter value is just "address1" instead of "address1=details1" it will gracefully fall back to the previous behavior).

-- ChrisHoefler - 09 May 2017

I haven't tested this, but I whipped up a couple of quick patches:

• [[http://foswiki.org/pub/Support/Question1874/gmap_foswiki_edit.patch][gmap_foswiki_edit.patch] - Patch for gmap3.init.uncompressed.js. Updates the setting of the "click" event handler in the marker opts to take advantage of the context arg available in the new gmap3 version.
• [[http://foswiki.org/pub/Support/Question1874/gmap_plugin_edit.patch][gmap_plugin_edit.patch] - Patch for GoogleMapsPlugin /Core.pm. Update processing of the markeraddress parameter to support multiple addresses with optional "data" attributes (address1=data1, address2=data2).

It was a bit more complicated because the plugin JS code used an old workaround to support infowindows for multiple markers. The new version of gmap3 provides a "context" object to the click handler, so you don't need to loop over the marker values array anymore.

-- ChrisHoefler - 10 May 2017

Working patches implementing the desired functionality are attached at Tasks.Item14397

-- BramVanOosterhout - 13 May 2017

Commenting is disabled while not logged in