Widget Form

I form servono a inserire nuovi record o ad aggiornare record esistenti. La tua app può avere quanti form vuoi, anche per gli stessi oggetti: ad esempio, potresti voler offrire form diversi a utenti diversi o per scopi diversi.

Come creare un widget Form

1. Trascina un widget Form in una pagina.
2. Usa il menu a tendina per selezionare il comportamento desiderato del form (creare un nuovo record o aggiornare uno esistente) e l'oggetto che vuoi creare o aggiornare. Il menu elencherà solo le azioni consentite in quella specifica pagina: ad esempio, se la pagina non fa riferimento a un record specifico, il menu non elencherà l'azione di aggiornamento.
3. Configura il widget Form selezionando i campi che vuoi far compilare agli utenti.

Opzioni generali

Come per gli altri widget, puoi impostare facoltativamente un title e un subtitle che verranno mostrati sopra il form.

Inoltre, puoi definire visibility rules che determinano se, in base alle condizioni che imposti, il widget deve essere mostrato o meno. Ad esempio, potresti voler nascondere un form di contatto per gli ordini contrassegnati come completati.

Per wizard multi-step, usa un widget Stepper dedicato con più form (uno visibile per step). La modalità obsoleta Display as → stepper del form non è più offerta per i nuovi form; le app esistenti che la usano ancora dovrebbero migrare al widget Stepper.

Campi del form

In un form puoi usare quanti campi vuoi, in base ai dati che vuoi far inserire agli utenti (o anche nessun campo se vuoi mostrare solo il pulsante di invio per creare un oggetto vuoto o eseguire Task).

Per ogni campo puoi impostare le seguenti opzioni:

• Label: l'etichetta del campo, come apparirà nel form.
• Instructions: testo aggiuntivo mostrato accanto al campo del form. Puoi usarlo per dare più contesto sui dati che ti aspetti dagli utenti.
• Required: questa opzione contrassegna il campo con un asterisco e impedisce l'invio del form se il campo non è compilato.
• Read-only: questa opzione rende il campo grigio, impedendo all'utente di modificarne il valore. Usala per mostrare un valore senza permettere modifiche — sui form di aggiornamento per il valore corrente del record, o sui form di creazione quando una live formula deve essere visibile ma non modificabile.
• Default value: sui form di creazione, parti da un default fisso o dal default globale del campo; sui form di aggiornamento puoi mantenere il valore corrente o forzare un default quando appropriato.
• No default / require choice: sui form di creazione, per i campi boolean e number (non i rating), parti vuoto invece di 0 / No. L'utente deve scegliere un valore prima di salvare. Per Sì/No, conta entrambe le risposte (a differenza di Required, che significa Sì). I campi Sì/No in stile checkbox vengono mostrati come radio quando questa opzione è attiva.
• Width: larghezza del campo all'interno del form (100%, 75%, 50%, 33%, …) così puoi costruire layout a più colonne.
• Min items / Max items: per i campi Multiple Choice e Reference Array, richiedi o limita quanti valori possono essere selezionati.
• Live formula: calcola il valore del campo nel browser mentre cambiano gli altri campi del form (vedi Live formula).

Puoi anche aggiungere lo stesso campo dell'oggetto più di una volta su un form — ad esempio per mostrare una copia in sola lettura accanto a una modificabile, o per ripetere un valore in un layout multi-step.

Esempio

How to configure it in the builder

How it looks like in the resulting app

Il widget Form ha anche un'impostazione Width (nella scheda del titolo del widget) — da 100% a 16% — così un form può stare accanto a un altro widget sulla stessa pagina.

Live formula

Una Live formula compila un campo del form nel browser mentre l'utente digita — totali, etichette concatenate, date derivate — senza attendere l'invio. A differenza dei campi automatici, il valore viene calcolato sul form stesso e viene salvato solo quando il form viene inviato (come valore normale del campo).

Scenari tipici:

• totale riga = prezzo unitario × quantità;
• un'anteprima dell'etichetta costruita da più campi testo;
• un flag booleano derivato da altre risposte sullo stesso form;
• un'etichetta che include un campo di un record collegato selezionato sul form (ad esempio il nome dell'autore).

Come configurarla

