@loadbare/app 0.24.0 → 0.25.0

package/docs/reference/data-binding.md

@@ -902,18 +902,66 @@ the master and its details together; see [crud](./page-files.md#crud). The
 server checks that `rows` holds string keys and string values by query, and
 ignores a request whose `rows` does not.
 
+#### Rows not yet entered in a list
+
+A detail the master does not have yet is entered with it. `--lb-new` aimed
+at the nested list, rather than at a form, puts a row not yet entered into
+it, and sends nothing:
+
+```html
+<form lb-query="flight" lb-request="lb-row-insert">
+  <input lb-column="code" />
+  <ul id="arrivals" lb-query="arrivals">
+    <template>
+      <li>
+        <input lb-column="gate" />
+        <input lb-column="qty" value="1" />
+        <button type="button" lb-request="lb-row-delete">Remove</button>
+      </li>
+    </template>
+  </ul>
+  <button type="button" commandfor="arrivals" command="--lb-new">Add arrival</button>
+  <button type="submit">Save</button>
+</form>
+```
+
+- The row is a live row with the empty key, copied from the row template.
+  Its controls start at their HTML defaults, and its `lb-show` branches are
+  as for a row whose every column is null.
+- It stands after every row of the list, in the order added, and is not
+  ordered, filtered or aggregated, since it holds no data. It counts in
+  `lb-query-row-count`.
+- The form's submit carries it in `rows`, with `key: ""`, beside the rows on
+  record: an insert while the master is not on record, an update once it
+  is. The handler inserts each row with no key.
+- Once the submit succeeds, the rows not yet entered leave, and the rows its
+  answer lands take their place. A refusal leaves them, with a column's
+  message on its control.
+- A delete from one takes it out of the list and sends nothing, and an
+  update from one is not sent, as for any [row not yet
+  entered](#a-row-not-yet-entered).
+
+The form needs a submit: a row not yet entered never sends on its own, so
+one in a form that only saves control by control waits for nothing. The
+list is a query nested directly in the form's own, as for any set of rows
+the form gathers; the builder refuses `--lb-new` aimed at any other list.
+Aimed at a `<form>`, `--lb-new` points the form, as below.
+
 A nested query answers once for the page, so its rows are the same wherever
 they show. The form enters a new master with its details, or edits the
 master the page shows, whose details the nested query reads from the same
 query parm. A form [pointed at a row](#editing-a-row-in-one-form) fills its
-own controls from that row; its nested rows stay the nested query's answer.
+own controls from that row; its nested rows stay the nested query's answer,
+so the pointed row's own details come as its columns.
 
 ### A row not yet entered
 
-A row whose key is empty is a new one, not yet entered. It arises two ways:
-a `row` query answers with an empty key, as one showing the master a query
-parm names does when the parm is empty, or New points a form (see
-[Editing a row in one form](#editing-a-row-in-one-form)). Either way the
+A row whose key is empty is a new one, not yet entered. It arises three
+ways: a `row` query answers with an empty key, as one showing the master a
+query parm names does when the parm is empty; New points a form (see
+[Editing a row in one form](#editing-a-row-in-one-form)); or New aimed at a
+list adds one to it (see
+[Rows not yet entered in a list](#rows-not-yet-entered-in-a-list)). Either way the
 element carries `lb-key-value=""`.
 
 | Request          | From a row not yet entered            |
@@ -999,7 +1047,7 @@ row. Buttons point it with HTML's `commandfor` and `command`:
 | Command        | On a button                         | The hub                                     |
 |----------------|-------------------------------------|---------------------------------------------|
 | `--lb-edit`    | In a live row of the form's query   | Fills the form from that row, keyed by it   |
-| `--lb-new`     | Anywhere                            | Starts the form empty, for an insert        |
+| `--lb-new`     | Anywhere                            | Starts the form empty, for an insert; aimed at a list, see [Rows not yet entered in a list](#rows-not-yet-entered-in-a-list) |
 | `--lb-release` | Anywhere                            | Lets the form go without saving             |
 
 HTML requires a custom command to begin with `--`.
@@ -1032,6 +1080,13 @@ round trip, including columns no element in the table shows. The user
 edits a row they can see, so the row is on the page. A row that has to be
 fetched to be edited is another page, with that row as its master.
 
+A pointed form edits what the row it points at holds. Details the form
+shows for that row come as columns of the row, one per detail when the
+details are a fixed set, or from a master the page shows by a query parm,
+whose nested query reads the same parm. A query nested in a pointed form
+shows the page's answer, whichever row the form points at; see
+[A form over a set of rows](#a-form-over-a-set-of-rows).
+
 Pointing a form first empties it: every column it names lands as null, and
 the form resets, so each control returns to its default. Edit then lands
 the row on the form, stamps the form with the row's key, so the form's
@@ -1369,6 +1424,9 @@ expansion, and refuses to build:
   template, or beside `lb-column` or `lb-request`
 - a `command` beginning `--lb-` that is not one of the four commands
 - one of the four commands with no `commandfor`
+- `--lb-new` aimed at an element the markup holds that is neither a
+  `<form>` nor a list carrying `lb-query` nested directly in a form's own
+  query
 - `lb-group` on anything but a `<template>`, or on one holding no
   `<template>` for its contents
 - an aggregate on a `<template>`, or any but `lb-count` naming no column

package/docs/reference/names.md

@@ -139,7 +139,7 @@ Loadbare/app owns every value of HTML's `command` attribute beginning with
 | Command        | Defined in                                                               |
 | -------------- | ------------------------------------------------------------------------ |
 | `--lb-edit`    | [Editing a row in one form](./data-binding.md#editing-a-row-in-one-form) |
-| `--lb-new`     | [Editing a row in one form](./data-binding.md#editing-a-row-in-one-form) |
+| `--lb-new`     | [Editing a row in one form](./data-binding.md#editing-a-row-in-one-form), [Rows not yet entered in a list](./data-binding.md#rows-not-yet-entered-in-a-list) |
 | `--lb-release` | [Editing a row in one form](./data-binding.md#editing-a-row-in-one-form) |
 | `--lb-place`    | [Placing by hand](./data-binding.md#placing-by-hand) |
 

package/docs/reference/page-files.md

@@ -273,8 +273,9 @@ reported and ignored. A declared request receives `keys` as it is.
 `rows` holds the rows of a query nested in the form the request came from,
 by query name, each with its `key` and the `values` of its own controls; see
 [A form over a set of rows](./data-binding.md#a-form-over-a-set-of-rows).
-The handler writes the master and its details together, deciding what each
-row's values mean, such as an empty amount being no row at all:
+A row with `key: ""` is one not yet entered, added by `--lb-new`; insert
+it. The handler writes the master and its details together, deciding what
+each row's values mean, such as an empty amount being no row at all:
 
 ```ts
 rowInsert: {

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@loadbare/app",
   "description": "High performance web app framework for server-bound applications",
-  "version": "0.24.0",
+  "version": "0.25.0",
   "type": "module",
   "files": [
     "dist",

package/skills/loadbare-app/SKILL.md

@@ -189,7 +189,14 @@ every outer row; use it for a picker, never for per-row detail.  Inside a
 form, the live rows of a query nested in the form's own are gathered as
 `rows: { <query>: [{ key, values }] }` beside `values`, so a master and a
 subtable of its details (one input per type, say) are entered in one
-submit, and the master's handler writes both.  A new outer
+submit, and the master's handler writes both.  A detail not yet entered
+is added by a button with `commandfor` naming the nested list and
+`command="--lb-new"`: it adds a row with the empty key and sends nothing,
+the form's submit carries it as `{ key: "", values }`, the handler inserts
+each row with no key, and it leaves when the submit succeeds.  So a master
+and its details are one save, before or after the master is on record; never
+gate the details behind `lb-show` on the master being saved.  The form needs
+a submit.  A new outer
 row is filled from the nested query's last answer, whatever order they land
 in.
 
@@ -296,7 +303,11 @@ not a form.)  The form's `lb-key-value` is the row's key, empty
 for a new row, absent when not in use, and a stylesheet shows Save or Save
 new by it.  A successful request from the form, or its dialog closing, lets
 it go.  Which row is being edited is never a query parm.  A row that must be
-fetched to be edited is another page, with that row as its master.
+fetched to be edited is another page, with that row as its master.  A
+pointed form edits only what its row holds: a query nested in it shows the
+page's answer, not the pointed row's details, so give the row a column per
+detail when the details are a fixed set, or make the row the page's master
+by a parm.
 
 **Three requests are Loadbare's.**  `lb-row-insert` needs `query` and
 `values`, `lb-row-update` needs `query`, `key` and `values`, and
@@ -309,7 +320,8 @@ request the page does not declare.  One that arrives anyway, from a script,
 is warned about on the server console and answered with nothing.
 
 **An empty key is a row not yet entered.**  A `row` query answering with an
-empty key, or a form `--lb-new` pointed, carries `lb-key-value=""`.  The hub
+empty key, a form `--lb-new` pointed, or a row `--lb-new` added to a list,
+carries `lb-key-value=""`.  The hub
 sends inserts and declared requests from it with no `key`, and sends no
 update or delete at all, silently.  So a control with
 `lb-request="lb-row-update"` saves on a row on record and only holds its

package/skills/loadbare-app/references/data-binding.md

@@ -902,18 +902,66 @@ the master and its details together; see [crud](./page-files.md#crud). The
 server checks that `rows` holds string keys and string values by query, and
 ignores a request whose `rows` does not.
 
+#### Rows not yet entered in a list
+
+A detail the master does not have yet is entered with it. `--lb-new` aimed
+at the nested list, rather than at a form, puts a row not yet entered into
+it, and sends nothing:
+
+```html
+<form lb-query="flight" lb-request="lb-row-insert">
+  <input lb-column="code" />
+  <ul id="arrivals" lb-query="arrivals">
+    <template>
+      <li>
+        <input lb-column="gate" />
+        <input lb-column="qty" value="1" />
+        <button type="button" lb-request="lb-row-delete">Remove</button>
+      </li>
+    </template>
+  </ul>
+  <button type="button" commandfor="arrivals" command="--lb-new">Add arrival</button>
+  <button type="submit">Save</button>
+</form>
+```
+
+- The row is a live row with the empty key, copied from the row template.
+  Its controls start at their HTML defaults, and its `lb-show` branches are
+  as for a row whose every column is null.
+- It stands after every row of the list, in the order added, and is not
+  ordered, filtered or aggregated, since it holds no data. It counts in
+  `lb-query-row-count`.
+- The form's submit carries it in `rows`, with `key: ""`, beside the rows on
+  record: an insert while the master is not on record, an update once it
+  is. The handler inserts each row with no key.
+- Once the submit succeeds, the rows not yet entered leave, and the rows its
+  answer lands take their place. A refusal leaves them, with a column's
+  message on its control.
+- A delete from one takes it out of the list and sends nothing, and an
+  update from one is not sent, as for any [row not yet
+  entered](#a-row-not-yet-entered).
+
+The form needs a submit: a row not yet entered never sends on its own, so
+one in a form that only saves control by control waits for nothing. The
+list is a query nested directly in the form's own, as for any set of rows
+the form gathers; the builder refuses `--lb-new` aimed at any other list.
+Aimed at a `<form>`, `--lb-new` points the form, as below.
+
 A nested query answers once for the page, so its rows are the same wherever
 they show. The form enters a new master with its details, or edits the
 master the page shows, whose details the nested query reads from the same
 query parm. A form [pointed at a row](#editing-a-row-in-one-form) fills its
-own controls from that row; its nested rows stay the nested query's answer.
+own controls from that row; its nested rows stay the nested query's answer,
+so the pointed row's own details come as its columns.
 
 ### A row not yet entered
 
-A row whose key is empty is a new one, not yet entered. It arises two ways:
-a `row` query answers with an empty key, as one showing the master a query
-parm names does when the parm is empty, or New points a form (see
-[Editing a row in one form](#editing-a-row-in-one-form)). Either way the
+A row whose key is empty is a new one, not yet entered. It arises three
+ways: a `row` query answers with an empty key, as one showing the master a
+query parm names does when the parm is empty; New points a form (see
+[Editing a row in one form](#editing-a-row-in-one-form)); or New aimed at a
+list adds one to it (see
+[Rows not yet entered in a list](#rows-not-yet-entered-in-a-list)). Either way the
 element carries `lb-key-value=""`.
 
 | Request          | From a row not yet entered            |
@@ -999,7 +1047,7 @@ row. Buttons point it with HTML's `commandfor` and `command`:
 | Command        | On a button                         | The hub                                     |
 |----------------|-------------------------------------|---------------------------------------------|
 | `--lb-edit`    | In a live row of the form's query   | Fills the form from that row, keyed by it   |
-| `--lb-new`     | Anywhere                            | Starts the form empty, for an insert        |
+| `--lb-new`     | Anywhere                            | Starts the form empty, for an insert; aimed at a list, see [Rows not yet entered in a list](#rows-not-yet-entered-in-a-list) |
 | `--lb-release` | Anywhere                            | Lets the form go without saving             |
 
 HTML requires a custom command to begin with `--`.
@@ -1032,6 +1080,13 @@ round trip, including columns no element in the table shows. The user
 edits a row they can see, so the row is on the page. A row that has to be
 fetched to be edited is another page, with that row as its master.
 
+A pointed form edits what the row it points at holds. Details the form
+shows for that row come as columns of the row, one per detail when the
+details are a fixed set, or from a master the page shows by a query parm,
+whose nested query reads the same parm. A query nested in a pointed form
+shows the page's answer, whichever row the form points at; see
+[A form over a set of rows](#a-form-over-a-set-of-rows).
+
 Pointing a form first empties it: every column it names lands as null, and
 the form resets, so each control returns to its default. Edit then lands
 the row on the form, stamps the form with the row's key, so the form's
@@ -1369,6 +1424,9 @@ expansion, and refuses to build:
   template, or beside `lb-column` or `lb-request`
 - a `command` beginning `--lb-` that is not one of the four commands
 - one of the four commands with no `commandfor`
+- `--lb-new` aimed at an element the markup holds that is neither a
+  `<form>` nor a list carrying `lb-query` nested directly in a form's own
+  query
 - `lb-group` on anything but a `<template>`, or on one holding no
   `<template>` for its contents
 - an aggregate on a `<template>`, or any but `lb-count` naming no column

package/skills/loadbare-app/references/names.md

@@ -139,7 +139,7 @@ Loadbare/app owns every value of HTML's `command` attribute beginning with
 | Command        | Defined in                                                               |
 | -------------- | ------------------------------------------------------------------------ |
 | `--lb-edit`    | [Editing a row in one form](./data-binding.md#editing-a-row-in-one-form) |
-| `--lb-new`     | [Editing a row in one form](./data-binding.md#editing-a-row-in-one-form) |
+| `--lb-new`     | [Editing a row in one form](./data-binding.md#editing-a-row-in-one-form), [Rows not yet entered in a list](./data-binding.md#rows-not-yet-entered-in-a-list) |
 | `--lb-release` | [Editing a row in one form](./data-binding.md#editing-a-row-in-one-form) |
 | `--lb-place`    | [Placing by hand](./data-binding.md#placing-by-hand) |
 

package/skills/loadbare-app/references/page-files.md

@@ -273,8 +273,9 @@ reported and ignored. A declared request receives `keys` as it is.
 `rows` holds the rows of a query nested in the form the request came from,
 by query name, each with its `key` and the `values` of its own controls; see
 [A form over a set of rows](./data-binding.md#a-form-over-a-set-of-rows).
-The handler writes the master and its details together, deciding what each
-row's values mean, such as an empty amount being no row at all:
+A row with `key: ""` is one not yet entered, added by `--lb-new`; insert
+it. The handler writes the master and its details together, deciding what
+each row's values mean, such as an empty amount being no row at all:
 
 ```ts
 rowInsert: {

package/docs/temp-proposals.md

@@ -1,251 +0,0 @@
-# Proposals
-
-Working notes for changes not yet made.  Not part of the skill.
-
-## The mental model
-
-A `row` maps to an HTML form.  It supports select, insert, update and delete.
-The hub handles the basics, such as resetting a form after an insert, and
-lifecycle methods let a custom element add behavior of its own.
-
-`rows` treats each of its rows as a `row`, and allows insert, update and
-delete of several rows at once.  It also places its rows by sorting and
-filtering, each with an automatic or a manual flag.
-
-A form sends a parent `row` with its nested `rows` in one submit, and the
-handler writes them together.  This is the foreign key.
-
-The URL names the page, and its query parms are the server's filters.  The
-user's own sorts and filters are choices, held in `lb-choices`.
-
-Requests go up, from the element that committed through its ancestors to the
-hub, which completes them from what surrounds the element.  Commands go
-sideways, by id to the element they name, carrying the button that sent them,
-and never reach the server.  Lifecycle methods go down, from the hub to the
-custom elements it placed.
-
-What lies past this belongs to the application.  It reaches the hub as fields
-a custom element supplies on a request, and through lifecycle methods the hub
-calls on a custom element.
-
-## 1. Values kept across inserts
-
-Package: `@loadbare/widgets`.  No change to `@loadbare/app`.
-
-### Today
-
-After an insert succeeds, the hub resets the form the insert was gathered
-from, then calls `lbRequestDone` on the attached custom elements from the
-committing element outward.  `detail.request.values` holds the values the
-insert sent, by column.  A ghost row starts over empty, and each control
-returns to its HTML default.
-
-A page that wants some columns to carry over to the next row, such as a date
-or an account during a run of entries, has no way to say so.
-
-### Proposal
-
-A widget around the list, `lb-keep` or similar, names the columns to keep:
-
-```html
-<lb-keep exp-columns="date, account">
-  <lb-table lb-query="entries">
-    ...
-  </lb-table>
-</lb-keep>
-```
-
-In `lbRequestDone`, after a successful `lb-row-insert`, the widget sets each
-named column's control in the committing row back to the value the insert
-sent.  The hub's reset and the refill run in one synchronous stretch, so the
-empty row is never painted.
-
-- A column not named returns to its HTML default: `value` on an input,
-  `selected` on an option.  A control with no default comes back blank.
-- A reset the user asks for, with a reset button, sends no request and is
-  not followed by `lbRequestDone`.  It clears every column.
-- Kept values live in the controls.  A reload starts the row empty.
-
-### Open
-
-- A starting value taken from the page, not from the last insert: ef's
-  paychecks page enters a paycheck while showing a series, and the new
-  paycheck's series is the one showing.  A possible form is a default named
-  as `query.column`.
-- Whether every wrapped control in `@loadbare/widgets` takes an HTML
-  default.
-
-## 2. Sorted and filtered placement
-
-Package: `@loadbare/app`.
-
-### Today
-
-When a patch lands on a list, the hub either places the rows by the order and
-the filter, or holds them where they stand.  It holds them when the request
-was sent from inside the list: the list is the nearest element carrying
-`lb-query` around the element that committed, or the request came from a form
-that `--lb-edit` pointed at one of its rows.
-
-Where the committing element sits is the only input to that decision.  Two
-cases in ef come out wrong:
-
-- Matching.  "Create rule and apply it" is a form in a side panel.  Its answer
-  patches the rows the rule matched, and under the filter "Unmatched only"
-  they disappear.  The user wants them to stay showing for review.  An offset
-  chosen with the form `--lb-edit` points at a row is held, so the two ways of
-  matching a transaction behave differently.
-- Paychecks.  "Change from here…" is a form pointed with `--lb-edit`, so its
-  answer is held.  The answer replaces the rest of the year, and the new
-  paychecks land after the last row of the series, out of date order.  The
-  page carries a Re-sort button for this.
-
-Neither table has edits in its rows.  Every edit on both is made in a form
-outside the table.
-
-### Proposal
-
-The element carrying `lb-query` declares each kind of placement, `auto` or
-`manual`.  Both default to `auto`.  Spelling is open; for illustration:
-
-```html
-<lb-table lb-query="entries" lb-order="entries_order"
-          lb-filter="description, txn_date, is_unmatched"
-          lb-order-placement="manual" lb-filter-placement="manual">
-```
-
-The rule about where a request was sent from is removed.
-
-Each line of today's held behavior falls under one flag:
-
-| The answer                             | `manual`                           | Flag   |
-| -------------------------------------- | ---------------------------------- | ------ |
-| Changes a column the order reads       | The row stays where it stands      | order  |
-| Creates a row                          | The row goes last in its group     | order  |
-| Changes the column its group breaks on | The row stays under its heading    | order  |
-| Changes a row so the filter hides it   | The row stays showing              | filter |
-| Drops a row                            | The row leaves, under either value | —      |
-
-Under `auto`, the rows are placed by the order and the filter on every
-landing.
-
-Every combination has a use:
-
-| Order    | Filter   | Example                                                  |
-| -------- | -------- | -------------------------------------------------------- |
-| `auto`   | `auto`   | Paychecks: a regenerated schedule lands in date order    |
-| `manual` | `manual` | Matching: answered rows stay in place for review         |
-| `auto`   | `manual` | Answered rows stay showing and move into the order       |
-| `manual` | `auto`   | A to-do list: an edit does not move a row, done hides it |
-
-A row left where the order or the filter would not leave it is stamped, as
-`lb-row-unsorted` is today, and counted in `lb-query-unsorted-count`.  The rows
-are placed by both again when the page loads, when the user's order or filter
-changes, and on `--lb-sort`.
-
-### The command
-
-`--lb-sort` today places the rows by both the order and the filter, so a row
-kept despite the filter leaves on it.  Under the flags it is renamed for what
-it does, `--lb-place` or similar.
-
-A side set to `auto` is in place after every landing, so one command does
-what each list needs:
-
-| Order    | Filter   | The command       |
-| -------- | -------- | ----------------- |
-| `manual` | `auto`   | Sorts             |
-| `auto`   | `manual` | Filters           |
-| `manual` | `manual` | Sorts and filters |
-| `auto`   | `auto`   | Changes nothing   |
-
-Separate `--lb-sort` and `--lb-filter` differ from it only when both sides are
-`manual` and the user applies one without the other.  No case for that is in
-hand.
-
-### Effect on ef
-
-- Matching declares both `manual`.  The rule's answer and the offset form
-  behave alike, wherever the form sits.
-- Paychecks declares nothing.  The Re-sort button and its comment are removed.
-
-### Effect on other pages
-
-A list that relies on being held today, such as an editable `lb-table` with a
-ghost row, declares `manual` to keep its behavior.  Under `auto`, a row edited
-in place moves into the order, and a row entered in the ghost row is placed by
-the order.
-
-### Open
-
-- The attribute names.
-- One stamp for both kinds of out-of-place row, or one for each, so a page can
-  style a row out of order apart from a row kept despite the filter.  The
-  commands follow the stamps.  One stamp has one count, one button shown while
-  it is not 0, and one command.  Two stamps let a page show Re-sort and
-  Re-filter apart, each with its own command, `--lb-sort` and `--lb-filter`,
-  beside the one for both.  Every name carries the `--` prefix, or the
-  browser ignores it.
-
-## 3. Child rows entered with their parent
-
-Package: `@loadbare/app`.
-
-### Today
-
-A form gathers the live rows of a query nested in its own, and sends them in
-`rows` beside its own `values`.  The handler writes the parent and its child
-rows together.  A live row is one the nested query answered, so the child rows
-exist before the form is sent: ef's paycheck form sends one amount per
-deduction type, and the types come from the database.
-
-A row not yet entered, carrying `lb-key-value=""`, arises only as a single
-row: a `row` query answering with an empty key, or a form pointed by
-`--lb-new`.  A list holds no row not yet entered.
-
-ptracking's flight page enters a flight, then its arrivals.  The arrivals
-section shows once the flight is on record, and each arrival is its own
-`lb-row-insert` from the ghost row, keyed by the `flight_id` parm.  The
-arrivals handler refuses an insert with no flight: "Save the flight first."
-Most flights have one arrival, and pattern work is one arrival with a
-quantity, so the usual entry is two saves and a second form.
-
-### Proposal
-
-A list may hold rows not yet entered.
-
-1. Inside a parent not yet entered, the list's Add puts a row not yet entered
-   into the list, and sends nothing.
-2. The parent's form gathers those rows with its insert, each with no key,
-   under the nested query's name in `rows`.
-3. The parent's handler inserts the parent and its child rows in one
-   transaction, and answers both.  The rows not yet entered are replaced by
-   the rows the answer lands.
-4. Once the parent is on record, the list's Add inserts as it does today.
-
-A row not yet entered in a list follows the existing rules for one:
-
-- Its controls carrying `lb-request="lb-row-update"` send nothing and hold
-  what the parent's submit gathers.  Once the row is on record, they save as
-  they change.
-- A delete from it sends nothing.  The row is removed from the list.
-- A refusal of the parent's insert leaves it in place, and a column's message
-  goes on its control, as for any control the request gathered.
-
-### Effect on ptracking
-
-- The arrivals list moves inside the flight's form, and loses
-  `lb-show="on_record"`.
-- The flight's `rowInsert` accepts `rows.arrivals` and inserts both.
-  `detailCrud` writes the parent alone today.
-- A flight with one arrival is one save.  A flight with three approaches is
-  three rows not yet entered and one save.
-
-### Open
-
-- The command that adds a row not yet entered: the ghost row's insert,
-  changing meaning while the parent is not on record, or a command of its own.
-- `lb-table` joins the ghost row's controls to a form of its own, outside the
-  table, with the `form` attribute.  A ghost row inside a parent's form then
-  belongs to the ghost row's form, not the parent's.
-- One level only, as for a form over a set of rows today.