@esfaenza/flow-builder 20.3.14 → 20.3.15

package/README.md

@@ -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
@@ -412,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/
@@ -442,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.
@@ -465,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
@@ -523,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,