html5 geolocation api support

#8 Open

Bitbucket cannot automatically merge this request.

The commits that make up this pull request have been removed.

Bitbucket cannot automatically merge this request due to conflicts.

Review the conflicts on the Overview tab. You can then either decline the request or merge it manually on your local system using the following commands:

hg update default
hg pull -r default
hg merge 0deb923244d4
hg commit -m 'Merged in zalew/django-easy-maps (pull request #8)'
  1. Jakub Zalewski
  • introduces EASY_MAPS_USE_HTML5_GEOLOCATION setting (default: False)
  • centers the map and marker to user's location
  • fills up the text input with reverse location info (city, country)
  • falls back silently to default behavior when geo is not available or user refuses to share

Comments (8)

  1. Jakub Zalewski author

    Yeah, you're right. Now I see also the geocoder init can probably be just moved to latlngToAddress. Will provide an update in a moment.

    I also found a bug (afair not introduced by me ;)) that I feel needs addressing globally, I will submit an issue later on for discussion.

  2. Mikhail Korobov repo owner

    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?

  3. Jakub Zalewski author

    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?

  4. Jakub Zalewski author

    even if the goal is to just display a map

    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.

  5. Mikhail Korobov repo owner

    There was some work on interactivity here: , 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:

    <!-- show map -->
    {% easy_map ... %} 
    <!-- map with necessary js code for admin editing -->
    {% easy_map ... using "easy_maps/admin_edit.html" %}
    <!-- map with necessary js code for editing on user site -->
    {% with EASY_MAPS_ADDRESS_FIELD_ID="my_field" %}
        {% easy_map ... using "easy_maps/edit.html" %}
    {% endwith %}

    Thanks for working on this (and on a bug) by the way!

  6. Jakub Zalewski author

    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.