@esfaenza/flow-builder 20.3.1 → 20.3.3

package/README.md

@@ -202,6 +202,15 @@ qualsiasi.
 dalla mappa delle uscite invece di essere «ramo di errore» per tutti: su uno stage di
 orchestrazione quel ramo e' lo **step rifiutato**, non un guasto.
 
+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.5) — 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
+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
@@ -218,6 +227,34 @@ con la via d'uscita: scrivere quel risultato in una variabile.
 `Object` / `Enum`, `scale` solo sui numerici, costanti che non possono referenziare risorse,
 `stageOrder` distinti.
 
+**Oggetti e campi.** Ogni punto che chiede un'entita' o un suo campo usa lo stesso controllo:
+`<fb-object-picker>` e `<fb-field-picker>`, una casella con autocomplete che filtra il catalogo
+mentre si scrive. Un `<select>` andava bene con dieci entita', non con trecento; e dove il
+catalogo non arriva il controllo resta lo stesso, con un avviso, invece di degradare in un
+campo di testo cieco. La scrittura libera e' voluta — i percorsi di relazione
+(`Cliente.Citta`) non sono enumerabili e il catalogo dell'host puo' essere incompleto — ma un
+nome fuori catalogo viene segnalato subito, prima che il backend risponda `OBJECT_UNKNOWN` o
+`FIELD_UNKNOWN`. Il campo si chiede sempre con l'uso giusto (`filterable`, `sortable`,
+`updateable`), che decide sia l'elenco sia il testo dell'avviso: "non filtrabile" e "non
+aggiornabile" sono errori diversi. Restano `<select>` i dizionari chiusi — tipi di dato,
+operatori, enumerazioni — dove non c'e' niente da scrivere a mano.
+
+Lo stesso controllo, nella variante `<fb-name-picker>`, vale per **ogni altro nome che il flow
+prende da fuori**: tipo di action e action, script, form, i nomi dei loro parametri di ingresso
+e di uscita, il flow di uno step in background e dei suoi evaluation flow, il flow invocato da
+un Subflow e le variabili di input e output **del flow invocato**. Qui l'elenco arriva da chi
+ospita il picker — il catalogo già caricato per altri motivi, `listSubflowCandidates`, le
+variabili della definizione caricata — perche' dipende dal contesto: le action dipendono dal
+tipo scelto, i parametri dall'action, le variabili dal subflow.
+
+Un elenco vuoto resta "non lo so": il campo si scrive a mano e non si accusa nessun nome. Con
+l'elenco popolato, un nome che non c'e' e' segnalato, e con la **gravita' giusta**: un'action,
+un form, uno script o un parametro inesistenti sono errori che bloccano l'attivazione
+(`ACTION_UNKNOWN`, `FORM_UNKNOWN`, `PARAMETER_UNKNOWN`) e si mostrano in rosso; un flow senza
+versione attiva e' un avviso. Prima questi campi erano `<select>` con un'opzione sintetica
+«(non nel catalogo)» per non perdere il valore, oppure un `datalist` che accettava qualunque
+cosa in silenzio: il primo non si poteva cercare, il secondo non diceva niente.
+
 **Problemi.** Pannello con filtro per gravita', navigazione all'elemento con un clic,
 validazione su pausa di digitazione (debounce 400 ms) e l'avvertenza che l'assenza di rilievi
 non e' una garanzia di correttezza.