xmla-services / org.eclipse.daanse.xmla.client.typescript

0 stars 5 forks source link

Dashboard and Widgets [general requirement] #343

Open vwfox opened 8 months ago

vwfox commented 8 months ago

Dashboard and Widgets

definitions

relations

erDiagram
    DASHBOARDSYSTEM ||--}o DASHBOARDS : has
    DASHBOARDS ||--}o WIDGETS : has
    DASHBOARDS ||--}o CONTROLS : has
    WIDGETS ||--|| STORE : has
    STORE ||--|| DATASOURCE : has
    STORE ||--}o REQUEST : has
    STORE ||--}o REQUEST_PARAMETERS : has
    CONTROLS o{--}o REQUEST_PARAMETERS : change

requirements

User Roles

User

ssemenkoff commented 7 months ago

First of all the idea of dashboards and dashboardSystem is clear to me and we can proceed according to the current requirements.

The part starting from widgets isn't thought through good enough, so I have a suggestions here. I have 2 ideas on implementation of widgets, stores and datasources.

The main question for me is how the widgets and controls are connected between each other. And how the data for connected items are retrieved.

My first idea is based on the schema attached above. For communications between controls we have event bus. Controls and widgets can create events. Controls and widgets have group ids that represents their connections. Each event is created with group ids and parameters. Widgets with the same group id will listen for event and modify its store according to them. Each widget has it's own store that is responsible for storing widgets settings and data-specific settings. Each store has its own datasource. All the datasources send requests through the proxy object that is responsible for caching and preventing multiple simultaneous identical requests. image

Second one is based on the idea similar to what I created in the beginning. All the widgets, stores and controls are part of the group object. Group object has it's own datasource(may be multiple datasources of different types) and it's own store. This store is only storing data-specific settings. Widget specific settings is a part of a widget. Controls and widget can call methods of the store directly and react to store changes. Having single datasource for group eliminates possibilities of same request occurring multiple times. So in this case dashboard will contain groups and not directly widgets and controls. image

vwfox commented 7 months ago

I like the idea of the event bus. However, I see the problem with the reduntant requests. However, I see the caching more in the data source.

Alternatively, a combination of both ideas would make sense:

If you soften the 1..1 restriction of data resources and stores and that of widgets and stores, you could both map the groups and avoid the duplicate requests. Widgets could share a store if they consume the same data (and thus automatically form a group). In turn, stores could also use different data sources to enable the data to be intersected.

The event bus could mediate between controls and stores.

Page_3

ssemenkoff commented 7 months ago

I like that idea. So the main points are:

vwfox commented 7 months ago

check