Hi all,
I am also +1 for the second approach.
Drawbacks with this approach
>
> -
>
> In the approach one, golden layout will take care of hiding the title
> header using its ItemConfig options [1]. So supporting other itemConfigs in
> future will be straightforward. But in this second approach we will have to
> implement logic in base widget for newer configs.
>
>
AFAIU there is no solid requirement of using other itemConfigs in widget
level up to now. Since we do not have widget editing capability for
generated widgets at the moment, if we follow the 1st approach, we have to
do a DB call in order to change the configs for generated widgets. I think
it is better to overcome the DB call drawback rather than overcoming the
itemConfigs issue. Because changing widgetConf related show/hide title is
more frequent use case compared to passing new itemConfigs.
Thanks,
Nisala
On Tue, Aug 28, 2018 at 12:21 PM Tanya Madurapperuma <ta...@wso2.com> wrote:
> Hi all,
>
> We have a requirement of hiding the widget title bar in some use cases.
> For example Date time picker widget doesn't need to have widget title
> displayed on its container.
>
> In order to implement this we can take two approaches.
>
>
>
> 1.
>
> Provide a config to be added in the widgetConf.json file which
> indicates if we want to hide the title. By default (when there is no config
> added) title will be visible and only hidden when a config as below is
> added.
>
> {
>
> "name": "UserInfo",
>
> "id": "UserInfo",
>
> "thumbnailURL": "",
>
> "configs": {
>
> "containerConfig": {
>
> "header": {
>
> "show": false
>
> }
>
> },
>
> "options": []
>
> }
>
> }
>
> Drawbacks with this approach
>
> -
>
> If the widget is a custom widget, config change gets applied to all
> instances of the given widget globally. For example if we have 10 date
> picker widgets in different dashboards, title of all widgets will be
> hidden.
> -
>
> If the widget is a generated one, we have to do a database call to
> edit the widgetConf.json. ( When we provide a facility to edit generated
> widgets this issue will be gone)
>
>
>
> 1.
>
> Introduce an options config in the widget. In this approach config
> should be added to all the widgets by default and designer can configure
> his preference after adding the widget to the dashboard.
>
> {
>
> "name": "UserInfo",
>
> "id": "UserInfo",
>
> "thumbnailURL": "",
>
> "configs": {
>
> "options": [
>
> {
>
> "id": "header",
>
> "title": "Header",
>
> "type": {
>
> "name": "BOOLEAN",
>
> "possibleValues": [
>
> true, false
>
> ]
>
> },
>
> "defaultValue": true
>
> }
>
> ]
>
> }
>
> }
>
> Logic that needs to be executed upon receiving of the option can be handed
> over to the base widget so that each widget author needs not to worry about
> that and will inherit.
>
> Drawbacks with this approach
>
> -
>
> In the approach one, golden layout will take care of hiding the title
> header using its ItemConfig options [1]. So supporting other itemConfigs in
> future will be straightforward. But in this second approach we will have to
> implement logic in base widget for newer configs.
>
>
> Considering the above options, it seems to me that second approach is more
> appropriate. Appreciate your inputs on above approaches and any other
> approaches.
>
> [1] https://golden-layout.com/docs/ItemConfig.html
>
>
> Thanks,
>
> Tanya
>
> --
> Tanya Madurapperuma
>
> Associate Technical Lead,
> WSO2 Inc. : wso2.com
> Mobile : +94718184439
> Blog : http://tanyamadurapperuma.blogspot.com
>
--
*Nisala Niroshana Nanayakkara,*
Senior Software Engineer
Mobile | +94 717600022
WSO2 Inc | http://wso2.com/
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