1. Apri le impostazioni del campo del form di destinazione.
2. Inserisci un'espressione in Live formula.
3. Fai riferimento ad altri campi sullo stesso form con segnaposto {field}, oppure un salto attraverso un campo Reference con {reference.field} (ad esempio {author.name}).

Disponibile sui campi text, number, boolean e date/time modificabili (non sui campi password).

Sintassi dell'espressione

L'espressione viene valutata come JavaScript. Ogni {field} viene sostituito con il valore corrente di quel campo sul form. Per un campo Reference sul form, {author.name} usa il name del record collegato (testo, numero, boolean o data/ora — non i campi password, e non percorsi multi-hop come {author.publisher.name}).

Esempi

Espressione	Descrizione
{price}*{qty}	Totale riga da due campi numerici
{year}+'-'+{month}+'-'+{day}	Costruisce una stringa data da parti separate
{firstname}+' '+{lastname}	Anteprima del nome completo
{author.name}+' - '+{title}	Nome dell'autore collegato più un campo di questo form

Regole da tenere a mente:

• Possono essere referenziati solo i campi presenti su questo form (e non il campo stesso).
• I percorsi con punto sono un solo salto attraverso un campo Reference presente sul form (non Reference Array).
• I segnaposto dentro le virgolette non vengono interpolati — scrivi {a}+'-'+{b}, non '{a}-{b}'.
• Se il campo di destinazione è modificabile, l'utente può sovrascrivere il valore calcolato; viene ricalcolato quando cambia una dipendenza.
• Contrassegna il campo come read-only quando vuoi una visualizzazione puramente calcolata che gli utenti non possono modificare (tieni però presente che i campi read-only non vengono salvati nel database — per quello ti serve un campo Auto).

Live formula vs campo automatico

Usa una live formula quando il calcolo ha bisogno solo dei valori attualmente sul form e vuoi feedback immediato. Usa un campo automatico quando il risultato deve essere memorizzato e tenuto aggiornato da record collegati, altri oggetti o funzioni placeholder lato server. Passo per passo: Totale riga con una live formula.

Display rules

Le Display rules cambiano il form mentre l'utente digita — mostrano i campi giusti, applicano vincoli in anticipo ed evidenziano lo stato — così le persone finiscono al primo tentativo invece di scoprire errori dopo l'invio.

Ad esempio, mostra un campo "Company Name" solo quando l'utente seleziona "Company" in un menu a tendina "Type":

Esempio

How to configure it in the builder

How it looks like in the resulting app

Le azioni disponibili per le Display rules includono:

• Show/hide: il campo selezionato verrà mostrato se la condizione configurata è vera, altrimenti nascosto.
• Hide/show: il campo selezionato verrà nascosto se la condizione configurata è vera, altrimenti mostrato.
• Set required: il campo selezionato diventa obbligatorio se la condizione configurata è vera, altrimenti facoltativo.
• Set read-only: il campo selezionato diventa read-only se la condizione configurata è vera, altrimenti modificabile.
• Set read-only (all fields): rende l'intero form read-only quando la condizione corrisponde.
• Rename field: l'etichetta del campo selezionato viene cambiata in un altro valore se la condizione configurata è vera, altrimenti torna al valore originale.
• Set Max Length: limita quanti caratteri possono essere inseriti quando la condizione corrisponde.
• Raise Validation Error: valida usando i valori sul form corrente (vedi Validazione).
• Set Color / Set Label Color / Set Background Color: enfatizza o avvisa visivamente (ad esempio evidenzia in rosso i campi scaduti).

I filtri del Builder sulle Display rules supportano anche operatori come matches / does not match per controlli testuali flessibili.

Tasks

I Task sono azioni eseguibili quando un form viene inviato. Ad esempio, puoi usare un Task del form per:

• inviare un'e-mail all'utente che ha inviato il form o a te;
• creare un nuovo record in un altro oggetto;
• impostare valori per altri campi del record corrente, come modo per fornire default o impostarli secondo una logica condizionale basata sull'input dell'utente;
• interrompere il salvataggio con un errore di validazione quando un controllo su altri record del database fallisce (vedi Validazione).

Un Task si configura selezionando le condizioni in cui deve essere eseguito e configurando una o più azioni da eseguire. Un form può avere quanti Task vuoi, che verranno valutati ed eseguiti nell'ordine configurato.

