@esfaenza/flow-builder 20.3.13 → 20.3.15

package/README.md

@@ -90,7 +90,7 @@ l'attributo di scope di Angular, quindi un CSS incapsulato non li raggiunge.
 | `version` | la versione da aprire; assente → l'attiva se c'e', altrimenti l'ultima (§6.1) |
 | `author` | registrato sulla versione e mostrato nell'elenco |
 | `defaultProcessType` | `processType` iniziale di un flow nuovo |
-| `inspectorMode` | `'dialog'` (predefinito) apre il dettaglio dell'elemento in una finestra sopra il canvas, come il flow builder di Salesforce; `'panel'` lo tiene nel pannello laterale |
+| `inspectorMode` | `'dialog'` (predefinito) apre il dettaglio dell'elemento in una finestra sopra il canvas; `'panel'` lo tiene nel pannello laterale |
 
 | Output | Quando |
 |---|---|
@@ -221,10 +221,31 @@ stesso che avra' sul canvas. `core/element-variants.ts` tiene la mappa tipo →
 discriminatore; i valori restano nel dizionario del backend (`collectionProcessorTypes`), e
 senza quel dizionario il tipo torna a essere una voce sola.
 
-**Inspector.** Un form per ogni tipo supportato: Start, Screen, Assignment, Decision, Loop,
-Collection Processor, Get / Create / Update / Delete / Rollback Records, Action, Script,
-Subflow, Wait, Custom Error, Transform, Orchestrated Stage. Più l'intestazione comune con la
-rinomina, che **riscrive tutti i riferimenti** all'elemento.
+**Inspector.** Un form per ogni tipo supportato: Start, Screen, Screen dinamico, Assignment,
+Decision, Loop, Collection Processor, Get / Create / Update / Delete / Rollback Records,
+Action, Script, Subflow, Wait, Custom Error, Transform, Orchestrated Stage. Più l'intestazione
+comune con la rinomina, che **riscrive tutti i riferimenti** all'elemento.
+
+**Screen dinamico (§5.2).** È l'unico inspector a due pannelli, e per questo la dialog e' larga
+il doppio di com'era: a sinistra l'albero dei campi con la larghezza in dodicesimi disegnata, a
+destra le proprieta' del campo selezionato. Quali proprieta' mostrare **lo decide il dizionario**
+(`screenFieldTypes` e i suoi flag `storesValue`, `isCollection`, `acceptsChoices`, `isContainer`,
+`requiresDataType`), non il codice: sono gli stessi flag che applica il runtime, e
+reimplementarli porta a proporre configurazioni che il motore rifiuta.
+
+Tre cose che il modello non mostra e il form dice:
+
+- un campo che raccoglie un valore **e' una risorsa del flow**, referenziabile per nome ovunque
+  e di **sola lettura** — il suo nome vive nello spazio dei nomi comune, e rinominarlo riscrive i
+  riferimenti (`FlowDocumentStore.renameScreenField`, come per i node: nessuna primitiva del
+  backend lo fa);
+- le regole di visibilita' si rivalutano **sui valori appena inviati**, i campi nascosti vengono
+  **azzerati** e solo i visibili vengono validati;
+- `choiceReferences` accetta **solo** `Choice` e `DynamicChoiceSet`, e gli output automatici di un
+  `ComponentInstance` sono esclusivi con i suoi `outputParameters`.
+
+Il riordino e l'annidamento si fanno trascinando (`@angular/cdk/drag-drop`) oppure con i comandi
+«su / giu' / porta dentro / porta fuori», che coprono anche gli alberi piu' alti del pannello.
 
 Sullo stage di orchestrazione il form dice le tre cose che il modello non mostra: gli step
 **non sono una sequenza** (le frecce riordinano l'esame, non l'esecuzione), ingresso e uscita
@@ -334,6 +355,17 @@ vuoto resta "non lo so" — primitiva non esposta, tipo senza valori dichiarati,
 da scegliere — e allora il valore si digita; con l'elenco popolato un valore fuori elenco e' un
 **avviso**, perche' nessun codice della §7 lo blocca ed e' l'editor ad accorgersene prima del runtime.
 
