Wt entity UI — top-level commissioning story

Table of Contents

This page is a capture in the deferred bucket of the product backlog — a pre-sprint idea, not yet pulled into a sprint as a story.

What

Make Wt (the web UI, projects/ores.wt.service) a top-level story with one task per component / entity, rather than a deferred "file Wt and HTTP gap captures" task in each commission_* story (every commission story has one; e.g. country). Those per-commission tasks are superseded by this top-level story and should be abandoned/closed in its favour when picked up.

Pick up after all entities are commissioned — Wt is a horizontal layer.

Current state

  • Wt is entirely hand-written and not codegen-driven. Each entity has bespoke widgets, e.g. src/app/currency_list_widget.cpp / currency_dialog.cpp and src/app/country_list_widget.cpp / country_dialog.cpp (+ headers under include/ores.wt.service/app/).
  • They are wired by hand into the application: src/app/ore_application.cpp:27-28 includes the country widgets, :285-286 constructs the list widget, :449-454 connects add/edit/delete, :472 sets rows. So country's Wt gap is functionally closed — but only by hand, and the wiring in ore_application is the blob (the analogue of the HTTP application.cpp route wiring).
  • The layer has not been revisited in a long time: it likely lags the feature set the Qt client now has (flags/provenance/history/pagination/change reasons) and shares the platform's stale-auth concerns (see the HTTP capture's JWT findings — the Wt service runner uses the RS256 verifier, so confirm its login/token story too).

Target architecture (codegen-first)

Same shape as the HTTP proposal: adding an entity's web UI = a codegen run, touching no shared file.

  • Per-entity generated units: <entity>_list_widget + <entity>_dialog generated from the entity model (columns, detail fields, history, flag — reusing the same model data that drives the Qt widgets). Use the hand-written currency/country widgets as the reference shape.
  • Generated aggregator = delegation: a generated registration that builds and wires each entity's widgets into ore_application (menu entry, list widget, add/edit/delete signal hookup), so ore_application stops being a hand-edited per-entity blob. Same idea as the HTTP route aggregator and the messaging registrar.
  • Modernize first: align Wt with current domain/messaging conventions and the Qt feature set before generating, so the template captures the modern shape.

Proposed task breakdown (top-level Wt story)

  1. Modernize the Wt layer — review against current conventions + the Qt feature set (flags, provenance, history, pagination, change reasons) and auth; pick the canonical widget shape.
  2. Unpick one entity (country or currency) into clean per-entity units + a delegation aggregator in ore_application — reference impl.
  3. Templatize into a codegen Wt facet (list widget + dialog + aggregator); regenerate the reference entity and prove zero-diff.
  4. Per-component rollout tasks — generate Wt for each commissioned entity.

Why

Wt is the only entity-facing layer with no codegen path, so every entity's web UI is bespoke and drifts from the Qt feature set; ore_application grows a hand-wired block per entity. Hand-maintaining it doesn't scale as entities are commissioned, and the staleness risks convention/security drift. A top-level story — modernize, establish the per-entity pattern, templatize — makes the web UI consistent and cheap, like SQL/C++/Qt, and retires the scattered per-commission Wt tasks.

References

  • projects/ores.wt.service/src/app/ — country_list_widget.cpp, country_dialog.cpp, currency_list_widget.cpp, currency_dialog.cpp; wiring in ore_application.cpp:27-28,285-286,449-454,472.
  • Headers under projects/ores.wt.service/include/ores.wt.service/app/.
  • Wt service runner / auth: ores.service/.../wt_service_runner.hpp (RS256 verifier).

See also

Emacs 29.3 (Org mode 9.6.15)