The attached patch provides a cck-field for adding a google-map to a node.

There's yet work to be done to define some smaller map-views for teasers, but since I didn't need that right now I've postponed it for a bit.

I know you diverted my gpx-patch to the tracks module, but I have no intension on working on a module where half the function names are in french and the other half is undocumented.

If there's interest I'll follow up with a patch allowing this gmap field to show a gpx-file from a file-field in the same node to be displayed as a track, otherwise I'll keep that in my private branch.

Comments?

CommentFileSizeAuthor
#8 gmap-macrobuilder-hidefields-1.patch1.46 KBray007
#1 gmap_macro_builder.module.patch1.1 KBbdragon
gmap-ckk-field-1.patch18.78 KBray007

Comments

bdragon’s picture

bdragon commented
StatusFileSize
new gmap_macro_builder.module.patch1.1 KB

Regarding the change to the macro builder:

How about this instead?

Thanks for your work on gmap!

The other thing I noticed is that the documentation in the new files seems to be the hook docs instead of implementation docs. Other than that, looking good.

--Brandon

ray007’s picture

ray007 commented

Your change looks fine, I can do that for the next version. I just tried to make my changes to existing files minimally intrusive.
If changing gmap_macro_builder_form() is ok I'd also like to give it a second parameter for hiding some of the input fields, so I don't have to do that outside after calling gmap_macro_builder_form() ;-)

And yes, the docs are mostly the standard hook-docs, i still need them myself to look at when coding ... will update (or remove) those later.

What I'm missing in your answer is a comment about gpx-support.

Thanks for taking a look at this.

bdragon’s picture

bdragon commented

What needs to happen is a generalized gmap_macro_builder_form... I know other places it could be used...

I'd love for it to be combined with the "default settings" form, but I don't have any good ideas at the moment.

I don't remember anything about saying no to gpx support... I can't remember what that was about... I also don't remember anything about a "tracks module." Sorry :-/

I do tend to forget stuff, so please ping stuff as necessary. :-/

In any case, the change to gmap_macro_builder_form is now in DRUPAL-5.

ray007’s picture

ray007 commented

I'm talking about issue http://drupal.org/node/135725 which was moved to the Track project with the reason being give "out of scope for the gmap module".

If you're amenable for a second parameter to gmap_macro_builder_form() for converting form-fields to 'hidden' or wrapping them in a invisible div I'll send in a patch soon.
Oh yeah, I just realized: in my patch the $settings from the parameter will also be used to set the '#default_value' properties of several form-inputs, while yours doesn't, right?

I also thought about letting the user show a marker on the map, that shouldn't be too hard to realize with using the macro builder too.

bdragon’s picture

bdragon commented

Ahh. I'm not the one who moved it.

I think this might be a good thing for an extension module. I've been trying to get enough pieces of gmap modularized that one could write an addon module.

I've also been planning on moving (the currently not working) wms stuff into an addon module as a test of this.

Hmm, maybe a project akin to "views_bonus_pack" that collects addons by various people in one place would be a good idea.

Actually...
/me runs off for a few....

http://drupal.org/project/gmap_addons

--Brandon

ray007’s picture

ray007 commented

Yeah, I just realized it's been somebody else moving the issue.

Moving the cck-field to gmap modules is fine with me. If we do that better sooner than later, a new location for a module with the same name always makes troubles otherwise.
I think gpx-support should be core so one could also trigger the show of a gpx-track by a property in a macro ... it's not something that can live on its own.

The change I think we need for the macro editor is changing line 71 from

  $defaults = gmap_defaults();

to

  $defaults = array_merge(gmap_defaults(), $settings);

Or does gmap_widget_setup() do some magic making this unnecessary?

ray007’s picture

ray007 commented

I have taken your giving me commit-access to the gmap_addons module as a hint to move the gmap_cck module there.
Which I just did.

I now need word for you if you'd prefer to add gpx-support in an inc-file here in the main-module, or if I should put it in gmap_addons too for now (inc/module ?).

ray007’s picture

ray007 commented
StatusFileSize
new gmap-macrobuilder-hidefields-1.patch1.46 KB

Some testing suggest the settings of $defaults with array_merge() is necessary for things to work as they are supposed to.

And since I was changing the function for this fix, I thought I'd offer the 2nd parameter for hiding fields as I think it could be useful for re-using the macrobuilder from other locations.
What do you think about the attached patch?

bdragon’s picture

bdragon commented
Status: Needs review » Active

Slightly simplified #8 committed.

bdragon’s picture

bdragon commented

I was thinking gmap_addons.

Also, I was thinking having each addon in a seperate folder might be a bit cleaner than everything in the root, so it would be easy to tell what files belong to what module.

When I get gmap wms layers support, I'll be trying to keep it in gmap_addons. I think the extensibility is finally at the point where wms support can be done outside of core and hooking in with the event system.

bdragon’s picture

bdragon commented
Status: Active » Closed (fixed)
moshebeeri’s picture

moshebeeri commented

Any suggestions on using GMap as content type field in Drupal 6.
I would like to implement a tracks content type for users to recommend hiking path.
Moshe.

moshebeeri’s picture

moshebeeri commented

I just did some more Google search and found gmap field, I think it will do the job.
http://drupal.org/project/gmapfield