One more thing: if I understand the code properly (I haven't tried it), on addresses with geocoding errors (when map.address could be None or empty) users of a public site would be asked for permission to use geolocation API even if the goal is to just display a map. Maybe we should create map_admin.html or map_edit.html specifically for use in admin/edit forms? What do you think?
When html geolocation is set to True, a request for geolocation access is sent only when there is no address in the form when creating or editing. Whenever there is a valid address, the user isn't bothered, because it wouldn't make any sense to prompt him to constantly override his own input.
If you'd like to have the option to disable it on occasion while having the geolocation set True globally, hmmm, I guess I can think of something and implement it. I'm not fond of the idea of separating it like admin/site, because use cases may vary and not be dependent on where the form is displayed, but how you actually want it to work. IMO better to f.ex. give the possibility to enable/disable this feature with a flag - it may be the simplest idea, what u think?
There is a serious bug I found before and is still valid, where the map is not displayed when the address is not empty but gibberish, because it results in a JS syntax error of empty lat/long values on google.maps.LatLng(, ) creation and breaks the whole thing. That's something I'd like to address as a separate issue.
When it comes to actually editing the location, I plan on touching the subject of selecting location via dragging the map (it just begs for it); but that's another feature for later on. Unless you or somebody else are already working on it?
Oh, wait, now I get what case you describe. I got carried away with the form widget so I forgot the map template also can also be used to just show a map :) Ok, I will think for a moment and I may ditch the global setting for a flag set on demand.
There was some work on interactivity here: https://github.com/kmike/django-easy-maps/pull/2 , but I was not happy with the implementation and we decided to defer this/split into multiple issues (Gianluca submits several pull requests that gets merged then, but they didn't address interactivity). I'm not working on this feature myself. This would be a wonderful contribution!
When talking about templates I was thinking about something like the following:
I thought it over and you are right about the show_map / edit_map split, it will be easier to maintain and contribute further specific features.
What I propose regarding the geoapi support:
ditch the global setting (worked for me but it turned out to be not so smart as a generic solution, as usual with settings ;))
introduce an argument in its place (geo can be useful in editing as well as in display)
It will let people turn this feature on selectively.
Further on I'd like to work on making it less fragile, because currently it's too easy to break it, but as I said I will address it separately because there is a probability that some minor design decisions will have to be made.
Thanks for working on this (and on a bug) by the way!
No problem, tx for making this app :) I already have a few UX needs to address on my list, so for sure I'd like to contribute them up.