Development for 6-1.x

I have been thinking about a Layers hook structure. I was thinking about a hook that describes how to get more information about a layer:

function hook_openlayers_layer_info() {
  return array(
    'modulename_layer_x' = array(
      'name' => t('Layer Name'),
      'file' => 'some_path',
      'callback' => 'openlayers_layers_callback',
    ),
  );
}

Basically, the info hook would be a very simple array that describes the available layers and how to get more info for them. This would mostly be used in the select lists for forms.

function openlayers_layers_callback($layer_id, $layer) {
  if ($layer_id == 'some_layer') {
    return array(
      'modulename_layer_x' = array(
        'id' => 'modulename_layer_x',
        'type' => 'WMS',
        'name' => t('Layer Name'),
        'url' => 'http://labs.metacarta.com/wms/vmap0',
        'params' => array(
          'layers' => 'basic',
        ),
        'options' => array(),
        'events' => array(),
      ),
    );
  }
}

The callback would just do all the processing to get the details of the layer.

This means lots of things:

* Layers would have to be processed a lot more in the render_map() function
* A map array could just provide the layer id, instead of all the information
* The openlayers_layers hook would need to be renamed to something like openlayers_layer_handlers (but we still want this)
* The openlayers API module could provide one simple layer so that the map is working
* We can create a new module openlayers_layers that can provide lots of more exciting layers, and possibly a gui management tool
* Provides an easy way to choose layers in the map_form

What do you think?

Yes, a whole whack. First step would just be programmaticly, with hopes of creating an interface. The interface and management would be on the shoulders of the openlayers_layers module. So, the openlayers_layer module would provide a layers hook that would possibly bring in data from the database, but at first just hard-coded.

It would basically be moving the layer definitions outside the API module and into the hands of other modules. Of course, there will still be the ability to just create a layer when creating a map array.

Does that make any more sense? I am not that good at explaining things, sometimes. It might make a lot more sense when I actually start to code it. I think it will be good. And we can start to put in more fun visual layers.

The major point of having a separate module is to keep the render time down for maps. The way I envision it, the rendering of the map will call the hook which means that it could pull in a lot of data. It is similar to what yarma is talking about. It is also a lot like the Views UI. There is need to have the layers rendered or the management tool installed if you are not using it. I also see this module handling some of the layer processing hooks as well.

Though it seems like everyone would want all these layers and functionality, its not inherently true. I think it's important to have the OL API module be very bares bones, but still be able to function by itself; it should provide the interface to put everything together (with sensible defaults).

Anyway, it'll be beautiful when I am done with it; and shouldn't change the way maps are rendered, just how the map array is put together.

I was thinking that we should probably have the rendering process also involve the HTML process. Meaning that instead of the map array, maybe the render_map() should return some themed HTML.

I bring this up because it seems like we should have a class for all maps, in case someone (or we) wants to put a bordder around the maps or something like that.

Another option would be a wrapper function that return themed HTML.

What do you think?

Basic syntax for the hook_openlayers_layers_info() hook. If you look at the openlayers_layers module, it will be a good example. Please note that I have not tested this yet, just made sure that the defaults page rendered correctly.

The openlayers_layers_layers_info() (say that three times fast) implementation:

/**
 * Implementation of hook_openlayers_layers_info
 */
function openlayers_layers_openlayers_layers_info() {
  $file = drupal_get_path('module', 'openlayers_layers') .'/includes/openlayers_layers.layers.inc';
  $callback = 'openlayers_layers_process_layers';
  $info = array();
  
  // Define info array
  $info['openlayers_layers_jpl_nasa_wms'] = array(
    'name' => t('NASA JPL Global Imagery Service'),
    'file' => $file,
    'callback' => $callback,
  );
  
  return $info;
}

Whats going on here is just defining the basic information about a layer and where to get more. Since I am going to use the same function to get all these layers (that is in a single file), I am using variables for the file and callback. Otherwise, there is an ID (key of array) and a name.

Then, the callback function in includes/openlayers_layers.layers.inc:

/**
 * Process Layers
 *
 * Call back to process layers provided by the
 * openlayers_layers_openlayers_layers_info() function
 *
 * @param $layer
 *   String ID for the layer
 * @return
 *   Array formated for an OpenLayers map layer
 */
function openlayers_layers_process_layers($layer = NULL) {
  $layer_data = array();
  
  // Make sure layer is a string
  if (!is_string($layer)) {
    return FALSE;
  }
  
  // Get info array to reference title
  $layer_info = openlayers_layers_openlayers_layers_info();
  
  // Determine what data to send back
  switch ($layer) {
    case 'openlayers_layers_jpl_nasa_wms':
      $layer_data = array(
        'id' => $layer,
        'type' => $layer_info[$layer]['name'],
        'url' => 'http://wms.jpl.nasa.gov/wms.cgi',
        'params' => array(
          'layers' => 'modis,global_mosaic',
        ),
        'options' => array(),
        'events' => array(),
      );
      break
      
    default
      break;
  }
  
  return $layer_data;
}

