Investigate iframed custom views for ELFA Tables and db-app-runner #78

New issue

Open

opened 2026-10-28 18:08:16 +01:00 by michielbdejong · 0 comments

michielbdejong commented

2026-10-28 18:08:16 +01:00

Owner

Goal

Assess how ELFA Tables can host custom views in isolated iframes, reusing or adapting AtomicServer's existing custom-view infrastructure where appropriate. Keep this separate from the TablePage port investigation so its host/API and isolation requirements can be sized independently.

Existing implementation to inspect

Reference source: github.com/ontola/atomic-server@49d21e08f7/browser/data-browser/src. Inspect table app views rendered by TableResource through AppPage/AppFrame, its host-store protocol and frame bridge. Also inspect the installed-plugin PluginView path: identify whether these are distinct contracts and which is relevant, rather than treating every iframe as the same runtime.

AtomicServer app views can appear alongside a table's built-in tabs and consume table context through a host bridge. Determine what is reusable outside the Data Browser and what assumes Atomic resources, installations/agents, source loading, permissions or server endpoints.

Investigation and expected output

Define the initial use case: a custom representation of the selected NextGraph table/collection using the same underlying records. Specify required table, schema, active-view and selection context, and distinguish table views from standalone apps or generic embedded web pages.
Map source/module loading, initialization/handshake, request/reply messages, subscriptions, writes and error/teardown behavior in the existing Atomic host. Identify required SDK or bridge changes for NextGraph.
Propose a minimal host contract for schema/record access, bounded queries, reactive updates, permitted edits, theme/locale and navigation. Keep the final protocol provisional until the upstream investigation; do not expose the whole NextGraph wallet/session or Atomic Store to frame code by default.
Specify iframe sandbox/origin and CSP behavior, sender/frame validation, allowed operations and data scope, and how the host enforces read-only versus editable access. Cover unloading, navigation, stale subscriptions and requests, malformed messages, and retained draft/error behavior.
Decide how the db-app-runner frontend supplies browser routing and how an embedded ELFA host can substitute its own navigation. Include links/open-resource behavior without granting a frame control of the parent application.
Compare reuse of Atomic's existing bridge/runtime with a small NextGraph adapter. Record dependencies, licensing/attribution, effort, risks and a staged PoC plan. Coordinate with the separate full TablePage port investigation without making that port a prerequisite by assumption.

Proposed PoC acceptance

Load one small custom view in a real sandboxed iframe, display a selected NextGraph table through the agreed host bridge, and observe a native update. If editing is included, demonstrate an allowed write and a rejected out-of-scope/read-only operation. Verify cleanup on frame/table changes, rejected invalid messages, useful errors and bounded data access; mocked rendering alone does not establish isolation or native storage integration.

ELFA Tables remains the current priority (docs/ROADMAP.md). This investigation does not resume the postponed ELFA Forms or Project implementations and does not depend on document inbox functionality.

Related investigation: #77 — Assess and size a full port of AtomicServer TablePage to ELFA Tables.

## Goal Assess how ELFA Tables can host custom views in isolated iframes, reusing or adapting AtomicServer's existing custom-view infrastructure where appropriate. Keep this separate from the TablePage port investigation so its host/API and isolation requirements can be sized independently. ## Existing implementation to inspect Reference source: https://github.com/ontola/atomic-server/tree/49d21e08f7a0851c7db18af404b9be318d311030/browser/data-browser/src. Inspect table app views rendered by `TableResource` through `AppPage/AppFrame`, its host-store protocol and frame bridge. Also inspect the installed-plugin `PluginView` path: identify whether these are distinct contracts and which is relevant, rather than treating every iframe as the same runtime. AtomicServer app views can appear alongside a table's built-in tabs and consume table context through a host bridge. Determine what is reusable outside the Data Browser and what assumes Atomic resources, installations/agents, source loading, permissions or server endpoints. ## Investigation and expected output - Define the initial use case: a custom representation of the selected NextGraph table/collection using the same underlying records. Specify required table, schema, active-view and selection context, and distinguish table views from standalone apps or generic embedded web pages. - Map source/module loading, initialization/handshake, request/reply messages, subscriptions, writes and error/teardown behavior in the existing Atomic host. Identify required SDK or bridge changes for NextGraph. - Propose a minimal host contract for schema/record access, bounded queries, reactive updates, permitted edits, theme/locale and navigation. Keep the final protocol provisional until the upstream investigation; do not expose the whole NextGraph wallet/session or Atomic Store to frame code by default. - Specify iframe sandbox/origin and CSP behavior, sender/frame validation, allowed operations and data scope, and how the host enforces read-only versus editable access. Cover unloading, navigation, stale subscriptions and requests, malformed messages, and retained draft/error behavior. - Decide how the db-app-runner frontend supplies browser routing and how an embedded ELFA host can substitute its own navigation. Include links/open-resource behavior without granting a frame control of the parent application. - Compare reuse of Atomic's existing bridge/runtime with a small NextGraph adapter. Record dependencies, licensing/attribution, effort, risks and a staged PoC plan. Coordinate with the separate full TablePage port investigation without making that port a prerequisite by assumption. ## Proposed PoC acceptance Load one small custom view in a real sandboxed iframe, display a selected NextGraph table through the agreed host bridge, and observe a native update. If editing is included, demonstrate an allowed write and a rejected out-of-scope/read-only operation. Verify cleanup on frame/table changes, rejected invalid messages, useful errors and bounded data access; mocked rendering alone does not establish isolation or native storage integration. ELFA Tables remains the current priority (docs/ROADMAP.md). This investigation does not resume the postponed ELFA Forms or Project implementations and does not depend on document inbox functionality. Related investigation: #77 — Assess and size a full port of AtomicServer TablePage to ELFA Tables.

michielbdejong referenced this issue

2026-10-28 18:08:17 +01:00

Assess and size a full port of AtomicServer TablePage to ELFA Tables #77

michielbdejong referenced this issue

2026-10-30 12:03:59 +01:00

Consume the Atomic table package with native NextGraph views and schema workflows #80