+**Un campo a `null` e' assente.** Il valore ha un campo per tipo e va valorizzato **uno e un solo**
+campo (§4.2); la §2 dice che cio' che non c'e' si omette, ma un backend che serializza tutte le
+proprieta' — `System.Text.Json` senza `IgnoreNullValues` lo fa di default — manda
+`{"enumValue": "InIstruttoria", "formulaExpression": null, …}`: un solo valore e sette caselle piene
+di niente. Riconoscere il campo con `!== undefined` faceva vincere il primo letto, cioe'
+`formulaExpression`: l'editor apriva la **formula** (vuota) e il valore, pur presente nel documento,
+spariva dalla vista — e il conteggio dei campi accusava `VALUE_AMBIGUOUS`. La regola sta in
+`core/flow-value.util.ts` (`isValued`, `valuedFieldOf`, `valuedFieldsOf`) e la usano l'editor del
+valore e quello delle condizioni: `null` e `undefined` significano la stessa cosa, mentre
+`booleanValue: false`, `numberValue: 0` e `stringValue: ''` restano valori.
+
 Perche' l'editor conosca il tipo della destinazione serve saperlo, e i percorsi non fanno eccezione:
 `POST /flows/references` elenca le **radici** e non i percorsi, quindi su `Richiesta.Stato` la
 corrispondenza esatta del nome non trova niente. Il tipo si ricava allora navigando la catena —
@@ -401,6 +433,7 @@ src/lib/
     condition-logic.util.ts  riscrittura di conditionLogic su cancella / riordina
     condition-types.util.ts  quali tipi si confrontano, e i numeri in cultura invariante
     stage-step.util.ts       gli step di uno stage: nomi, output non condizionabili
+    screen-field.util.ts     l'albero dei campi di uno screen dinamico: percorsi, nomi, mutazioni
   ui/
     flow-builder.component.ts  il componente da montare
     canvas/ palette/ inspector/ resources/ problems/ versions/ debug/ shared/
@@ -431,6 +464,7 @@ Oltre ad Angular:
 |---|---|
 | `@foblex/flow` (+ `@foblex/platform`, `@foblex/mediator`, `@foblex/2d`, `@foblex/utils`) | rendering del grafo, pan/zoom, gesti su node e connessioni. Usata in *classic mode*: la libreria disegna e riconosce i gesti, lo stato resta nostro |
 | `dagre` | auto-layout gerarchico del comando «Riordina» |
+| `@angular/cdk` | il solo `drag-drop`, per l'albero dei campi dello screen dinamico. Nessun componente Material: i controlli restano input nativi |
 
 Nessun design system: i controlli sono input nativi con binding espliciti e CSS custom, così
 il builder si integra nel tema dell'app ospite senza imporre il proprio.
@@ -454,6 +488,12 @@ Le variabili si sovrascrivono sul contenitore:
 Elenco completo in `styles/flow-builder.css`. Per la variante scura basta
 `data-fb-theme="dark"` su un antenato.
 
+La dialog di modifica ha **una misura sola per ogni tipo di elemento** — l'inspector dentro
+cambia, la finestra no, altrimenti i comandi si spostano sotto il mouse a ogni apertura — e le
+due misure sono token: `--fb-dialog-width` (1400px) e `--fb-dialog-height` (860px), entrambe
+limitate allo spazio disponibile. La larghezza e' quella che serve al compositore dello screen
+dinamico, che e' a due pannelli.
+
 Nota sugli archi: il colore si imposta valorizzando le custom properties del tema di
 @foblex/flow (`--ff-connection-color`, `--ff-marker-color`) invece di sovrascrivere le sue
 regole, perche' i selettori hanno la stessa specificita' e chi vince dipenderebbe dall'ordine
@@ -512,6 +552,13 @@ possibile anche con errori e attivazione bloccata dagli errori (§8).
   vivono dentro `rules[i].connector`, ma un arco selezionato perde la selezione.
 - **`relatedRecords` di Get Records** e' esposto in sola lettura con un avviso: e' modellato
   ma non tradotto in query.
+- **L'albero dei campi dello screen dinamico e' una lista di rilascio piatta**, non una per
+  contenitore: le drop list annidate del CDK sono ambigue proprio qui — il rettangolo di una
+  sezione contiene quello delle sue colonne, e a ricevere il rilascio e' sempre la lista
+  registrata per prima, cioe' la radice. Con la lista piatta il contenitore di arrivo si deduce
+  dalla riga che precede il punto di rilascio (sotto un contenitore = dentro, sotto un campo =
+  accanto). Il prezzo: trascinando una sezione, i suoi figli restano fermi finche' non si
+  rilascia — poi si spostano con lei.
 - **L'esecutore della demo non valuta le condizioni**: prende il primo ramo disponibile e lo
   scrive nella traccia. È un mock per esercitare il pannello, non il motore.
 - **Nessun test automatico**: la libreria e' stata verificata a mano sull'app demo (canvas,