Add button to enable/disable scrolling

[BibMartin]

When embedding a leaflet chart in a webpage (in a jupyter notebook, for example), you've got a quite heavy behavior when scrolling your web page : when the charts comes under the mouse cursor, then you zoom into your map instead of scrolling down the page.

I solve this in adding a small button in the bottom left corner, that toggle the scrolling behavior.

[themiurgo]

Nice idea. Keeping in mind that fol_template is not used only for embedded maps / jupyter and that this feature is useful only in some occasions, it would be good to make the following changes before including it in the project:

• Keep this feature disabled by default (no arrow shown at all in the map and no code outputted for it in the html page);
• Provide a Python method to toggle it on or off.

@ocefpaf what do you think about this?

[ocefpaf]

@themiurgo I am at SciPy right now (and I really need to get back to folium!!!)

I trust your judgement. Just consider making that optional to avoid braking people current layout.

[BibMartin]

Thanks for your answers.
I have added a boolean keyword argument in Map.__init__ to have it optional.
This is then managed by {% if %} condition in fol_template.

Thanks again (and enjoy SciPy ;-))

[ocefpaf]

Awesome!

[ocefpaf]

Thanks @BibMartin! That is a nice addition to folium. Can you update the changelog?

BTW: This PR is OK. Ignore the test failure for now. (I have a PR sitting here to fix travis.)

[BibMartin]

Done. Please tell me how I can improve contribution quality ; this is my first PR.

[themiurgo]

I'm not sure it's a good idea to include this functionality in the __init__ method. If we allow it this time, then any other plugin/functionality we might add in the future should/could also go in the object initialiser. Maybe it's better to move it to a separate method? What do others think about this?

Also, before merging, it would be good to include a little test, to make sure that the functionality works (and will keep working in the future).

[themiurgo]

[This also shows the importance of implementing soon a good way to handle plugins. That way we might have a generic add_plugin(plugin_object) for all the plugins and extra functionalities like this, and no need to make changes to the core object Map and its interface]

[ocefpaf]

I'm not sure it's a good idea to include this functionality in the init method.

Agreed! Or we will end up like pandas.read_csv 😉

it would be good to include a little test

Read my mind! @BibMartin take a look at our (horrible and monolithic) test file for examples.

This also shows the importance of implementing soon a good way to handle plugins.

This should be our number 1 priority! If only we had the time...

[BibMartin]

I don't feel I understand well how plugins are handled yet. In my mind, we can define a plugin as an object with methods like render_html, render_css and render_js, and use these methods into the template.

I did an illustration (BibMartin@5238fb9 ) but put it on another branch because is seems like a dirty hack to me.

As for the tests, I can implement one that creates a map with a ScrollZoomPlugin, renders it and sees if it fails ; but I can barely imagine something more challenging. Please tell me.

[ocefpaf]

I don't feel I understand well how plugins are handled yet.

Don't worry @BibMartin . We don't either 😜

@themiurgo can you take a look at BibMartin@5238fb9? Does it goes in the direction of what you were planning?

[themiurgo]

@themiurgo can you take a look at BibMartin/folium@5238fb9? Does it goes in the direction of what you were planning?

Yes, it does. Thanks @BibMartin! Perhaps we should continue this discussion on a separate plugin thread? In general we should decide where in the template we allow plugins to inject code (e.g. , , ...), based on a minimum set of plugins we want to support (ideally as many as possible). If we make all the sections of the template accessible, adding new plugins will be a breeze.

[BibMartin]

Ok, I have created issue #145 to host the discussion.

As for this PR, I would suggest to freeze it until we know how it shall be implemented to comply with the plugins mindset.

[themiurgo]

As for this PR, I would suggest to freeze it until we know how it shall be implemented to comply with the plugins mindset.

I agree, that's sensible.

[BibMartin]

I close this, because it's redundant with #148.