So, in this function we are creating the more detailed layer array that would go into a full map array. The $layer argument that is passed is the ID that we defined in the layers_info() hook. So, we are checking what layer ID was passed, and then creating the correct array to return.

This is a simple implementation of the hook. If (and when) we put in a layer management interface, these values would be pulled from a database, but the hook implementation would be the same.

Specially looking at a WMS layer, it actually can hold multiple layers. So, in this instance, I am getting multiple layers with it. I am not sure what would be best practice: do we put each sublayer into its own layer array? Also, I got some positive feedback about getting the WMS administrative features out of nice_maps: #425930: Abstracting WMS Functionality

I am going to work on putting this into the defaults form tonight, and it might make it all even more clear. And, at that point, it might be good to put the ol form into the CCK widget settings.

My work was broken, but through proper testing, it has been fixed. I also added in support fo picking layers in the defaults form. I also changed the example in the ol_layers.module. The same principles still apply:

/**
 * Implementation of hook_openlayers_layers_info
 */
function openlayers_layers_openlayers_layers_info() {
  $file = drupal_get_path('module', 'openlayers_layers') .'/includes/openlayers_layers.layers.inc';
  $callback = 'openlayers_layers_process_layers';
  $info = array();
  
  // Define info array
  $info['openlayers_layers_nasa_global_mosaic'] = array(
    'name' => t('NASA Global Mosaic'),
    'file' => $file,
    'callback' => $callback,
  );
  
  return $info;
}

/**
 * Process Layers
 *
 * Call back to process layers provided by the
 * openlayers_layers_openlayers_layers_info() function
 *
 * @param $layer
 *   String ID for the layer
 * @return
 *   Array formated for an OpenLayers map layer
 */
function openlayers_layers_process_layers($layer = NULL) {
  $layer_data = array();
  
  // Make sure layer is a string
  if (!is_string($layer)) {
    return FALSE;
  }
  
  // Get info array to reference title
  $layer_info = openlayers_layers_openlayers_layers_info();
  
  // Determine what data to send back
  switch ($layer) {
    case 'openlayers_layers_nasa_global_mosaic':
      $layer_data = array(
        'id' => $layer,
        'type' => 'WMS',
        'name' => $layer_info[$layer]['name'],
        'url' => 'http://t1.hypercube.telascience.org/cgi-bin/landsat7',
        'params' => array(
          'layers' => 'landsat7',
        ),
        'options' => array(),
        'events' => array(),
      );
      break;
      
    default:
      break;
  }
  
  return $layer_data;
}

I have also created a field in the default form for the Default Layer, but I have not really thought about how to implement this. I have not looked at how OL actually does this. Any ideas?

Awesome! I will take a look, and try to add the open layers settings form to the widget. I haven't looked at the CCK module for a little while.

I think we should revisit what we want to happen in order to release a dev, alpha, beta, and/or 1.0 versions. I think two big features to get going before we release an beta version:

* CCK Formatter for the Geo Field.
* Views Plugin (we can look at GMap and Nice Map for good examples)

I think both of these features will depend on a good system of adding features to a map via the map array. After that, I think its just a matter of finding bugs and cleaning up code.

I think Layer Management GUI should be post 1.0 (there is already good layer management in the code).

FYI, I put our module into my API site. This means we can see how our inline documentation is. But, I have to manually update it at the moment, so it'll be good when we are cleaning up documentation and not something we can use easily in our process. Also, you can't really browse the project.

* http://api.zzolo.org/api/file/drupal-6-contrib/openlayers/openlayers.mod...
* http://api.zzolo.org/api/file/drupal-6-contrib/openlayers/modules/openla...
* http://api.zzolo.org/api/file/drupal-6-contrib/openlayers/modules/openla...

As far as providing a theme for the HTML of a map, I added $map['themed'] to the rendering process. It is added after the map is added to the JS settings as it seemed like there was no need to provide it to JS.

I agree, it does get a little confusing.

The Layer Type is important, but the hook_openlayers_layers_handler_info() is for defining handlers for the Layer Types. So it may be more appropriate to call it: hook_openlayers_layers_type_handler_info()

I think info is a good suffix because it used in other Drupal places, and usually means that we are just compiling an array of information on what to do when more details is needed.

I like this way of only defining the layer handling, because it allows for lots of flexibility in defining layers and how they get processed. In theory someone could use a layer with type "WMS_extended", then define the handler with the hook, and also add as much information to their layer array and process it accordingly.

Also, I believe that if a Layer Type Handler is not found, then the map renderer does not actually include that data. I may have to double check that.

