@esfaenza/flow-builder 20.3.46 → 20.3.48

package/README.md

@@ -103,9 +103,21 @@ l'attributo di scope di Angular, quindi un CSS incapsulato non li raggiunge.
 | `activated` | dopo un'attivazione riuscita |
 | `runRequested` | l'utente ha premuto **Esegui** o **Debug**, con `FlowRunRequest`: `debug`, `flowName`, `version`, `inputs` già convertiti, `processType`, `isDirty` e la `definition` in mano all'editor. **L'editor non esegue e non chiama niente**: cosa significhi eseguire — una navigazione, delle API dell'host, una dialog con l'interview dentro — lo decide l'host. Un host che non ascolta questo output fa sì che i due comandi non facciano niente: non c'e' nessuna primitiva che possa mancare, quindi nessun errore da mostrare |
 
-Il componente vuole un'altezza: `<fb-flow-builder style="height: 100vh">`, oppure un
-contenitore flex. Gli store sono provider **del componente**, quindi due builder sulla stessa
-pagina editano due flow indipendenti.
+**Il componente vuole un'altezza**, e non e' un dettaglio di stile: `<fb-flow-builder
+style="height: 100vh">`, oppure un contenitore flex che gliene dia una. L'editor e' un guscio
+d'applicazione, e ogni suo pannello — l'elenco delle risorse, i problemi, l'inspector, la traccia —
+**scorre per conto proprio** dentro l'altezza che riceve.
+
+Se non la riceve, `height: 100%` si risolve su `auto` e la catena si rovescia: ogni regione diventa
+alta quanto il suo contenuto, nessuna scorre piu', e la pagina cresce all'infinito. È un difetto che
+non si vede finche' il flow e' piccolo — con dieci risorse la differenza non si nota, con quaranta la
+pagina non finisce piu'. Da lì `max-height: 100vh` su `.fb-builder`, che e' un **freno** e non il
+modo in cui l'editor prende la sua altezza: rimette in piedi lo scorrimento dove l'altezza manca, e
+dove c'e' non morde. Il freno non sostituisce l'altezza: sotto un'intestazione di pagina il
+viewport intero e' comunque troppo, e a fare la cosa giusta e' l'ospite.
+
+Gli store sono provider **del componente**, quindi due builder sulla stessa pagina editano due flow
+indipendenti.
 
 ---
 
@@ -366,6 +378,37 @@ comando «Rinomina»: da lì in poi cambiarlo riscrive i riferimenti di tutto il
 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.
 
+**Il tipo di flow (§3.4).** È la prima scelta, e nel documento **non e' un campo**: il tipo e' la
+coppia `processType` + `start.triggerType`, e i tipi sono sei — con schermate, su richiesta,
+innescato da un record, pianificato, innescato da un evento, orchestrazione innescata da un record.
+La tabella con i flag arriva nei dizionari come `flowTypes` e non si ricopia: `allowsScreens`,
+`requiresObject`, `requiresSchedule`, `requiresEvent`, `requiresRegistration` sono gli stessi che
+applica il backend.
+
+Tre conseguenze nell'editor:
+
+- **si sceglie alla creazione** e poi resta un'etichetta, come prima; cio' che cambia e' che la
+  tendina elenca i sei tipi e scrive **due** campi in una sola mutazione. Il contratto ammette il
+  cambio di tipo (riscrivere la coppia); l'editor non lo offre, per la ragione di sempre — un
+  documento già scritto si riempirebbe di riferimenti a globali che da quel momento non esistono;
+- **la coppia si legge in un posto solo**, `FlowDictionaryStore.flowTypeOf`. Tre dei sei tipi sono
+  `AutoLaunched`, quindi ogni domanda posta al solo `processType` da qui in avanti risponde male: e'
+  il motivo per cui la palette decide di offrire gli screen da `allowsScreens` e non piu' dal
+  `processType`, e per cui lo Start propone i soli `triggerTypes` del tipo scelto;
+- `flowType` compare **derivato** nell'elenco dei flow, nelle versioni e nell'outline, e vale `null`
+  per cio' che non e' uno dei sei (un `Evaluation`, un'orchestrazione senza trigger): lì si mostra il
+  `processType`, e non e' un difetto da correggere.
+
+**L'attivazione, e la sua seconda meta' (§8).** I tre tipi che non partono da soli vanno **presi in
+carico** dall'infrastruttura dell'ospite — uno scheduler, un bus, un intercettore delle scritture — e
+il backend li registra prima di attivare. Da lì due esiti che il pannello dei problemi non spiega,
+perche' non parlano della definizione: `MissingService` (su questa installazione nessuno prende in
+carico quel tipo di flow: la definizione e' valida, «riprova» non ha senso) e `RegistrationFailed`
+(l'host ha rifiutato: «riprova» ce l'ha). In **entrambi** i casi la versione non e' attiva, e la
+sessione ricarica l'elenco versioni invece di lasciar credere all'esito; su un salvataggio con
+`activate: true` la bozza **resta salvata** e non attivata. Le due frasi le compone
+`describeActivationError`, in un posto solo perche' ad attivare sono in due.
+
 **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
@@ -453,6 +496,28 @@ Le due cose che il modello non mostra e la colonna centrale dice:
   **nome** di un campo (`stringValue`), ma dove il tipo della collection aggregata e' noto lo si
   sceglie da un elenco invece di ricordarlo.
 
+**Le regole della schermata (§5.2).** `validationRules` sono le verifiche che **non appartengono a
+nessun campo**: «almeno un punto fra le due sezioni», «la somma delle percentuali fa cento». Si
+modellano nelle proprieta' della schermata, accanto alle action, e a runtime arrivano come
+`SCREEN_RULE` — l'unico codice di validazione che puo' presentarsi **senza `fieldName`**.
+
+Perche' esistono: la `validationRule` di un campo giudica **un** valore, e su una sezione ripetibile
+e' addirittura inerte (una sezione non raccoglie un valore proprio). L'alternativa storica era un
+node a valle dello screen, che pero' non blocca la schermata — l'interview avanza e poi torna
+indietro — e mette una validazione dentro il disegno del flow.
+
+Tre cose che il form mette a posto:
+
+- `errorMessage` e' **obbligatorio** (`SCREEN_RULE_INVALID`): senza, la schermata si rifiuta di
+  avanzare senza dire perche', e un messaggio non si puo' costruire — non c'e' un campo da nominare;
+- **si scrivono con le condizioni, non con la formula**, ed e' il consiglio che il pannello ripete:
+  `IsEmpty` su una collection e' un operatore che il runtime valuta, mentre la stessa domanda in una
+  formula chiede al motore una funzione che potrebbe non avere. `Formula` resta un `conditionLogic`
+  ammesso — qui sì, a differenza di un `filterLogic` — quindi l'editor la offre lo stesso;
+- il `fieldName` facoltativo pesca dai campi della schermata **senza quelli dentro una riga**: lo
+  stesso elenco degli inneschi, e per la stessa ragione — un campo che esiste in una copia per
+  elemento non individua un controllo a cui agganciare il messaggio.
+
 **Screen action (§5.2).** Un campo che l'utente compila puo' **innescare un'action** i cui risultati
 finiscono negli altri campi della stessa schermata: e' il caso «scrivi il codice fiscale e nome e
 cognome compaiono da soli», e senza di essa lo si farebbe spezzando lo screen in due con un elemento