@esfaenza/flow-builder 20.3.4 → 20.3.6

package/README.md

@@ -235,12 +235,30 @@ non ha nulla da istanziare — mentre il campo «valore iniziale» non c'e' affa
 esiste un `structureValue` e la variabile parte con un'istanza vuota. I membri si scelgono con
 `<fb-structure-member-picker>`, e nelle destinazioni si propongono **solo** quelli scrivibili: un
 membro calcolato si legge in una condizione ma assegnarlo e' `TARGET_NOT_WRITABLE`. Lo stesso
-vale dentro `<fb-reference-picker>`, dove i membri di una variabile `Structure` sono l'unica
-eccezione ai percorsi non verificati: `Richiesta.Ragione` si propone e il **primo** segmento si
-verifica (`STRUCTURE_MEMBER_UNKNOWN`), oltre quello si torna a "non lo so" — la descrizione della
-classe e' piatta, e i membri di una classe annidata sono una seconda chiamata (§4.7.1). Un
-Transform con target `Structure` compone l'istanza intera in un elemento solo: lì
-`outputFieldApiName` e' il nome di un membro, e il form lo dice invece di far indovinare (§5.12).
+vale dentro `<fb-reference-picker>`, dove `Richiesta.Ragione` si propone e si verifica
+(`STRUCTURE_MEMBER_UNKNOWN`). Un Transform con target `Structure` compone l'istanza intera in un
+elemento solo: lì `outputFieldApiName` e' il nome di un membro, e il form lo dice invece di far
+indovinare (§5.12).
+
+**Percorsi annidati.** I percorsi con il punto non sono piu' un buco nero: la validazione li segue,
+e quindi li segue l'editor. `core/path-navigation.ts` naviga la catena una tappa alla volta —
+`objectType` di un membro `Structure` porta la classe annidata, quello di un membro `Object` porta
+un'**entita' dello schema**, e da lì si continua con i campi (§4.7.1) — ed e' lo stesso codice per
+i membri di una classe e per i percorsi di relazione di un record (`Cliente.Citta`, §4.4). Tre
+conseguenze visibili: i pickers propongono **il livello in cui si sta scrivendo** e hanno un «›»
+per scendere di uno; un refuso in mezzo (`Richiesta.Clente.Nome`) e' segnalato subito, con l'elenco
+di cio' che esiste in **quella** tappa; e dove la catena si interrompe — un membro senza
+`objectType`, una classe annidata non descritta, una collection — il rilievo e' l'avviso
+`PATH_NOT_VERIFIABLE` con il **motivo**, che vuol dire "non lo so" e non impedisce di scrivere.
+Restano fuori i percorsi radicati sul risultato **automatico** di un elemento
+(`Leggi_Contatti.Owner.Name`): la validazione non li verifica, e l'editor non accusa cio' che il
+backend non verifica.
+
+Su una destinazione la colonna che decide non e' la stessa nei due mondi: un membro porta il proprio
+`isWritable`, un campo no. Fuori da un Create o da un Update il contesto non c'e' — un Assignment su
+`Cliente.Codice` non sa se quel record verra' creato o aggiornato — quindi lì basta `isCreateable`
+**oppure** `isUpdateable`, e un campo che non e' ne' l'uno ne' l'altro e' `TARGET_NOT_WRITABLE` in
+qualunque contesto (§5.7).
 
 Dei tre esiti di `describeStructure` il picker mostra tre messaggi diversi, perche' portano a
 gesti opposti: con l'elenco autorevole un nome fuori elenco e' un errore; con `members: []` la
@@ -253,10 +271,10 @@ ragione per cui la risposta ha un involucro invece di essere un array.
 `<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`,