As far as the other hook, I would describe it more as Available Layers, since they are not automatically included in maps, just available to include. But, as I write this I think Layer Instances is probably a good solution. So maybe the hook could be: hook_openlayers_layers_instance_info()

--
zzolo

Just a note on the blur events of the WKT fields. Currently it is using JQuery but this method does not handle the "Add Field" AHAH event. This needs to be addressed.

On 4/17/09 2:06 PM, Patrick Hayes wrote:
> Thanks for the tweaks to
> openlayers_cck. One thing: I purposefully didn't use jquery for the onblur
> event. When someone does a "add new item" to get another field, Drupal
> reloads all the fields via AHAH / AJAX, and so looses any events attached to
> the fields. You'll note that now if you add a new item, and then edit the
> text in any of the fields, the polygons on the map do not update like they
> were before. The only way I could think of remedying this is to add the
> onblur event in openlayers_cck.module, instead of using jquery. If you have
> any more elegent solutions please let me know!

Great work, Patrick. I have not looked at the anything yet, but will in a moment. A few things:

1) Defining layers and implementing the layer_info hook. I am definitely open to discussion, but I think we need to keep those definitions in the ol_layers module and not in the API module, and here is why:

* The OL API module should be just that. A set of functions and methods to bring together definitions and data. It should handle the array, not defining what is in it. The exception here is very simple sensible defaults, with the only goal being that if someone called render_map() (withonly the API module installed) it would actually render a map (with a default layer)
* Every .module file is loaded on a Drupal page. I think its really important to separate out functionality and "data" (definitions) in this case, because there can easily be the case where someone wants to streamline their site and only define a couple custom layers. If we keep basic layers in the API module, then those will always be there.
* Example: CCK comes with FieldGroup. There is pretty much no reason not to install FieldGroup, but it is still separate functionality and thus in its own module, and it would help performance to uninstall it if it was not being used.

2) This ties into the "default_wms" layer and how it is the only exception in my opinion. I think it should be a regular definition like you have done. But it needs to be handled such that if no other layers are present, then the "default_wms" is included. Basically, it is part of the sensible defaults and is an exception.

3) Projections: Does it make sense to define a projection for the map, and have the layers support specific projects? This could ensure that only layers that supported the projection be included in the map. Also, how variable are projections? Is it something we should make a hook of?

--
zzolo

As far as Projections go.

1) Not sure how you have done it so far, but it would probably be a good idea to keep projections as string: '12345' not 12345. This is because it will be mostly used as a string and PHP handles integers different when they are the key to arrays.

2) The way you have the map error checking is fine, but I was thinking of something different. Since we are already going through the layers in the process method, we can stick the logic in there to check against the map projection. I also think there is no need to set a message. There are three main ways someone will create a map:

1: Sensible Default. We have control over this.
2: Customizing Form. I think we need to put in choosing a projection, and have it update the available layers in the drop down. This would ensure that people can only choose things that are compatible.
3: Programmaticly. Then they should know what they are doing.

So, I don't think there is any reason to display that message. I think it'll confuse the end user if it appears. We can log it, though.

As always, good job.

Great work. I have not looked at the code yet. I like the features a lot. I'll have to think about the Behavoirs thing a little more, but sounds pretty good.

For creating a Views Plugin, there are a few modules that have already done similar things:
* http://drupal.org/project/mapstraction
* http://drupal.org/project/gmap
* http://drupal.org/project/nicemap

I like the idea of having the Views Plugin in another module, but Views actually does a really good job of allowing you to tput your code in a different file, sp I am not sure if it is necessary on the performance side. Any thoughts?

I see what you are saying about the default layer. And I think just including it if there are no layers (maybe non-vector layers) is a good way to go. The goal is to make it so that a map works without setting anything up.

Just a note. We are one of the most actively developed modules on Drupal at the moment. Not sure how often the stats update, but cool.

http://drupal.org/cvs (block on the left)

I would say that we could release a dev version right now. This is the time line and major actions I see that need to happen for each step.

* Alpha: After we have fleshed out the views plugin a little.
* Beta: After we have pegged down the API, reviewed logic and functionality of code, and written tests
* RC: After any outstanding bugs have been squashed and we run it through coder
* 1.0: After Full documentation and any bugs are fixed.

Given what we have, I predict the Beta being pretty solid and usable.

Patrick. I remember you mentioning how something weren't updating when Drupal did some AJAX things. I am not that well versed in it, but we probably want to change all our document.ready function to Drupal.behaviors function and this might address that sort of issue.

See http://api.drupal.org/api/file/developer/topics/javascript_startup_guide...

Hey phayes,