Le azioni disponibili per i Task includono:

• Send email: invia un'e-mail a un indirizzo fisso (utile per notificare il team) o a un indirizzo preso da un campo dell'oggetto. Vedi Invio e-mail.
• Raise a validation error: interrompe il salvataggio dopo controlli consapevoli del database — vedi Validazione.
• Update this record: imposta altri valori per il record che il form sta creando/aggiornando.
• Create a new record: crea un nuovo record in un altro oggetto.
• Update a connected record: aggiorna uno o più record in un oggetto collegato.

Quando un invio esegue un grafo di Task pesante (più di dieci azioni espanse, o qualsiasi child task annidato), Bobuild elabora salvataggio e Task in modo asincrono e mostra un indicatore di avanzamento fino al redirect o messaggio di follow-up. Gli invii più leggeri restano sincroni.

Pulsante Annulla

I form in popup spesso hanno bisogno di un modo chiaro per uscire senza inviare. Nelle impostazioni del campo submit button del form, abilita Show Cancel button.

Quando è abilitato:

• un controllo Cancel appare accanto al pulsante di invio;
• viene mostrato solo quando il form è visualizzato in una finestra popup (su una pagina normale a schermo intero resta nascosto);
• cliccando Cancel si chiude il popup senza salvare.

Scenari tipici: modifica rapida "in popup" da una griglia, dialoghi per creare record collegati, o qualsiasi form modale in cui gli utenti dovrebbero abbandonare le modifiche senza cercare i controlli della finestra.

Follow-up

Nella sezione follow-up puoi configurare una o più regole per definire dove l'utente verrà reindirizzato dopo l'invio del form. Per impostazione predefinita la pagina corrente viene ricaricata, ma puoi selezionare qualsiasi altra pagina della tua app come destinazione. Puoi anche definire un messaggio facoltativo da mostrare in alto per confermare l'invio riuscito. Queste regole possono essere legate a condizioni, così puoi reindirizzare l'utente in posizioni diverse secondo una logica configurabile.

Per i form che creano o modificano un record di un oggetto usato anche nella pagina di destinazione come oggetto di login utente, avrai anche la possibilità di attivare il flag Auto-login. In questo caso, l'utente che invia il form verrà automaticamente autenticato come l'utente del record inviato. Può essere utile in due situazioni:

1. Stai creando un form di registrazione che crea il record di login dell'utente, quindi vuoi che l'utente sia autenticato automaticamente all'invio del form senza dover autenticarsi.
2. Hai un portale interno per gli operatori e un portale esterno per i clienti, e vuoi permettere agli operatori di accedere come clienti per verificare cosa vedono nella loro area, bypassando la loro autenticazione.

Validazione degli input

Una buona validazione blocca i dati errati in anticipo, evita agli operatori di correggere errori e mantiene affidabili i workflow. Bobuild ti offre quattro livelli — usa il più semplice adatto alla regola.

Scenari tipici:

• un numero di telefono non può essere vuoto e deve restare entro un intervallo di lunghezza;
• "Company name" è obbligatorio solo quando Type è Company;
• la data di inizio deve precedere la data di fine sullo stesso form;
• una prenotazione non deve sovrapporsi a un'altra prenotazione già memorizzata nel database.

1. Vincoli a livello di campo