+campo di testo cieco. La scrittura libera e' voluta — 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`. I percorsi di relazione (`Cliente.Citta`) si **navigano**: l'elenco diventa quello
+dell'oggetto referenziato e l'ultimo segmento si verifica con l'uso richiesto (§4.4). Il campo si chiede sempre con l'uso giusto (`filterable`, `sortable`,
 `updateable`, `createable`), che decide sia l'elenco sia il testo dell'avviso: "non filtrabile",
 "non aggiornabile" e "non valorizzabile alla creazione" sono errori diversi. In particolare
 `createable` e `updateable` **non** sono sinonimi (§5.7): un Create propone i primi, un Update i
@@ -411,7 +429,7 @@ distribuire e nessuna dipendenza da un font di icone dell'applicazione ospite.
 | 13 | **Testo e numero non si confrontano** (`CONDITION_TYPE_MISMATCH`) | `ConditionEditorComponent` conosce il tipo del lato sinistro da `POST /flows/references`: filtra gli operatori applicabili, guida il campo del letterale del secondo operando e segnala la coppia vietata. La regola sta in `core/condition-types.util.ts`, che salta gli operatori con semantica propria (`Contains`, `In`, …). I numeri si scrivono in cultura invariante: `1234,50` viene tradotto in `1234.50`, non troncato |
 | 14 | **`None` non e' un operatore, e' un "da completare"** | Condizione evidenziata come incompleta, con il conteggio in testa alla sezione e la frase «la bozza si salva, l'attivazione no»; il validatore della demo lo emette come **errore** |
 | 15 | **Un valore data senza `Z` significa ora locale** | `ValueEditorComponent` ha un selettore «Ora locale / UTC (Z)», dice che cambiare fuso riscrive l'orario e non lo converte, e toglie il suffisso solo per il controllo `datetime-local`, che con il fuso resterebbe vuoto |
-| 16 | **`Structure` e `Object` non sono intercambiabili** | `StructurePickerComponent` per la classe (fuori catalogo = **errore**, `STRUCTURE_TYPE_UNKNOWN`) e `StructureMemberPickerComponent` per i membri, filtrati su `isWritable` dove serve una destinazione. Il pannello risorse mostra la classe come obbligatoria con severita' di errore e **non** mostra il valore iniziale, perche' un `structureValue` non esiste; `ReferencePickerComponent` propone `Variabile.Membro` e verifica il primo segmento; il Transform con target classe chiede un membro invece di un campo. `FlowDictionaryStore.isStructure` legge il flag dal dizionario, non dal nome del tipo. La risposta dei membri e' la **descrizione della classe** (`{className, label, members}`), e i suoi tre esiti restano distinti fino alla UI: `FlowCatalogStore.describeStructure` li traduce in `declared` / `undeclared` / `unknown-class` / `unknown-catalog`, e solo `declared` autorizza a dire che un membro non esiste (§4.7.1) |
+| 16 | **`Structure` e `Object` non sono intercambiabili** | `StructurePickerComponent` per la classe (fuori catalogo = **errore**, `STRUCTURE_TYPE_UNKNOWN`) e `StructureMemberPickerComponent` per i membri, filtrati su `isWritable` dove serve una destinazione. Il pannello risorse mostra la classe come obbligatoria con severita' di errore e **non** mostra il valore iniziale, perche' un `structureValue` non esiste; `ReferencePickerComponent` propone `Variabile.Membro` e verifica il percorso **fino in fondo** con `core/path-navigation.ts`, con `PATH_NOT_VERIFIABLE` dove la catena si interrompe; il Transform con target classe chiede un membro invece di un campo. `FlowDictionaryStore.isStructure` legge il flag dal dizionario, non dal nome del tipo. La risposta dei membri e' la **descrizione della classe** (`{className, label, members}`), e i suoi tre esiti restano distinti fino alla UI: `FlowCatalogStore.describeStructure` li traduce in `declared` / `undeclared` / `unknown-class` / `unknown-catalog`, e solo `declared` autorizza a dire che un membro non esiste (§4.7.1) |
 
 Altre regole del contratto rispettate: liste vuote omesse invece di scritte come `[]` (§2),
 `filterLogic` mostrato **solo** dove il modello lo prevede (§4.4), `fullName` / `status` mai