I am just starting to go through the code (there's a lot). I was wondering why you made a separate API function: openlayers_prepare_map() ?

I took out the prepare_map function and just put those steps in the render_map api call. I also added some switch arguments so that you can call it and not go through the JS steps.

I Also changed how the default form was working, both through its check of errors, and how it gets it defaults. I creates new function: convert_map_to_form to create defaults for the form from the system default map. It needs work, but at the moment, there are some defaults in form, so it should make more sense to users.

I am having some problems with some of the values not showing up in the fields. I think this may have to do with some JS. I will look into it more.

JS Namespaces!!!

So, I jsut read Drupal JS and jQuery and its so great! One of the things I picked up in it is namespacing. Not to say I didn't know about it before, but I got to see it used well.

One suggestion in the book is not to use the Drupal settings namespace, but we are a little too entrenched in that approach.

But, I would like to start using the "OL" namespace for functions. this will make things look prettier and we should be able to get out of using the Drupal.settings namespace except for getting data from PHP. I am still thinking about how to do module contributed functions when hooks are used. Any ideas or thoughts?

I am committing my changes to the openlayers.js file so you can start to see how it might work.

Some further uses of a namespace.

* Change all "Drupal.openlayers.activeObjects" to "OL.maps" (this alone will save lots of characters!)
* Change "Drupal.openlayers.mapDefs" to "OL.mapDef"

What I have been doing and am going to commit.

* Went through ol.module and ol_layers module and fixed a lot of formatting and some various logical things. Nothing major.
* The base API module should be mostly solid and ready to go (except for defaults form). It still should be run through Coder and Coder Tough Love, but should be a good example of formatting, documentation, coding practices at this point.
* Totally changed the JS namespaces for the base ol.module
* Changed namespace for layers and layer handlers.

So, now things are like this. Notice the new layer_handler:

function openlayers_layers_openlayers_layers_handler_info($map = array()) {
  // Define Layer Types that won't be used outside of this module 
  // such as Google Maps, Yahoo Maps, and MS Virtual Earth
  $js_file = drupal_get_path('module', 'openlayers_layers') .'/js/openlayers_layers_layers.js';
  return array(
    'KML' => array(
      'layer_handler' => 'KML',
      'js_file' => $js_file,
    ),
    'XYZ' => array(
      'layer_handler' => 'XYZ',
      'js_file' => $js_file,
    ),
    'Google' => array(
      'layer_handler' => 'Google',
      'js_file' => $js_file,
    ),
    'VirtualEarth' => array(
      'layer_handler' => 'VirtualEarth',
      'js_file' => $js_file,
    ),
    'Yahoo' => array(
      'layer_handler' => 'Yahoo',
      'js_file' => $js_file,
    ),
  );
}

And on the JS side:

/**
 * Process Google Layers
 */
OL.Layers.Google = function(layerOptions, mapid) {
  var mapType;
  if (layerOptions.params.type == "street"){
    mapType = G_NORMAL_MAP;
  }
  else if (layerOptions.params.type == "satellite"){
   mapType = G_SATELLITE_MAP;
  }
  // ....
}

Major To-Do's:

* I was not able to address the cck, views, or behavoirs module, so things are broken, given these changes.
* The setting form needs love. Its a good start and is powerful, but
** It seems buggy (I have made it kind of buggy, sorry)
** Does not properly use Drupal's built-in AHAH
** Does not fully support default_values
** The idea of sensible defaults is there, but I think we need to focus on easy changes. I think the biggest thing that most people will want to do is add on cool layers, so we need to ensure that this can be done with ease.

Also, this is probably just an old habit to break but for conditionals, there should be a space between condition and opening bracket, for PHP and JS:

if (condition) {

}

Quick helpful command to see changes in CVS that look like "svn status" output.

cvs status 2>&1 | egrep "(^\? |Status: )" | grep -v Up-to-date

"only_these_layers":
I am not entirely sure what this is doing. But what I think it is doing is a way to switch off the default system layer. I think what needs to happen is just a way in the rendering process to not include the default system layer if layers are provided. Basically, the default layer is there if nothing has been changed, but as soon as the user has saved some defaults or is rendering a map from code, then we should ignore our layer. The other settings can be overridden.

"Form Defaults in Description"
I think the key to all this is to make the settings form very descriptive and in those description tell the user what is the system default, so that in theory, they could just use those values to reset it.

"Naming":
I do like OL.LayerHandlers. I think Behavoirs is fine. I think you may have missed the point of namespacing, though, which is to keep things grouped together and shorten code. You did the following:

OL.Behaviors.openlayersBehaviorsDrawFeatures = function(event) { }

You see how it is redundant. What it should be is:

OL.Behaviors.drawFeatures = function(event) { }

"CCK Events"
Drupal.behavoirs to the rescue! Since openlayers rendering happens inside a Drupal behavoirs, all we have to do is call Drupal.attachBehavoirs after we have done our CCK stuff. Pretty awesome.

"$Id$":
Just noticing that seems to be missing from some files. The string "$Id$" needs to be at the top of all files, in a comment. It is used by Drupal's CVS to replace with relevant repo data. Not need to change it once it has been in there.

"My Changes":
I did a lot of work on the CCK and Behavoirs. Lost of formating and docuemntation and renamed functions and stuff. I can get a CCK field without errors but I have no controls, nor can I input anything. I am committing what I have though.

Loading maps need to account for existing maps.

The OL.loadMaps function need to behavior in a more event driven manner. Meaning that it currently just starts over and loads all the maps in Drupal.settings.openlayers. But it should account for possible new maps that might join the page through AJAX or similar JS event. Basically it needs some way or marking maps as rendered and not resetting the OL.maps each time. This will ensure that anytime Drupal attachBehavoirs is called, things are not reset.

I just thought about this as I was looking at the code, then was testing the CCK module which attachBehavoir each time a new field is loaded, and it has some funny results. I think this is the bug you were running into phayes.

Fixed. Pretty simple. I just added a rendered variable to the OL.maps array and just checked for it before rendering.

I am currently working on the settings form. I am trying to make it simpler and use Drupal's AHAH functionality. Should commit something tonight.

Finally committed all my changed for the Settings Form. It took me a while to figure out Drupal's AHAH form stuff, but I got it. (http://drupal.org/node/331941)

So, major changes.

* Overall, more simpler, more elegant
* More logic is pusdhed into PHP side of things
* I put Projections, Layers, and Options at the bottom and collapsed.
* By changing the Projections, it will update the Layers and Options accordingly
* Options now have an Automatic checkbox. This basically fills in the Options if checked.
* On the JS side, the Center Map is working fine now.
* I also moved something into the theme level (and created a new theme file)

Please test. I had to commit each file so that I didn't change any existing changes, but it should be fine.

One thing to note is that the submit handler is called with each AHAH trigger. This means it is saving it as someone is picking things. This could lead to problems.

--
zzolo

So, I was thinking about things running into problems with the Settings Form and defaults, and it occurred to me to switch from an idea of Merging Maps with Defaults, to simply overriding them. This means that we use the system default if no default has been saved in teh defaults form.

I have created a new public API function that just simply checks for the save default map in the variables table, or gets the system default if the variable is not found:

$default_map = openlayers_get_default_map();

I have update the defaults form and CCK to do things in this manner.

I had a pretty great idea in the shower today. I think we should move to using map presets. This would be similar to something like imagecache presets, or basically like gmap macro creation page, but being able to save it. It would require a different interface for the admin, and may be a fair amount of work if we want it in before 1.0 (but the module is still in dev). Here are the wonderful benefits:

* Easier to set a default.
* No need to reuse the complicated Settings Form in different places (like CCK or Views)
* Allows for "exportables" a lot easier
* Could allow for caching easier in the future
* Would allow for inline maps a lot easier that macros, like GMap uses

What do you think?

@tmcw,

Thanks for the comments. Presets are definitely going to happen. I am currently trying to update the CCK part to work with the new Geo, though it may be futile at the moment, so maybe I will just switch to map presets.

I am a little confused on the things you are referring to here.

that doesn't mean that it'll be user-unfriendly, but rather that stuff like KML layers with Strategy.BBOX() enabled, or any combination of layer, format, and option, wouldn't require hacking (as it has for me).

I am not sure why you would need to hack anything (the goal is not to). If for some reason the hooks for specific things don't work, there is always the final alter that is done, and there are plenty of events to hook into on the JS side. I would love to hear more about specific places you are thinking need to be extensible; I am sure I can't see all the use cases.

Thanks,
zzolo

@tmcw

I am glad things are looking better. First off, don't trust the documentation at this point; it has not been updated in a while. Second, you should be able to register an event in the following manner:

PHP side:

<?php
  $map = get_map_array();
  // In events key, use the custom triggers, then put in an array of callbacks
  $map['events']['beforeBehaviors'] = array('CCKProcess');
?>

JS side:

OL.EventHandler.CCKProcess = function(event) {
  var mapid = event.mapDef.id;
}

This is what I am doing in the CCK module to create all the extra handling of fields with the map. You should be able to add custom controls at this point. I would like to rename and re-asses or add where custom events are at some point.

Also, I have updated the CCK stuff for Geo-ish changes. It works for a single value, but is broken for multiple values. I started creating the preset interface. Going pretty good, mostly borrowing ideas form image_cache.

@tmcw

No, at the moment, it has to be registered in the map array first. This makes it easy to put multiple callbacks to a single event. Phayes had implemented this, but I will take a look at it and see if we can't make it a little more flexible.

For now, if you are writing custom JS, you can write a simple custom module that uses the hook_openlayers_map_alter() and add your event registration there.

--
zzolo

Big huge commit: http://drupal.org/cvs?commit=230092 (then plus the stuff I forgot)

Large Commit:
* Added Preset UI module. This allows the user to make map presets.
Presets are now used to manage and display maps
* You set the default Preset in the base OL Admin settings
* Updated Views PLugin to use a Preset
* #485298 by jer: Added support for CloudMade Tiles with the style
option
* Lots of various formatting fixes
* Various small bugs
* CCK And Geo stuff is still broken

So, phayes and I talked in IRC about the main things that need to happen before 1.0. So, I'm gonna go through a small roadmap here:

For ALPHA:
-----------------------
* Styles need reviewing
* Popups
* Smooth out Views Plugin
* Squash bugs

For BETA
-----------------------
* Tests (Should have done first)
* Coder and Coder Tough Love

For RELEASE CANDIDATE
------------------------------
* Squash any existing bugs
* Documentation (Inline and External)
* Demo
* Sweet looking themed controls as default

For 1.0
------------------------------
* Squash any bugs

I have been thinking about possibly making a Geo-independent CCK field. I know this module should not really get into storage but there are two main concerns I have that this would address:

1) When will Geo be stable?
2) How much overhead will Geo have

