@esfaenza/flow-builder 20.3.40 → 20.3.42

package/README.md

@@ -316,9 +316,9 @@ orchestrazione ne resta fuori: la §7 non lo comprende.
 Un tipo con un **discriminatore** compare come piu' voci, una per valore: il Collection
 Processor e' «Ordina» e «Filtra», non «ordina o filtra». Sono due gesti diversi — un `Sort`
 vuole `sortOptions`, un `Filter` vuole condizioni (§5.6) — e sceglierli dalla palette evita di
-sceglierli dopo, dentro il form. L'elemento nasce con il discriminatore già scritto, con la
-label della variante (da cui viene anche il nome tecnico) e con il glifo della variante, lo
-stesso che avra' sul canvas. `core/element-variants.ts` tiene la mappa tipo → campo del
+sceglierli dopo, dentro il form. L'elemento nasce con il discriminatore già scritto, con il
+glifo della variante — lo stesso che avra' sul canvas — e con un nome tecnico provvisorio preso
+dalla variante. `core/element-variants.ts` tiene la mappa tipo → campo del
 discriminatore; i valori restano nel dizionario del backend (`collectionProcessorTypes`), e
 senza quel dizionario il tipo torna a essere una voce sola.
 
@@ -327,6 +327,17 @@ Decision, Loop, Collection Processor, Get / Create / Update / Delete / Rollback
 Action, Script, Subflow, Wait, Custom Error, Transform, Orchestrated Stage. Più l'intestazione
 comune con la rinomina, che **riscrive tutti i riferimenti** all'elemento.
 
+*Nominare un elemento nuovo.* Un elemento appena creato nasce **senza etichetta**, e il suo form
+si apre con il cursore lì: il nome tecnico parte **vuoto** e si costruisce dall'etichetta mentre
+la si digita, con spazi e caratteri non ammessi sostituiti da `_` (§3.3). Nel documento un nome
+provvisorio c'e' comunque, perché il nome e' la chiave con cui tutto raggiunge l'elemento — e' anche
+cio' che il canvas mostra al posto del titolo finché l'etichetta manca — ma non e' quello che si
+legge nel campo. Scrivere il nome a mano lo sgancia dall'etichetta; svuotare il campo lo rimette a
+seguirla. Su un elemento che un'etichetta ce l'ha già il nome torna in sola lettura dietro il
+comando «Rinomina»: da lì in poi cambiarlo riscrive i riferimenti di tutto il documento (§13.8) e
+non e' un gesto da fare per sbaglio. Corollario: l'annulla riporta indietro etichetta e nome
+**insieme**, in un passo solo, e la selezione dell'editor — che e' il nome — lo segue.
+
 **Screen dinamico (§5.2).** È un **compositore**, non un form, e per questo la dialog e' larga il
 doppio di com'era: **tre colonne**. A sinistra la palette (due schede — i componenti, e i campi di
 un'entita' che portano tipo ed etichetta dallo schema), al centro **la schermata disegnata** (si
@@ -349,7 +360,11 @@ Tre cose che il modello non mostra e il form dice:
 - 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`.
+  `ComponentInstance` sono esclusivi con i suoi `outputParameters`;
+- `autoSelectSingleChoice` fa prendere al campo l'**unica** opzione risolta, quando e' una sola: e'
+  la tendina che dipende da un'altra tendina — i CAP di un comune — dove chiedere di scegliere non
+  decide niente. La spunta compare solo dove il tipo `acceptsChoices`, e altrove e'
+  `SCREEN_FIELD_CONFIGURATION_INVALID` (avviso).
 
 Il riordino e l'annidamento si fanno trascinando (`@angular/cdk/drag-drop`, senza drop list: il
 bersaglio si calcola dal DOM) oppure con i comandi «su / giu' / porta fuori».
@@ -400,7 +415,9 @@ Le tre cose che riguardano l'editor, e non il runtime:
 - **un trigger senza campo e senza `initBehavior` non scattera' mai**
   (`SCREEN_TRIGGER_WITHOUT_CAUSE`), e l'unico `initBehavior` ammesso e' `runOnLoad` — il
   `runOnRevisit` della specifica Salesforce e' `SCREEN_TRIGGER_INIT_BEHAVIOR_UNKNOWN`, e vale la
-  pena saperlo perche' chi arriva da quella specifica lo scrive per abitudine.
+  pena saperlo perche' chi arriva da quella specifica lo scrive per abitudine. Dove il campo
+  osservato ha un `defaultValue` il form dice che `runOnLoad` **non serve**: un campo precompilato
+  dal flow conta come un campo che ha preso un valore, e l'action gira comunque all'arrivo.
 
 Le action si aprono **una alla volta**: i cataloghi delle action e dei loro parametri dipendono da
 `actionType`/`actionName`, e tenerne N in volo sarebbe N volte la corsa fra risposte che l'inspector
@@ -658,6 +675,14 @@ leggendo. Ad aprire il form ci sono il bottone «✎» della riga e il doppio cl
 coppia di gesti del canvas. Per la stessa
 ragione il clic non si limita ad aprire l'elemento: **seleziona il campo** che il rilievo nomina.
 
+**Il tipo di flow si sceglie alla creazione.** Su un flow nuovo — quello che l'editor apre senza
+`flowName` — il `processType` e' una scelta nella barra in cima; da quando il flow e' salvato
+diventa un'etichetta e non si tocca più. Non e' prudenza: il tipo decide quali globali esistono
+(`$Record` non c'e' in uno screen flow, §4.1), quali elementi sono ammessi (§13.6) e come il motore
+esegue il flow, e cambiarlo su un documento già scritto lo lascia pieno di riferimenti a cose che
+da quel momento non esistono — senza che nessuna primitiva del backend rimedi. Un host che crea i
+flow da sé (come la demo) il tipo lo chiede lì, e lo passa a `emptyFlowDefinition`.
+
 **Versioni.** Elenco con stato, «Nuova versione» al posto di «Salva» sulle versioni chiuse,
 attivazione bloccata finche' ci sono errori, eliminazione dietro una conferma esplicita che
 spiega il rischio per le esecuzioni sospese.