Review findings on the harness.
- timing=load posted nothing: mount() only started a replay for early/both and
the load handler only logged. Both and load now post on the frame's load as
well, which is the metadata path and the second copy VA sends, so the mode the
controls offer is a mode that works.
- a re-apply with the same prompts did not reload the frame: setting src to the
value it already has is a no-op in the browser, so the new load post (and the
refresh path generally) delivered nothing. The frame is reloaded explicitly
when the URL is unchanged.
- dataType was declared and never applied. A prompt configured as number now
arrives as 42 rather than "42", which is what DC's clause builder branches on;
a non-numeric value is left alone rather than becoming NaN.
- the prompt select is found by walking the selects instead of building a
[data-name="..."] selector, so a prompt name with a quote or bracket in it
cannot throw inside apply() and leave the page with no frame.
- the replay's give-up message now says when the app does not expose
window.__vaLastMessage, so a changed probe is not reported as a delivery
failure.
- deploy.mjs throws when the Node runtime cannot read Set-Cookie rather than
silently dropping every cookie and failing later as an unauthenticated 401.
report.json carries a numeric prompt so the numeric path is exercised by
default rather than only in theory.
A parent page standing in for the VA report that embeds Data Controller as
data-driven content: the dropdowns are the report's prompts, and the iframe is
framed and fed the way VA frames and feeds it.
Deliberately outside the DC build. The host is not the child: shipping it in
DC's deployment would put a test harness on customer servers and let DC be
opened top-level as a page that frames itself.
- report.json defines the report: child AppStream name, table, sandbox set,
delivery mode and timing, and the prompts (label is the va_parmap key, since
DC matches on the label rather than the report's internal parameter name).
- two delivery modes, because they reach different code in DC: refresh (reload
the frame, replay from before load - the report-refresh path) and prompt (post
into the loaded frame - an in-place prompt change).
- deploy.mjs posts the folder to a SASjs Server with /SASjsApi/drive/deploy and
streamWebFolder, which is the same route sasjs cbd uses, so a static app is
published the usual way and served at /AppStream/<name>.
dc