Leaflet control #1902
Leaflet control #1902
Conversation
There was a problem hiding this comment.
This PR contains three separate ideas that I think we should handle separately.
CustomControl is useful I think, and something requested by users. It inherits from Control, but doesn't use anything from it, so it might as well be separate.
I'm not sure what Control is supposed to do. It's a base class for many other classes in this PR, but none of the now child classes use anything from it. No arguments are passed in super().__init__() and the template is overwritten. So it might as well not be there. In which case is shouldn't. Long chains of object inheritance make things difficult to grok.
Then there are also some changes in Realtime that on first glance are not linked to the control change.
So my suggestion would be to take the first and third point and deal with those in separate PRs. And then have a discussion about the second point, how the class structure of Folium should be.
|
Thanks for the review. I will rework it as requested. |
1. Created a root control class which can load any Leaflet control 2. Made all items that generate a leaflet Control in plugins inherit from Control instead of MacroElement. 3. Still TODO: It would be nice if Control itself inherited from JSCSSMixin. But for that we'd need to revamp loading of css and js. 4. Probably many of the plugins could be rewritten more simply by using features from Control and JsCode instead of using custom templates. 5. map.LayerControl does not inherit from Control due to issues with circular imports. (features import map, so map cannot import features). We'd need to move LayerControl for that to work, but that is breaking change.
Most of the code of mouse_position has been removed. Instead it simply calls the constructor of Control with the typed parameters.
|
@Conengmo I removed the parts that could be handled as separate Pull Requests. I also rewrote the I would prefer to rewrite the other plugins incrementally. However, that means that for a while there will be inconsistent approaches in the code. |
Based on the original draft by @Conengmo
Control, which can be used to more easily create new control based plugins.CustomControlso that it also accepts astyleparameter.L.Controlsubclasses to useControlas a base class.This is to some extent a work-in-progress. Once #1898 is merged I can make
Controlinherit fromJSCSSMixinand remove that class from all the plugins and just use the inherited method fromJSCSSMixininheritance to add stylesheets and javascript.Furthermore, many of the plugins could be simplified. In the current implementation
optionsare very often coded in the_Template. By using theControlbase class andJsCodeparameters as part of the specifiedoptionswe can avoid that. Or, at least, we can move flow code from the Jinja templates into the__init__method, which is cleaner.Also, I tried to make
map.LayerControlas subclass ofControl, but that resulted in circular dependencies.I did not do everything at once, because I want to take small steps and check if everything stays backward compatible.