Getting started guide

Live Components are end-user tools. End users in the customer's organization build their own reports, dashboards, charts and tables. The consultant's and developer's job sits one layer underneath: deliver oviw_*-views and DataQuery-definitions that make the data available. Once that layer is in place, the customer is self-sufficient and you as a consultant can offer this kind of delivery without having to be involved in every single report or dashboard the customer wants.

The components fall into two main categories:

• User-facing surfaces: Full pages that show up in the menu and have their own sharing rules: Live Report, Live Dashboard.

• Widgets: Reusable building blocks that are embedded in the user-facing surfaces: Live Chart, Live Table, Live Grid, Live DataObject, Live Inputs.

Live Report

What it is. A structured prose report with embedded widgets (Chart, Table, Inputs). Saved as versioned PDF snapshots, can be sent to recipients via a built-in distribution flow, and offers AI-assisted prose writing (enabled via configuration).

How it's used. The end user opens live-reports, creates a new Report, writes prose directly in the editor, embeds widgets via the sidebar, and invites any Inputs contributors to fill in their parts. Once the content is ready, a PDF snapshot is generated and sent to recipients — persons, roles × OrgUnit.

Strengths.

• Output and Input live in the same interactive document: contributors see the data from the rest of the report while they write their part.

• AI-assisted writing is built in. Suggested text changes are presented for approval before they are applied.

• The distribution flow — generate PDF, assemble recipient list, send — is part of the component, not something that has to be coded on top.

• Widget content is cached at refresh; viewers of the Report see the data without themselves needing access to the sources.

• Co-edit on Live Input — contributors write into the very report they are delivering to.

Things to be aware of. For tabular presentation in a Report, use Live Table (Live Grid is interactive and belongs in a Dashboard).

Live Dashboard

What it is. A tile-based page with widget tiles (Chart, Table, Grid) in a flexible layout. Interactive — viewers can sort, filter and navigate the row data.

How it's used. The end user opens live-dashboards, creates a new Dashboard, adds widgets from the sidebar, configures each widget (data source, columns, filters), and sets up the layout via drag-and-drop.

Strengths.

• Interactive: Grids provide sorting, filtering, paging and search — viewers can dig into the data themselves.

• Composable: the same widgets can be reused in multiple Dashboards without new configuration.

• Content is cached. This means an end user can be granted access to a Dashboard without having access to the data underneath — only the person refreshing the Dashboard needs source access. Auto-refresh is planned; today refresh is manual.

Things to be aware of. The caching behavior is designed into the component — which data becomes visible via the Dashboard is governed by who refreshes and who it is shared with.

Widgets

Live Chart

What it is. A configurable chart based on ECharts. Embedded in Live Report and Live Dashboard. Identified by Name (string).

How it's used. The end user opens live-chart-editor, gives the chart a name, picks a data source, picks a chart type (line, column, pie, and others) and maps columns to X/Y/series. Once saved, it is from that moment available as a widget in other Live components.

Strengths.

• Configured once, embedded in many Reports and Dashboards.

• Server-side rendering means the same chart works both in a printable PDF and in an interactive view.

Things to be aware of. Charts do not aggregate or group on their own; if you want aggregation or grouping, this must already be present in the data source.

Live Table

What it is. A server-rendered table widget. Takes a data source — typically a DataQuery or an oviw_ — and produces a formatted summary. Embedded in Live Reports and Live Dashboards.

How it's used. The end user opens live-table-editor, gives the table a name, picks a data source, columns, and any groupings and totals. Once saved, it is available for embedding.

Strengths.

• Server-side rendering yields a predictable appearance both on screen and in print.

• Live Tables are the primary tabular widget in Live Reports.

• Once a consultant has delivered a DataQuery, the customer can immediately build a Live Table on it without needing to know what sits underneath the DataQuery.

Things to be aware of. Live Table is not interactive on the client side — this is intentional, since the purpose is predictable summarization. Users who need sorting and filtering should use Live Grid in a Dashboard.

Live Grid

What it is. An interactive data grid with sorting, filtering and paging. Embedded in Live Dashboard, or opened as a standalone page.

How it's used. The end user opens live-grid-editor, gives the Grid a name, picks the Type ('View' for direct view binding or 'DataQuery' for data-source-agnostic binding), picks columns, and sets sorting, filters, and a default layout. Embed in a Dashboard or use via a standalone route.

Strengths.

• Users can dig into the data themselves: sorting, filtering, paging, search — without development.

• The Type choice provides flexibility: use 'View' for direct binding against an existing oviw_, use 'DataQuery' for binding via the DataQuery layer.

Things to be aware of. Live Grid is embedded in Dashboards, not Reports — the Report's printable nature and the Grid's interactivity do not fit together. Use Live Table for tabular data in a Report

Live Inputs

What it is. Placeholders in a Report or Dashboard that humans fill in. Assigned to a specific Person or Role. The content is prose, status assessments, comments, or other qualitative information — what the data cannot answer on its own.

How it's used. In the Report or Dashboard editor, the end user creates an Input section and assigns it to a contributor. The contributor is granted access to fill in their Input directly in the same report. Once the Input is filled in and marked "Submitted", the content becomes part of the report.

Strengths.

• Output and Input live in the same interactive document: the contributor sees the data from the rest of the report while writing their part. Inputs can therefore be informed by output, not written independently.

• Inputs are the dedicated mechanism for capturing human judgments as a complement to system data.

Things to be aware of. An Input inherits access from the report — the assignee must have at least read access to the Report to be able to contribute. The sharing setup should be in place before Inputs are assigned.