Drupal 5.0 update

Known issues:
* Unload is broken for some reason. (Actually, I don't think it was ever done in the first place...)
* Only the map/macro is known to be working (I have fixed the js files, but not the stuff embedded in the module file, so all other instances are currently broken)

I have not tested gmap_location, node creation, or any of the optional scripts.

Not to mention the echo "Flush!" shouldn't be there ;-)

Patch is not finished, obviously. There's a lot of javascript embedded in the module file that needs modification to work with jQuery. I was just so happy to see map/macro and garland getting along that I felt I had to post what I had so far ;-)

No, the old JS does not work with Drupal 5. jQuery takes over the $() function. All the $('form-element').value stuff needs to be $('#form-element').val() now, among other things. I spent more time fixing the javascript than the PHP, actually. Then again, I'm a lot faster coding PHP than javascript.

As for location, I too need it in a project that I recently decided to switch to 5.0 on, so if nobody else ports it, I'll probabaly end up contributing a patch there as well.

I can handle branching if you like. The great thing about the new branch/release system that was just released here is that you _can_ have bleeding edge branches. It would be great to use CVS to collaborate on this. Feel free to add me, and thanks!

I'm pretty good at working with CVS, so if anyone wants stuff back/forward ported between branches, I can do that too.

--Brandon

Here's a snapshot.

Changes:
I'm working on a jQuery way to attach the behavior. It's working nicely for the parts I have done.
Only map/macro is working at the moment, and it is slightly less operational at the moment than it was last patch, due to me not quite having all the behaviors converted over.

I'm a bit new to jQuery and JavaScript in general (but I'm one of those people who can code in just about anything given a manual ;) so if you see anything stupid, feel free to shout.

--Brandon

And now I'm switching away from using the 'settings' stuff to doing this:

$outtext.='<div id="'.$gmap['id'].'" style="'.$style.'" class="gmap-map"></div>';
$outtext.='<script type="text/javascript">'."\n//<![CDATA[\n";
$outtext.="function _gmap_load_$gmap[id](){return ".drupal_to_js($gmap)."}\n//]]></script>";
return $outtext;

That means each map compresses down to this in the source:

<div id="map" style="width: 300px; height: 200px;" class="gmap-map"></div><script type="text/javascript">
//<![CDATA[
function _gmap_load_map(){return { "": "", "zoom": "13", "latitude": "37.43411302887416", "longitude": " -122.13123321533203", "width": "300px", "height": "200px", "id": "map", "control": "Small", "type": "Map", "autozoom": false, "align": "", "tcontrol": "off", "scontrol": "off", "ocontrol": "off", "drag": "yes" }}
//]]></script>

I got a gmap to boot itself up off of this a few minutes ago. :-)

I've allocated a block of time to work on this today.

Seperate patch for the info files, because they keep disappearing.
Add the version tag.

*sigh*
Didn't get much done that day.
Working a bit more on this now...

I have nearly finished converting the rendering code to an element.
That means putting a gmap in a form is as simple as

$form['mymap'] = array(
  '#type' => 'gmap',
  '#attributes' => array('#id' => 'mymap'),
  '#settings' => array( /* array of settings to pass in... */ ),
  '#width' => 500, // in pixels
  '#height' => 500, // pixels again
);

And the settings all default to whatever the settings page was configured to be.

I'll post the patch when I'm done coding this....
--Brandon

Here's a snapshot of my progress.

* map/macro has an address field to test delay-loading the geocoder.
* I've been working on getting gmap_location into shape, but it's not done. I left in my debugging code for the time being.
* A map can now draw itself using FormsAPI.
* Geocoding ported to the jQuery based event handler.

Here's another snapshot. It's NOT WORKING at the moment, so don't bother trying to test it.

* Store all the defaults in one variable by using #tree. Comment out a bunch of defines obseleted by this.
* Moved the defaults into a function, gmap_defaults(). (Defaults being either the stuff on the settings page, or hardcoded if the settings were missing.)
* More cleanup.
* Created an install file with an update function to convert the gmap_default_* variables to the new format.
* Use array_merge() instead of large blocks of if(isset()) functions.

Everything's broken at the moment (even map/macro), but it's pretty close to working again, and fixing the other broken things will be easier and easier as the code continues getting cleaned up. Therefore, don't use this version and expect it to work.

