@esfaenza/flow-builder 20.3.33 → 20.3.35

package/README.md

@@ -341,6 +341,26 @@ Tre cose che il modello non mostra e il form dice:
 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».
 
+**Transform (§5.13).** Anche questo e' un compositore e non un form: **tre colonne** — le sorgenti,
+la destinazione, il dettaglio della riga scelta. Si mappa **trascinando** una sorgente su una
+destinazione, oppure selezionando la destinazione e cliccando la sorgente; il bersaglio del rilascio
+si calcola dal DOM, come nello screen dinamico.
+
+Le due cose che il modello non mostra e la colonna centrale dice:
+
+- **le righe sono le destinazioni, non le azioni.** Vengono dal catalogo del risultato — i membri
+  della classe (§4.7.1) o i campi dell'entita' (§4.4) — quindi si vede anche cio' che **non e'**
+  ancora mappato, che nell'elenco delle `transformValueActions` non compariva. Una riga esiste prima
+  dell'azione: la prima modifica la crea. Un membro calcolato non c'e' affatto, perche' assegnarlo e'
+  `TARGET_NOT_WRITABLE`. Dove il catalogo non e' autorevole — una classe che non dichiara i membri, un
+  risultato scalare — le righe tornano a essere le azioni e il nome si **digita**, senza che nessuno
+  venga accusato di non esistere;
+- **le sorgenti si navigano.** Sono i riferimenti di `POST /flows/references`, e dentro un record o
+  una classe si entra per proporne campi e membri, con la regola del reference picker: gli output
+  automatici si **propongono** e non si giudicano (§4.5). `aggregationField` di un `Sum` resta il
+  **nome** di un campo (`stringValue`), ma dove il tipo della collection aggregata e' noto lo si
+  sceglie da un elenco invece di ricordarlo.
+
 **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
@@ -655,9 +675,19 @@ non ne cambia il comportamento. Quattro conseguenze, tutte visibili nell'editor:
   che nomina un elemento cancellato e' cio' che resta dopo la cancellazione: l'editor offre di
   ripulirlo con un comando e non lo fa di soppiatto mentre si trascina qualcos'altro.
 
-Chiuso, il riquadro resta la sola barra del titolo e **gli elementi restano visibili**: nasconderli
-vorrebbe dire connettori con `display: none`, cioe' geometria 0×0 e archi attaccati nel punto
-sbagliato.
+**Chiuso, il riquadro nasconde cio' che contiene.** Al posto dei suoi elementi compare una
+**pastiglia** col titolo, quanti elementi sta nascondendo e i loro rilievi sommati — chiudere un
+riquadro non zittisce un errore. Gli archi interni non si disegnano, quelli che entrano nel riquadro
+o ne escono si riattaccano alla pastiglia e portano nell'etichetta il nome dell'elemento nascosto,
+che e' l'unica informazione che chiudere ha portato via. Si sposta come la cornice (i membri vengono
+dietro), si apre con il suo triangolo o con un doppio clic, e si elimina senza toccare gli elementi.
+
+Due limiti che sono scelte: gli archi con un capo sulla pastiglia **non si riassegnano e non si
+innestano** — dietro un solo connettore stanno elementi diversi, e non c'e' modo di sapere quale si
+intendeva, quindi per collegare o innestare si apre il riquadro; e trascinare un elemento sopra una
+pastiglia **non lo aggiunge** al riquadro chiuso, perche' sarebbe un elemento che sparisce.
+Cercarne uno che sta dentro un riquadro chiuso lo **apre**: la ricerca promette l'elemento, non la
+sua scatola.
 
 **Import/export.** Export JSON indentato; import via `POST /flows/parse`, che normalizza il
 documento o lo rifiuta con `InvalidDefinition`.