Basically, this will allow users to store very simple data and have limited functionality with that data. I definitely think that we should push for Geo, but in the meantime for this. It would be fairly easy since most of it is set up for the Geo field. Also, creating a tool to migrate that data to a Geo field should be pretty easy, shoudl we have to support that. Any thoughts?

So, all in all, we are pretty close. I am hoping to tag an ALPHA this weekend. I am very ready to get this module stable and enjoy my summer. Thank you all for the wonderful work.

@phayes

I notticed you changed how the Default map preset was getting put into the database. I did nto have this problem, but it was because I was using the Devel's reinstall functionality, which is awesome, but since the uninstall and install happens on the same request, the functions from the module are still available.

The problem, ultimately was because during the install process, the .module file is not included. So, openlayers_save_preset() is not loaded. I first just dedicded to make a sopy of that function in the .install file, but I believe there is something up with drupal_write_record in the install process as well (not data to back up). So, I just did a manual DB Insert.

Should be working now from the install process.

Maybe further down the line, if the whoel default preset becomes a problem, we can look into hook_requirements.

--
zzolo

Just committed fix for bug that makes the styles actually work, as far as the map preset interface default styles go.

I have changed the 6--1.x version to use the DRUPAL-6--1 branch, instead of HEAD. This will allow for us to make a 7.x version or a 6--2 version in the future.