Impostali sul campo (default dell'oggetto e/o impostazioni del campo del form). Si applicano mentre l'utente compila il form e di nuovo all'invio:

Vincolo	Campi tipici	Effetto
Required	Qualsiasi	Invio bloccato se vuoto
Min length / Max length	Text	Limiti al numero di caratteri
Min / Max	Number	Intervallo numerico (applicato anche lato server)
Min items / Max items	Multiple Choice, Reference Array	Quanti valori possono essere selezionati

Inizia da qui per le regole "sempre vere". Sono facili da capire e non richiedono Display rules o Task.

2. Override condizionali con Display rules

Quando un vincolo dipende da altre risposte sullo stesso form, usa le Display rules per cambiare la validazione dinamicamente:

• Set required — ad es. richiedi Company Name solo quando Type è Company
• Set Max Length — restringi la lunghezza in certe condizioni
• Set read-only — impedisci modifiche quando il record è bloccato

Così un solo form copre più casi senza duplicare pagine.

Nelle Display rules puoi anche usare gli operatori matches / does not match per applicare validazione regex sui campi testuali.

Esempi utili di controllo formato (verificano la forma del valore, non checksum come le cifre di controllo dell'IBAN o del codice fiscale):

Caso d'uso	Regex
Codice fiscale italiano (persona fisica)	^[A-Z]{6}[0-9LMNPQRSTUV]{2}[ABCDEHLMPRST][0-9LMNPQRSTUV]{2}[A-Z][0-9LMNPQRSTUV]{3}[A-Z]$
Partita IVA / CF italiano (azienda)	^[0-9]{11}$
Codice IPA / SDI italiano (6 caratteri)	^[A-Z0-9]{6}$
IBAN italiano	^IT[0-9]{2}[A-Z][0-9]{10}[0-9A-Z]{12}$
Codice postale francese	^[0-9]{5}$
SIRET francese	^[0-9]{14}$
IBAN francese	^FR[0-9]{12}[0-9A-Z]{11}[0-9]{2}$
DNI / NIF spagnolo	^[0-9]{8}[A-Z]$
CIF spagnolo	^[ABCDEFGHJKLMNPQRSUVW][0-9]{7}[0-9A-J]$
IBAN spagnolo	^ES[0-9]{22}$
CAP statunitense	^[0-9]{5}(-[0-9]{4})?$
Social Security Number statunitense	^[0-9]{3}-[0-9]{2}-[0-9]{4}$
Numero di telefono E.164	^\+[1-9][0-9]{6,14}$
Data ISO (YYYY-MM-DD)	^[0-9]{4}-[0-9]{2}-[0-9]{2}$
Indirizzo e-mail (pratico)	^[^\s@]+@[^\s@]+\.[^\s@]+$
URL (http / https)	^https?://[^\s]+$
UUID	^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

Preferisci input in maiuscolo (o normalizza prima del salvataggio) per identificativi come codice fiscale, IBAN e codici SDI/IPA, dato che i pattern sopra sono case-sensitive.

3. Logica cross-field sul form (Display rule "Raise Validation Error")

Quando la regola confronta più valori digitati nel form — e non ha bisogno di altre righe nel database — aggiungi una Display rule con Raise Validation Error:

• scegli il campo che deve mostrare l'errore
• imposta la condizione (i filtri possono combinare più campi; gli operatori includono matches / does not match)
• scegli Immediately (mentre l'utente digita) o On submit
• scrivi il messaggio che vedranno gli utenti

Esempi: data di inizio dopo la data di fine; due campi password che devono coincidere; una checkbox che deve essere spuntata quando un totale supera una soglia.

suggerimento

Preferisci questo livello quando tutto ciò che serve è già sul form. Gli utenti ricevono feedback prima o all'invio, e un campo specifico può essere evidenziato. Quando l'utente modifica il campo che ha fallito la validazione, il messaggio di errore viene cancellato automaticamente.

4. Controlli consapevoli del database (Task "Raise a validation error")

Le Display rules non possono guardare altri record già memorizzati nel database. Per quei controlli, collega un Task del form con l'azione Raise a validation error.

Esempi tipici:

• un intervallo di date non deve sovrapporsi a un'altra prenotazione;
• unicità che copre due campi alternativi;
• una somma che deve corrispondere a righe collegate o campi automatici calcolati da dati connessi.

Come funziona: all'invio Bobuild salva il record ed esegue i Task del form nella stessa transazione del database. Se viene eseguito Raise a validation error:

1. le azioni Task rimanenti si fermano
2. la transazione viene annullata (la creazione/aggiornamento non viene mantenuta)
3. il messaggio configurato viene mostrato in un dialogo

Poiché il controllo viene eseguito dopo il salvataggio temporaneo, i campi automatici sul record sono già calcolati e possono essere usati nelle Conditions del Task.

Configura:

• Conditions sul Task — quando sollevare l'errore (spesso un campo automatico che conta righe in conflitto)
• Error message — messaggio globale (non legato a un singolo campo)

suggerimento

Usa vincoli di campo e validazione con Display rules per il percorso comune; riserva la validazione con Task per le regole che hanno davvero bisogno del resto del database. La stessa azione Task è disponibile sugli endpoint API Create/Modify.