Move Map and Plugin object to a tree structure

[BibMartin]

3 simple commits, and an important one (561f060).

The goal of the latter is to move progressively the Map and Plugin objects into a tree structure.

What I have in mind is a tree like :

+- figure
    +- header
    +- css
    +- body
    +- script
    +- maps
        +- Markers
        +- Layers
        +- Plugins
        ...
    +- Others

Each node of the tree would have a render method that can have an effect on his parents.

This would have several positive effects:

• One can embed several maps into a single page, and eventually add other html stuff, as asked in Request: Additional file input #138.
• Each Leaflet object would have a python mirror so that one can compute interactions between objects. For example, marker, popup, divIcon and awesomeMarker need that kind of interactions (see Avoid code duplication in div marker #169). In my mind, this corresponds to the idea of a FoliumDataSource, as @wrobstory mentioned in Support GeoPandas #34.
• Some plugins will be easier to implement : provided that a Jinja temple has a render method, it can be a leaf in that tree. This may help today's plugins and @themiurgo's Rationalize Templates #147 to converge.
• Each node implements how it's children are rendered (and in which order), which provides more flexibility.
• Issue Handling external and internal dependencies #155 would find an elegant solution : an external link would be an object that you can render several ways (http, https, embeded). (see 5e90c1b)

Well, discussion is open... ;-)

[BibMartin]

I forgot ; for the moment, the tree structure is:

+- Map
    +- figure
        +- header
        +- css
        +- body
        +- script
    +- template_vars
    +- plugins
    ...

The idea is to move progressively template_vars into a structured tree (without changing the API), then to have figure embed several maps.

[themiurgo]

I feel like this PR is actually 2PRs, one part is the plugin render idea, the other is the tree structure.

Some questions:

• Why is the root name called figure? Shouldn't it be something like "page" or "root"?
• Why is plugin a child of maps? Surely each plugin affects the whole page and needs to inject their own header. If I embed two maps with the same sets of headers it will be difficult to track whether the js/css has been already injected beforehand.

[BibMartin]

Why is the root name called figure? Shouldn't it be something like "page" or "root"?

I chose figure because I have something like matplotlib in mind : a figure in which you can put several maps/axes. I thought we could get closer to their function names. I would be okay for "page" or "root".

Why is plugin a child of maps?

A plugin generally adds something on the map. But you're true, it can require to add somthing to the overall figure. This is why I have designed the thing so that each node knows who is his parent, and can have an effect on it. For example, if you have something like

Figure
    map1
        boatmarker1
        boatmarker2
    map2
        boatmarker3
        boatmarker4

Then each boatmarker will do something like

boatmarker.map.figure.header['boatmarker_js'] = Link('http://...')

But as it is the same Figure object, they will simply overwrite the former header.
BTW, this is why we need to use OrderedDict instead of lists : order is important, but we also need to get objects by their key/name.

[BibMartin]

Let's say that VegaPopup is working (though it's pure prototype). @wrobstory I would be happy if you have time to wartch 8ce53ea as it is going far from folium.Map._popup_render and I'm not really sure of the javascript generated.

[BibMartin]

💚 At last !

[ocefpaf]

With this approach it should be relatively easy to create mpld3 (pr even bokeh) popups.

[BibMartin]

This is outdated. Replaced by #203