@esfaenza/flow-builder 20.3.37 → 20.3.38

package/README.md

@@ -79,8 +79,11 @@ l'attributo di scope di Angular, quindi un CSS incapsulato non li raggiunge.
   [flowName]="'ApprovazioneOrdine'"
   [version]="null"
   [author]="utenteCorrente"
+  [runOutcome]="esitoUltimaEsecuzione()"
+  [isRunning]="esecuzioneInCorso()"
   (saved)="onSaved($event)"
   (activated)="onActivated($event)"
+  (runRequested)="esegui($event)"
 />
 ```
 
@@ -91,11 +94,14 @@ l'attributo di scope di Angular, quindi un CSS incapsulato non li raggiunge.
 | `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; `'panel'` lo tiene nel pannello laterale |
+| `runOutcome` | l'esito che l'host vuole far vedere nel pannello «Debug» dopo un `runRequested` (`FlowRunOutcome`); `null` → il pannello dice che non c'e' niente. Facoltativo: chi mostra l'esecuzione in una sua interfaccia non passa niente |
+| `isRunning` | l'esecuzione annunciata e' ancora in corso. Solo l'host lo sa: accende il puntino sul tab «Debug» e tiene spento il bottone della finestra degli ingressi |
 
 | Output | Quando |
 |---|---|
 | `saved` | dopo un salvataggio riuscito, con `FlowSaveResult`. Lo emette anche «Duplica», e in quel caso `flowName` e' quello della **copia**: la sessione si e' spostata su di essa, quindi l'host che tiene il nome da parte deve adottarlo |
 | `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
@@ -150,8 +156,7 @@ sono opzionali e rifiutano con `MissingService` se non sovrascritti.
 
 | Esecuzione dall'editor | |
 |---|---|
-| `runFlow(request)`, `debugFlow(request)` | opzionali — i comandi **Esegui** e **Debug** della barra. Non sono primitive del contratto: l'editor raccoglie i valori di ingresso in una finestra e passa la mano all'ospite, che sa dove gira il motore. Senza implementazione il comando fallisce con `MissingService` e l'editor lo dice — non finge un avvio. Sono due metodi e non un flag perche' quasi sempre sono due strade diverse, e perche' un ambiente puo' esporre l'una senza l'altra. **Il ritorno e' facoltativo e conta**: un `FlowRunOutcome` finisce nel pannello «Debug» dell'editor — stato, traccia, risorse, output — mentre `void` significa «guardo altrove». Restituirlo e' quasi obbligatorio sui flow **senza schermate**, dove non esiste nessun'altra interfaccia in cui vedere cos'e' successo |
-| `startInterview`, `respondToScreen`, `resumeInterview`, `inspectInterview`, `abandonInterview` | opzionali — le primitive §6.5 dell'interview. **L'editor non le usa**: servono a chi implementa `runFlow`/`debugFlow` con un runner proprio (la demo lo fa) |
+| `startInterview`, `respondToScreen`, `resumeInterview`, `inspectInterview`, `abandonInterview` | opzionali — le primitive §6.5 dell'interview. **L'editor non le usa**: servono a chi risponde a `runRequested` con un runner proprio (la demo lo fa) |
 | `completeStageStep(request)` | opzionale — conclude uno step di orchestrazione (§5.14) |
 
 **Errori.** Ogni metodo, in caso di rifiuto, deve fallire con un `FlowApiError`
@@ -639,24 +644,31 @@ ripiego dove `cloneFlow` non c'e' (e' opzionale). Un nome già usato lo rifiuta
 generato dalle variabili `isInput` del documento — tipo dichiarato rispettato anche in scrittura,
 istanze di classe compilate un membro alla volta (§4.7), enum per **nome** da `listEnumValues`
 (§4.6). Un campo lasciato vuoto non viene mandato: non valorizzato e stringa vuota sono cose
-diverse. Poi l'editor **passa la mano**: chiama `runFlow` o `debugFlow` e non esegue niente per
-conto suo. Si esegue la versione **salvata**, quindi i comandi sono spenti su un flow mai scritto
-e la finestra avverte quando ci sono modifiche non salvate. Senza implementazione — categoria
-`MissingService` — il banner dice quale delle due primitive manca, con parole comprensibili a chi
-ha appena premuto «Esegui».
-
-**Il pannello «Debug».** Cosa l'ospite ha restituito dall'ultima esecuzione: stato, output,
+diverse. Poi l'editor **passa la mano**, e non con una chiamata: emette `runRequested` con tutto
+cio' che sa del momento — `debug`, `flowName`, `version`, `inputs`, `processType`, `isDirty`, la
+`definition` in mano — e non esegue niente per conto suo. Cosa significhi eseguire lo decide
+l'host: una navigazione, una chiamata alle sue API, una dialog con l'interview dentro, o niente.
+Nessuna primitiva di `FlowBuilderApi` viene toccata, quindi non c'e' nessun `MissingService` da
+mostrare: un host che non ascolta l'output fa sì che il comando non faccia niente. Si esegue la
+versione **salvata**, quindi i comandi sono spenti su un flow mai scritto e la finestra avverte
+quando ci sono modifiche non salvate — con `isDirty` nel payload, se l'host preferisce provare la
+bozza che ha in `definition`.
+
+**Il pannello «Debug».** Cosa l'ospite ha voluto ridare all'editor dell'ultima esecuzione,
+passandolo all'input `runOutcome`: stato, output,
 traccia degli elementi eseguiti — ogni riga porta all'elemento sul canvas — e risorse. Esiste per
 un caso che altrimenti non ha risposta: un flow **senza schermate** (`AutoLaunched`, o
 un'orchestrazione tutta in background) non apre nessuna interfaccia del runtime, quindi senza
-questo pannello non ci sarebbe **nessun** posto in cui vedere cosa e' successo. `trace` e
+questo pannello non ci sarebbe **nessun** posto in cui vedere cosa e' successo. Passarlo e'
+facoltativo — chi mostra tutto in casa sua non passa niente, e il pannello lo dice invece di
+sembrare rotto. `trace` e
 `resources` arrivano solo con `debug: true` (§6.5), e riportano i valori di tutte le risorse —
 dati personali compresi: l'avviso e' in chiaro. Il pannello non conduce niente: guarda, e basta.
 
 Come si implementa l'altra metà si vede nella demo
 (`projects/flow-builder-example/src/app/runner`), e la scelta interessante e' **quando** aprire una finestra: un
-flow che non ha niente da chiedere finisce da solo e l'esito torna subito all'editor, mentre uno
-interattivo apre il runner e restituisce l'ultimo risultato alla chiusura — così la traccia resta
+flow che non ha niente da chiedere finisce da solo e l'esito va subito in `runOutcome`, mentre uno
+interattivo apre il runner e ci mette l'ultimo risultato alla chiusura — così la traccia resta
 comunque lì dove si stava lavorando. Il runner guida l'interview con le primitive della §6.5,
 distingue le due attese di `Suspended` (`isWaitingForEvent` / `isWaitingForStageStep`), conclude
 uno step al posto dell'assegnatario — rifiuto compreso, con la `interviewKey` nuova che sostituisce