Released ALPHA2. Main thing is that the WKT Field CCK works for a single value (did not look at multiple values). The formatters should work as well, but need to take into account multiple values. You can also choose which feature types to allow for the widget.

Next main fixes:
* WKT Field for multiples
* Popups

ALPHA3 main changes:

* Grouping in views
* Much better handling of coded presets
* New hook: hook_openlayers_presets
* openlayers_presets provides a layer that uses Drupal's cache
* openlayers_get_presets is still used to get presets, but as a wrapper
* Instead of saving preset in database, the default map is just an implementation of the preset hook
* Coded presets can only be cloned and exported (not edited or deleted)
* I decided to use the default Drupal cache table to store data since this is not a huge amount of data
* Oh, and also, the map UI form now merges the original data with the new data from form, meaning that there was any data that the UI did not account for, it will still be saved.
* Overall, this should make things like integration with Features much easier
* Testing is always appreciated

WKT CCK and Popups, then beta!

Just an update on roadmap and things that need to get done:

For Beta:
------------------------------------------
* CCK stuff (close)
* Fix any existing bugs
* Documentation
** openlayers.api.php (hooks)
** theming, some basic information at least
** Map array
** Changelog.txt
** any other stuff we can fit it

Once Beta, Patrick and I decided we will support any changes to the DB structure, but not to functionality.

For Release Candidate
------------------------------------------
* Fix any bugs that come up
* Tests (should have done first)
* Documentation
** Finish any documentation that belongs in the files
** Provide external documentation
** Provide API inline documentation site (I can put this up at a subdomain)
* Ideally I would like to have a more visually pleasing set of controls, but I am not sure if this will happen.

For 1.0
------------------------------------------
* Fix any bugs
* Provide Demo

Ideally we want to be at at least RC for Paris, Drupalcon. I am not sure if my presentation will be picked, but I put in a proposal for an OpenLayers session. Depending on our time, we should start a 7.x version after Paris.

So, I got the CCK stuff working for the WKT Field. Basics:

