Thanks for such a great module! Right now I use the location module with the gmap module, but I'd like to move away from the gmap mod to this one. I'm running into an issue though, I have a multi-site install using the domain access module and I use the Keys API module (http://drupal.org/project/keys_api) to manage all of the Google map keys. Is it possible to integrate mapstraction with the keys module??

CommentFileSizeAuthor
#3 mapstraction-keys_api.patch1.83 KBAnonymous (not verified)

Comments

jdlind38’s picture

jdlind38 commented

Sorry the link to the keys module is actually http://drupal.org/project/keys

Anonymous’s picture

Anonymous (not verified) commented

hear hear! The keys shouldn't be part of the view. The key should be configured separately, because I may have multiple views that use the same mapping service and thus the same key.

I'll contribute this patch myself later today.

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Needs work
StatusFileSize
new mapstraction-keys_api.patch1.83 KB

This turns out to be a little bit of a headache.

Keys 2 is a nonstarter. I couldn't get it to work reliably. Everything looks like it's almost working but... so I went to the stable DRUPAL-6--1-1 of Keys API. Adding a dependency on a module that's also changing its name, well, that's another problem.

The main issue I'm encountering is that Keys API isn't great at being a helper module for modules because it doesn't use the module name as a namespace. On the other hand, Keys should be shareable across modules which all use the same API, but there's no agreement on how to name these keys in Keys API so that other modules could get at them.

If we can't have agreement on the names, the best thing would be to use the module name as a namespace. As it stands, Mapstraction's Google Maps API key will be stored in the database simply as 'google'. If more modules depend on Keys API, this isn't good enough. How many modules will want to store a 'google' key?

Here's a starter patch. It works by setting the default value of the API key in Mapstraction views to the API key. Mapstraction will store this key in its own Views style options array.

At this time, I'm not going to develop this patch any further. I think it's probably better to develop an admin settings page for all the keys the way every other Drupal module does it.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

Interesting patch, but it shouldn't store the value at all as the View should be reusable across domains, which breaks the Google Maps API.

Another idea would be to use a variable by default but allow it to be overridden in the View. GMap uses the fairly generic "googlemap_api_key" value, couldn't we just use this? I'll see if I can whip something up.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

If anyone needs a temporary band-aid, give the patch on this issue a try: #568418: Allow the api_key to be loaded from a variable

greenskin’s picture

greenskin commented

I've finally gotten around to working on the Keys module (been so very busy).

@bangpound, I agree with everything you have stated and have been working on making version 2 better. A new 2.x-dev release should be posting soon which should be functional. First off, not every module that wishes to use the Keys module is required to establish its own service using hook_keys_service() unless the service, such as Google Maps, is not already provided. Version 2 of Keys now defines the service Google Maps.

Also, because not every site that needs an API key such as ones from Google need the functionality that Keys offers, the Keys module should never be a dependency and other modules should still offer their own simple method of storing an API key.

levelos’s picture

levelos commented
Status: Needs work » Closed (fixed)

I'm working on adding map presets in the new 2.x branch, separate from the individual views, much like GMap and Openlayers work. Then in your view style, you just select a preset. So closing this one for now.