TODO:
* Fix map/macro again.
* Look for more places to use array_merge().
* Make the map optional so the logic can be reused on the settings page to update the macro.
* Convert the long switch in the js to an extend() based version to facilitate extension writing. (The first TODO will help with this.)
* Fix map/macro again.
* Obselete the non-fapi map drawing code. (It's relatively easy to theme an individual gmap by hand, the theme function doesn't depend on fapi, so you can just build an element manually.)
* Update API.txt
* Fix all the third party scripts (Clusterer and co) -- Use the stuff from Todo #1. (gmap_clusterer.module? Making it easy to extend would mean that splitting all the third party scripts off would be a good idea...)
* Finish cleanup
* Double check all the docs
* Obselete and remove gmap_macro.js (by rolling its functionality into gmap.js -- almost there...)
* Write guide for extending gmap from javascript.

BTW:
Webgeer: Feel free to add me as a developer if you want me to handle forking for Drupal 5.

Thanks,
--Brandon

Rewrote the js again, now you can actually write new widgets and stuff without touching gmap.js.

Wrote a simple event system to make the updating work. Now all the fields collaborate using it.

Here's an example of writing widgets:

01: Drupal.gmap.prototype.handler.width = function(elem) {
02:   var obj = this;
03:   // Respond to incoming width changes.
04:   var binding = obj.bind("widthchange",function(){elem.value = obj.vars.width});
05:   // Send out outgoing width changes.
06:   $(elem).change(function() {
07:     obj.vars.width = elem.value;
08:     obj.change("widthchange",binding);
09:   });
10: }

The function gets bound to the control with the id gmap-{mapid}-{handler} (automatically)
elem points to the DOM element.
Line 4 binds a function to recieve the "widthchange" event, and sets the element's value from the width variable of the correct map.
Line 6-9 handles _sending_ the widthchange event. Note the second parameter to obj.change(). That ensures that the widget never recieves events from itself. (Can just pass undefined or -1 if you don't need to worry about recieving events from yourself)

So now, the map/macro page is a bunch of fields using events to update each other on values. And the macro field binds to every event, because every change affects the macro.

* Macros on pages and such should display again.
* Moved the settings code inline again, it just wasn't reliably getting output when using the filter.
* Started work on markers.

A couple bugfixes.
Thanks to LLyric in #drupal for the assistance.

-- Zoom does not work as a string.
-- Latitude / longitude not working right.

Next on the agenda: Fix markers.
I'm gonna find the commonalities between the default gmap marker api, Clusterer, and the new GMarkerManager and write plugin js files for this...

Sorry about the no updates. Still working on it. ;)

Right now, I'm rewriting some stuff as elements.
--Brandon

Well, I just about have markers working again. I'm defining a common API that marker manager engines can use. Implementations for no manager (add marker directly to overlay), Clusterer, and GMarkerManager will be the initial implementations.

Split map/macro marker code out into an "overlay editor."
It's not done, but points work (finally)