* Allows for any combination of feature types
* It now uses a single textarea as the visual input. This is using a GEOMETRyCOLLECTION so that it can be copied and be standardized
* Data is actually stored in a hidden input field. This is done becuase the GEOMETRYCOLLECTION syntax is really hard to parse to get the features out of it.
* The field handles any allowed values. If there are a specified amount of values, any features added will replace the last one added.

Known problems
* Views data needs to be accounted for. Since we using our own handling of multiple values.
* Did not try integrate with Geo

Overall, this seems a little hackish, but it is by far the best solution that we have come up with. CCK does not make it all that friendly to do what we are trying to do: have a single input for multiple values. Testing is encouraged.

@ReinoutS

* This module is still in heavy Development
* Make sure you have a firm understanding of Views and CCK first
* You should be able to add an OpenLayers CCK field, as well as use an OpenLayers views plugin
* This is not the correct place to ask this question, please start a new issue.

--
zzolo

http://drupal.org/cvs?commit=247418

Just ran everything through Coder, with Minor warnings on and Internationalization on.

I beg you guys to try to run this before committing any new code. It will save me form ahving to spend 3 more hours getting rid of white space and change "){" to ") {" (I'm looking at you Phayes :)).

I am gonna work on some documentation now.

http://drupal.org/cvs?commit=247430

I made some major changes to the documentation in the docs/ directory.

API.txt
* Points readers to other files
* Lists out the major public functions found in openlayers.module. Note that this just gives a very brief description. There is no need to duplicate the inline commenting

HOOKS.txt
This is just a directional sign, since most people may not think to look at openlayers.api.php

openlayers.api.php
This is the doxygen formatted inline documentation for the available hooks for openlayers. This can get parsed by the drupal api module.

THEMING.txt
Like the api.txt this provides a very brief overview of the available theming functions. Again, no need to duplicate inline commenting that should be adequate.

MAP_ARRAY.txt
This still needs lots of work. I am not sure the best way to go about this one. There is a lot of needed information, but I don't want to necessarily put it all in a text file like this.
* Maybe we can put it in douxygen format and make sure drupal api will read it
* Put it in Advanced Help format
* Keep it in plain text
* Any ideas?

I have updated my API site (api.zzolo.org). You can browse the hook code here:
http://api.zzolo.org/api/file/drupal-6-contrib/openlayers/docs/openlayer...

Pushed first Beta through (even though there were still some bugs out there). I also wrote up a big post on my blog to help get some buzz going: http://zzolo.org/thoughts/drupal-and-openlayers

These are things that I feel need to get done for a 1.0 (as well as just time to allow for bugs to be found)

* Squashing any bugs
* Testing
o We need people to start using the module and see how it works for them
o I also want to have at least a few SimpleTests done before a stable release
* Documentation
o Text-based documentation in the module needs to be finished up
o It would probably be better to push documentation to Advanced Help
o Any further documentation like handbook pages or screencasts would be wonderful
* Stylish Controls
o My personal goal is to get some stylish controls for the module to have by default. OpenLayers default controls are alright, but they won't win any hearts, and design goes a long way.
o Any designers out there want to help? (I have little to no design skills)

Thanks for all your hard work, everyone!

I put in integration with the Module Builder module. See #406538: Module Builder Hook

Though this module is still in heavy development, I was the one who suggested the hook, so I figure I sort of had to be the one to start using it. I think its a good ideas, but could use a little work; I think the Module Builder module could really be something great. Either way, its a very minimal implementation and does not add any code to the .module file.

Changing name to reflect new issue for other branches.

I was going through some bugs and noticed some things about the context styles and clustering that I believe Bryn worked on.

1) Using eval() which is really bad.
2) Spacing and indenting is off.
3) If..else structures needs to be complete with curly brackets, even if they are not technically needed.

JS coding standards:
http://drupal.org/node/172169
http://www.stellapower.net/content/drupal-js-coding-standards-final-version

I will admit my meticulousness about all this, but we have come this far with doing a pretty good job of sticking to standards, so it would be awesome if it could get cleaned up.

I am just noticing that a new drupal_alter was added to the render_map process and am confused by this. I believe phayes did this.

1) What is the use case for this? A drupal alter is pretty expensive, and anything that needs to be altered can still be altered after processing the layers, styles, and behaviors.
2) It seems that the later drupal_alter was renamed, which will probably break anyone's code that is currently using it. If this pre alter is needed, it should be the one that is named differently.
3) The drupal_alter for the map should be viewed as a last resort. Again drupal_alter is expensive, and if everyone seems to be using the map alter, then we are doing something wrong.

Personally, I would like to see this removed, but would like to hear what your goal with this is, phayes, and anyone else who has opinion.

I screwed up... twice.

1) I tried to change some eval statements and did not test. (http://drupal.org/node/432642#comment-2034806)
2) I changed the hover behavior on popups thinking it would just affect the feature hover, but it messed up the popup behavior all together. Again did not test.

