Keys API support
jdlind38 - April 8, 2009 - 16:22
| Project: | Mapstraction |
| Version: | 6.x-1.0 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Description
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??
#1
Sorry the link to the keys module is actually http://drupal.org/project/keys
#2
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.
#3
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.
#4
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.
#5
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