The new overlay editor writes its own macros. (i.e. the javascript macro creator no longer knows about "marker", and doesn't have to!) :)

Also added the ability to have more than one function on a single handler. Switched the gmap handler to this method. (So extensions can add additional behavior to the map easily)

The DRUPAL-5 branch exists at the moment (No tarball yet)

Lines are still broken. Some other stuff is still broken too. If anyone has time to review, please check the current functionality against your requirements so I can figure out what order to finish stuff up in.

Hopefully, I'll be working on it some more today.

--Brandon

http://pw.rtk0.net/index.php?q=node/69

After shuffling some code around, I finally got lines working again, both creation and display.

Just fixed the settings page for gmap_location.module. This fixed some issues I was having with the user locations stuff. So now I can work on gmap_location some more, finally..

DRUPAL-5. There isn't a snapshot yet, because I don't consider it fit for joe user yet...

DRUPAL-5 *is* branched. That's what I said. It doesn't have a snapshot node yet, so you have to check it out directly. (i.e. you can't get a snapshot tarball)

DRUPAL-5 does have .info files. HEAD doesn't.
Also, map/macro is currently the only working map at the moment in DRUPAL-5 (Just need to go fix it, it's probabaly something silly.)

If you load up latest DRUPAL-5, you'll probabaly notice all the markers getting shown in a lineup under the map. That's the start of a new marker interface for map/macro (so you don't have to go back and edit the macro to change marker types)

I agree with adding a package name.. Location or Locative is good.

Thanks,
--Brandon

Many changes behind the scenes the past week.

The marker interface is nearly there. At the moment, it supports sequences and all GIcon properties, and is able to load icon properties over a json query.

(These changes haven't hit the branch yet, I've been testing locally.)

My plans regarding the API are to make it so easy to use the elements that you won't have to use the API.

By making things easily extensible on the js side, and making it easy to create new form elements, I'm hoping to banish all the inline javascript that has plagued gmap in the past.

I'd like to have someone validate my thoughts on the JS side regarding the style of plugin programming. See for example js/align.js for a plugin. The important parts are the Drupal.gmap.addHandler, obj.bind / obj.change, and the macroparts stuff (for the map/macro page.) You can see how it adds a handler for "align" and also adds a handler to "gmap"'s handler stack to do the changes on the map side. When the map attaches itself, the relevant handlers get called against the elements in the order they were registered.

A document listing the "events" and when they happen would be nice...

Additionally, the marker manager stuff isn't finished. I still haven't finalized how they will work, and only the "no marker manager" code works properly at the moment.

The *ICON* manager stuff on the other hand is finished (except for better caching, and getting individual icons for people who have a pool of thousands of markers...) and works well. I got a little ... creative ... on the code (it does ad-hoc compression to make the JSON reply as small as possible.) It's capable of all things GIcon is capable of, and ties into .ini files in the marker directory.

I just checked in some changes to the overlay editor on the macro creator.

It now keeps track of marker types, and shifts markers that are in a set whenever a marker is removed so they always have the right icon.

It does't have the ability to edit popups yet, but that should be easier to add now.

Have fun!

--Brandon

The map blocks haven't been looked into yet, so they are probabaly still broken.

Sorry.

--Brandon

LARGE update:

Everything I've been working on recently.
* Abstracted marker loading
* Reimplemented GeoRSS (hopefully)
* Misc. bugfixes
* More.

Hopefully I haven't broken anything, this affected a lot of files.
As always, the changes can be found in the next snapshot.

Also, the location chooser should work significantly better now. I spent a bit of time working on it.

Anyone who wants to stick with the code prior to this commit until things have been tested better can hold off on updating for a bit or use the 0.5 release I made for this purpose. (http://drupal.org/node/126818)

Thanks,
--Brandon

More changes.
* Return of autozoom
* Ability to specify positive and negative behavior flags in macros.

When defining a macro, you can now turn on and off flags by writing a space-seperated string where each part is prefixed by a + or a - to turn on and off the flag.
Example:

[gmap ... |behavior=+autozoom -nokeyboard]

The current list of behaviors defined is:
'locpick' -- Default OFF -- This map is used to choose a location. Enables special behaviors for location chooser forms.
'nodrag' -- Default OFF -- Disable dragging the map.
'nokeyboard' -- Default ON -- Disable keyboard shortcuts.
'autozoom' -- Default OFF -- Pan and zoom when markers are added (Whether this works or not depends on the marker manager.)
'dynmarkers' -- Defualt OFF -- Explicitly load the marker loading code. This code is normally not loaded when no markers are defined on the map and there is no list of markers or path to fetch markers defined. Use this when you expect to load markers through some unknown method.
Not all of these behaviors may actually WORK at the moment. Also, if you think of a good idea for a behavior, go ahead and post it.

Getting autozoom working involves turning on the 'autozoom' behavior.

I think it's probabaly just a matter of changing the macro to have a '|behavior=+autozoom'.

Use the DRUPAL-5 snapshot, and wait ~12h for the changes to appear. (branch snapshots run twice a day)

New:
* Factored out the CSS ID generation so functions not using FormsAPI can use it. (gmap_get_id($map,$type);)
* Added mouse wheel zoom support (Use the settings page to diable globally, or |behavior=+nomousezoom to disable per-map)

* Mouse wheel support now requires getting a third party file yourself, due to contrib policy I had to remove the file.
* Fixed bug that was causing markers to be shown as the default marker on user/node maps, and views maps. (I forgot to handle missing sequences)
* Allow overriding the macro used to create a views map. Set $view->gmap_macro to a macro of your choice in the 'Argument Handling Code' textarea in the Arguments fieldgroup. Example:

$view->gmap_macro = '[gmap |width=600px |height=600px |behavior=+nodrag +autozoom]';

* Added new behavior to pass views fields directly through the marker interface. This allows writing custom marker handlers that work with the data from the view directly. Unless you're writing one, you should never have to use this. Anyway, set the behavior +fatmarkers to enable. This causes the marker to have only lat, lon, and markername set, and a field 'view' that contains the row from the view corresponding to the marker. Also vars.viewfields is made available with a copy of $view->field.

Mainly small changes since last report.
I just committed a change that fixes markers without shadows in IE. My check for whether the shadow was set was flawed and was attempting to attach undefined shadows. This was causing a script error.

Other than that, various cleanup.

"Hey, I was using that!" :-/

Yeah, GMap for Drupal 5 has stabilized. I'm using it in production, and am now making incremental changes instead of sweeping changes. Agreed that it's time to close this issue.

Thanks, everyone, for participating.

--Brandon