Explorer can be integrated into parent applications. This usecase assumes that the data stems from that parent application, and that individual rows in explorer when clicked should start some action in the parent application.
So when the parent application hosts a list of persons, and explorer allows selection of those persons, a click in explorer should start an action for the person clicked in the parent application (say, make an appointment with the clicked person).
The integration is two way;
A click on a row can trigger functionality in a parent application. This is detailed below in Explorer to Parent.
A click on a button in the parent application can retrieve rows currently selected in explorer. See Parent to Explorer.
For each row, explorer will forward an additional (non-ui) column that
identifies the row. The value of this
action_column has some significance
to the parent application and can be configured in the explorer configuration
EXPLORER_ACTION_COLUMN. Note that this is a SQL column name, that
should be available in the explorer table.
Note that the
action_column is not available in explorer group or pivot
views. Those views aggregate many input rows into one output row (persons in
the example), making a click on that row ambigious. The onrow click event is
not bound in those views.
10.1. Explorer to Parent¶
EXPLORER_ACTION_FUNCTION. This function needs to be set as a string value,
window. Actual evaluation
happens at click, so it can be defined after the page has loaded.
The function will be called with a single
10.2. Parent to Explorer¶
frontend, the parent application can call
export_json_ids to retrieve all
action_columns of the currently
All rows that are in the current query are reported on, not just the ones that are on the screen.
table_including_action_ids = await export_json() just_the_action_ids = await export_json_ids()