My apologies. I will fix these soon. It was very bad development practices.

Just an update on the the impending 1.0 release. This is what I am thinking is left to do to finally get this out the door, and just support bug fixes, and focus mostly on 2.x:

Status or changes:
* I am conceding the #555992: 2.x: Stylish Controls or A Theme System?
* Things are up to date according to Coder. Closing #583562: Coder for 1.x
** Please continue (or start) to run Coder through your commits first.
* #447686: 2.x: SimpleTests! Tests are still important!

To do:

* Features-Task-ish:
** #528952: Do not show empty map when views result is empty
** #555978: Handbook Page Documentation for 1.0 - I think we just need to add a little bit here. I think the handbook pages are a good place for recipies or more advanced tips, and that the internal Advanced Help should have all the basics of the module.
*** #564432: Import KML
** #555976: Advanced Help Documentation for 1.0
*** #587392: Guide users to custom builds for deployment.
** #583556: Clean up JS for 1.x
** #567898: 2.x: Temporary styles for hover events - I would argue that this could just be pushed back to 2.x, or added in a later 1.x version.
** #570236: 2.x Port: Support Domain Access module for Layers Keys and Main Settings
** #570292: 1.x: New Behavior: Click to zoom - This doesn't seem all that important. Can be moved to 2.x

* Bugs
** #519492: maps won't display in collapsible fieldgroup or other hidden div
** #586944: zoom_to_layer does not work for closed linestrings
** #592816: Cluster behavior does not work with two layers
** #592808: Views arguments break custom styles
** #566452: Openlayers causes php warning when adding a new item for a different multi-value cck field
** #566456: hook_features_api is broken

It looks like a lot, but it all seems like small discrete tasks. But It think we can move to release candidates once we get the bugs worked out. So close! Thanks for the great work, everyone.

I would definitely say that we can go to a release candidate. The main thing, IMO, that is holding up the final release (besides fixing bugs) is documentation. It seems like a lot of the problems people are having are similar, and we can do a lot up front by creating good documentation. I think the best documentation we can do right now is to create map preset examples, and how to add/override layers/behaviors that are not available in the preset interface. I would also like to see #598206: Localize happen, not that it is much work.

Open 6.x-1.x issues:
* http://drupal.org/project/issues/search/openlayers?text=&assigned=&submi...

Most of these are support requests. The only bugs are the ones that tmcw listed above.

(Sorry for being MIA for the past while, I am moving out of the country in a couple weeks and it has gotten me pretty busy. I should be back in the full swing of things in the next few weeks.)

Just an FYI (http://drupal.org/node/592816#comment-2332700), I updated the clustering code pretty significantly and it will probably break whatever someone is currently using.

Released another beta: http://drupal.org/node/668378

Lots of good bug fixes in there. Great work, all. I chose another beta because we still have bugs in the queue.

It looks like there are a couple bugs that are holding us up:
* CCK and multiple values (a few issues here)
* Browser compatibility (a few issues here)

Both of these issues kind of suck. I am definitely getting tired of the 1.x branch and would much rather be working on the 2.x, but I still want to get a 1.0 out. I 'm gonna try and put a lot more time towards it both versions this week, and hopefully get at least an rc1 out for 1.x.

OK! So, there are no bugs for 1.x and only a couple feature requests and support. I am sure some of this is caused by the fact that 2.x is getting much better and more widely talked about.

Anyway, let's do the 1.0. Here are my thoughts on what should happen beforehand:

* A coder run.
* A JSLint run
* Clean up Advanced_Help documentation. No need ot complete it, just make sure what is there is accruate.
* Release it! (and then suggest that people start using 2.x :)

Thoughts/Concerns?

That's a good catch on the TODO's, but personally I would rather just push it under the rug. :) Awesome, it seems like 1.0 is near ready!

So, ran through coder, and everything is fine.

Still running through JSLint, and have found this:
* #730778: Use of eval() in Context Styles

Ok, I went through it all to the best of my ability and things are better. Most of the stuff that JSLint catches is not that big of a deal.

So, if we could get someone else to take a look and sign off, I say, let's do the 1.0 (and finally close this ticket)!

Also, I made a few more test maps, which should make testing a lot easier.

I'm gonna try to push out a 1.0 tonight (or at least an rc2) and then I think we should stop support for 1.x, though still excepting patches of course. This means updating the project page to make it all more obvious about using 2.x. If I don't hear any objections in the next week, I will go ahead with this.

OK, so, I pushed out a RC2. There are a few minor issues in the queue. As disappointed as I am to not actually push out a 1.0, I think its best to just leave in current state and maybe someone will come along with time to dedicate to addressing these issues.

I have also updated the project page to better reflect the shift to promoting 2.x fully.

Closing.... *sniff*