More robust Macro handling in GMap Views

I have been using GMap module for a number of different sites that do mapping in both Drupal 5.x and Drupal 6.x. In the beginning of the summer I was working on a project to upgrade Open Green Map (OGM) from 5.x to 6.x. where I noticed that the changes between Views 1 and 2 changed a key way GMap Macros are passed to the View. This change broke a method that was used on OGM, as well as a different site still running D5 that I built long before touching OGM. That method allowed custom macro building on an Organic Group basis, but could have been used for many other things.

Under Views 1 in D5 the method worked something like this. Lets say I have an OG content type "group" and in that content type is a text field where users paste their own GMap Macro, which they get from the Macro builder. I build a view that uses the nid (gid) of the group node as an argument. The way Views 1 views were built allowed me to then add something like this to the argument handling code, which would pull the gmap_macro_field and set it as part of the view object.

if ($args[0]) {
  $query = db_query('SELECT nid FROM node WHERE status=1 AND type="group" AND nid="%d"',$args[0]);
  if (db_num_rows($query) === 1) {
    $node = node_load(db_result($query));
    $view->gmap_macro = $node->field_gmap_macro[0]['value'];
  }
}

This all changed in Views2. This method simply won't work anymore. So what I am requesting/ proposing is that a model be developed for allowing dynamic GMap Macros to be passed to a view.

The only exploration of this idea that I have done is essentially a hack to the gmap_plugin_style_gmap.inc file, which is what is currently running on the Open Green Map site. In the file (CVS r1.9), the macro and map is themed around line 140:

if (!empty($markers)) { // Don't draw empty maps.
  $map = gmap_parse_macro($this->options['macro']);
  $map['markers'] = $markers;
  $output .= theme($this->theme_functions(), $this->view, $this->options, $map, $title);
}

What I ended up doing to meet my needs was to change the way that the $map variable gets defined. This code example is not a proposed solution, since it is far too site specific, but it does pinpoint the place where a change could be made. In this case we are again dealing with Organic Group gid as an argument, however the macro is built using the values of several fields, so the macro is put together in a custom function, which gets set as the variable $macro.

if (!empty($markers)) { // Don't draw empty maps.
  // TODO: need to replace this hack which maintains custom zoom level
  //   with a long term solution
  $arguments = $this->view->argument;
  foreach ($arguments as $argobj) {
    if (is_numeric($argobj->argument)) {
      $gid = $argobj->argument;
      $macro = group_map_gmap_macro($gid);
    }
  }
  if ($macro) {
    $map = gmap_parse_macro($macro);
  }
  else {
    $map = gmap_parse_macro($this->options['macro']);
  }
  // End hack;
  // $map = gmap_parse_macro($this->options['macro']);

  $map['markers'] = $markers;
  $output .= theme($this->theme_functions(), $this->view, $this->options, $map, $title);
}

This code essentially checks for a macro and uses that, or the module's default handling.

What I am trying to get at with all of this, is a more robust way to pass a macro. I am not entirely sure as to the form that this should take, which is why I don't have a patch to go along with this request. A couple of options that I can think of are a hook that gets called right as the $map variable is about to get set, as a way for other modules to intervene and provide a macro. Another option would be to allow the macro field for the view to have php handling code that would provide a macro.

I'm happy to help with crafting the final patch once this has been discussed and thought out by people besides myself.