Improve widgets usage in external applications

[jailln]

After trying to use widgets in an application using itowns, I propose several modifications that could simplify their usage in external applications:

• [ ] Package each widget independently, so one can only import the widget he needs
• [ ] Don't position the widgets in the Widget constructor. This should be left to users IMO since there is a million way to do it and each user will need it done differently (currently it is closely related to itowns examples needs). I propose to move this positioning code to a WidgetUtils method that would help positionning them for itowns examples and to let itowns users deal with the domElement(s) object(s) of the widget.
• [ ] Don't set any css by default (e.g. no css classes) and leave the user do it. In the same way, the css classes could be added by the WidgetUtils

WDYT @mgermerie ?

[mgermerie]

About the packaging, we could indeed add the possibility to import widgets individually, but is the performance gain must be tiny (since the complete package is quite small). Moreover, perhaps it can be more complicated to import each widgets you need instead of importing all widgets as a single package. Is the performance gain worth the usage complication ? Also, is there another gain than performances that I would miss ?

I agree to make widgets more "standolone", in terms of style. In the WidgetUtils scenario, Widget would only create an html structure (with the whole widget domElement and all its children like buttons in navigation widget). WidgetUtils would grant something like a positionWidget(widget, { options for position }) method which would set each html element classes as it is for now. Is that how you thought it ? If doing so, user would need a complete understanding of the html structure of each widget in order to style it as wanted. This is a bit the same as what is going on now, since user can always chose not to import the default css for widgets. User can make its own css from the classes that he/she knows from the html structure of each widget. The difference is that user would need to set custom classes for each elements, should we change to the scenario you described.

[jailln]

About the packaging, we could indeed add the possibility to import widgets individually, but is the performance gain must be tiny (since the complete package is quite small). Moreover, perhaps it can be more complicated to import each widgets you need instead of importing all widgets as a single package. Is the performance gain worth the usage complication ? Also, is there another gain than performances that I would miss ?

Good point. My remark was also in the perspective that widgets will grow in the future. More work on our side but maybe we could provide a package with all widgets and one per widget?

I agree to make widgets more "standolone", in terms of style. In the WidgetUtils scenario, Widget would only create an html structure (with the whole widget domElement and all its children like buttons in navigation widget). WidgetUtils would grant something like a positionWidget(widget, { options for position }) method which would set each html element classes as it is for now. Is that how you thought it ? If doing so, user would need a complete understanding of the html structure of each widget in order to style it as wanted. This is a bit the same as what is going on now, since user can always chose not to import the default css for widgets. User can make its own css from the classes that he/she knows from the html structure of each widget. The difference is that user would need to set custom classes for each elements, should we change to the scenario you described.

Yes that's what I imagined. There is another difference in addition to what you cited though: in the case I described, the widgets won't have any style properties added by the Widget constructor (e.g. top, bottom, left or right positioning, translate, default css classes, etc.). I think this should be left to the user (even if it has to understand the html structure of the widget) since in my opinion widgets may be used in applications with complex UI and with specific style requirements. Users that don't want to bother with all that would still be able to use the WidgetUtils.

[mgermerie]

Good point. My remark was also in the perspective that widgets will grow in the future. More work on our side but maybe we could provide a package with all widgets and one per widget?

Yep, good idea to provide both "single widget" packages and a generic widget package.

Yes that's what I imagined. There is another difference in addition to what you cited though: in the case I described, the widgets won't have any style properties added by the Widget constructor (e.g. top, bottom, left or right positioning, translate, default css classes, etc.). I think this should be left to the user (even if it has to understand the html structure of the widget) since in my opinion widgets may be used in applications with complex UI and with specific style requirements. Users that don't want to bother with all that would still be able to use the WidgetUtils.

Ok that's fine for me :+1:

[valentinMachado]

It could also be good as mentioned here to let the possibility to the user to not specify the parentElement of the widget.