Here are some ideas for how to enable events in widgets, especially one widget listening to another.
The idea is that the event-creating widget does not know what downstream widgets are listing until it is told. The configuration must work in the JSON file and internally is not of much concern to the person configuring the dashboard. Also need to think ahead to if we create a builder tool to edit configurations.
The JSON for a chart might include something like the following (or maybe use eventListeners?):
Utility code could be written to look up the widget by name, confirm that the widget type supports Select event type, and then call the addSelectEventListener function on the selector, which would add the chart widget to an array maintained in the selector widget, or maybe configure an observable that serves the same purpose?
Then, when the selector widget has a select event, it would go through the array and call each listening object. In the Java world , the method would be something like notifySelectListeners, which would go through the loop.
It may be appropriate to have a method on the selector widget to return the types of events that it generates that can be listened to (a builder tool could use this).
Because each event has different data, the event type is important because it will result in a specific method being called on the listening widget. For example, it would be possible to enable events on a map and when a feature is selected a method might be called to pass the selected feature(s).
To make this more formal, objects could be defined, such as SelectEvent or WidgetSelectEvent to avoid confusion with other UI code, which would contain the appropriate data to pass to the listening widget. This object could expand over time if it made sense, for example, to include the reference to the originating widget rather than just passing the string that was selected.
If no event handlers are defined the widget does not listen to any other widgets.
Here are some ideas for how to enable events in widgets, especially one widget listening to another.
The idea is that the event-creating widget does not know what downstream widgets are listing until it is told. The configuration must work in the JSON file and internally is not of much concern to the person configuring the dashboard. Also need to think ahead to if we create a builder tool to edit configurations.
The JSON for a chart might include something like the following (or maybe use
eventListeners?):Utility code could be written to look up the widget by name, confirm that the widget type supports
Selectevent type, and then call theaddSelectEventListenerfunction on the selector, which would add the chart widget to an array maintained in the selector widget, or maybe configure an observable that serves the same purpose?Then, when the selector widget has a select event, it would go through the array and call each listening object. In the Java world , the method would be something like
notifySelectListeners, which would go through the loop.It may be appropriate to have a method on the selector widget to return the types of events that it generates that can be listened to (a builder tool could use this).
Because each event has different data, the event type is important because it will result in a specific method being called on the listening widget. For example, it would be possible to enable events on a map and when a feature is selected a method might be called to pass the selected feature(s).
To make this more formal, objects could be defined, such as
SelectEventorWidgetSelectEventto avoid confusion with other UI code, which would contain the appropriate data to pass to the listening widget. This object could expand over time if it made sense, for example, to include the reference to the originating widget rather than just passing the string that was selected.If no event handlers are defined the widget does not listen to any other widgets.