Symfony 8.2: nei form dinamici il problema non è aggiungere righe, è sapere quali sono

Un form dinamico sembra semplice finché le righe sono tutte uguali e nessuno cambia il loro ordine. Aggiungi un elemento, lo elimini, lo trascini più in alto. Poi il progetto cresce: un CMS deve gestire blocchi di testo, immagini, call to action e configurazioni diverse nello stesso editor. A quel punto non stai più costruendo una lista di campi. Stai costruendo un piccolo sistema di dati, con identità, tipi e regole di aggiornamento.

Le novità annunciate per Symfony 8.2 affrontano proprio due limiti storici di CollectionType: la necessità di usare lo stesso tipo di form per ogni elemento e l’associazione delle righe alla loro posizione. Non è soltanto una comodità per chi sviluppa interfacce. È un cambiamento che obbliga a ragionare su cosa significhi aggiornare correttamente un record.

Quando la posizione viene scambiata per identità

Immagina un editor che salva tre blocchi: una descrizione, un’immagine e una scheda tecnica. Se il backend interpreta il primo elemento inviato come il primo elemento già presente, basta un riordinamento per rendere ambigua la corrispondenza. In una lista omogenea questo rischio può restare nascosto; in una collezione eterogenea, invece, la confusione fra indice e identità emerge subito.

Il punto è che l’ordine descrive dove si trova una riga, non quale riga sia. Sono due informazioni diverse. Chi sviluppa applicazioni gestionali, configuratori o CMS dovrebbe tenerle separate già nel modello, prima ancora di occuparsi dell’interfaccia drag and drop.

PolymorphicCollectionType: tipi diversi, una collezione

Symfony 8.2 introduce PolymorphicCollectionType, pensato per collezioni nelle quali le singole voci possono richiedere form differenti. La configurazione può dichiarare più tipi tramite entry_types e delegare la selezione a un entry_type_provider. Questo consente, per esempio, di rappresentare blocchi editoriali differenti senza forzarli dentro un unico form sovraccarico di campi condizionali.

Il provider distingue due passaggi, forModelData e forSubmittedData. La distinzione conta: quando costruisci il form a partire dai dati già salvati, conosci il tipo dell’oggetto; quando ricevi una richiesta, devi invece interpretare il tipo dichiarato dall’input. Trattare queste due situazioni come equivalenti significa dare per scontato proprio ciò che dovrebbe essere validato.

Non è un invito a fidarsi del tipo indicato dal browser. La scelta del form, le trasformazioni e le autorizzazioni devono continuare a essere controllate lato server. Il componente offre un meccanismo di composizione; non sostituisce il modello di sicurezza dell’applicazione.

entry_name: un nome stabile invece di un indice fragile

La seconda novità è entry_name, disponibile per CollectionType e PolymorphicCollectionType. Permette di derivare il nome di una voce da un property path o da una callable, anziché affidarsi soltanto all’indice numerico. In pratica puoi rappresentare l’identità della riga con una chiave che rimane significativa anche quando la posizione cambia.

È una distinzione che in un database sembra ovvia: non useresti normalmente il numero della riga visualizzata come chiave primaria. Nei form, però, l’abitudine a costruire nomi come items[0], items[1] e items[2] ha reso facile confondere rappresentazione e identità. entry_name aiuta a esplicitare questo confine.

Un’interfaccia può cambiare l’ordine degli elementi. Non dovrebbe cambiare, per questo, il significato dei dati che stai salvando.

La trappola delle collisioni con allow_add

Un identificatore stabile non risolve tutto automaticamente. La documentazione della novità richiama un caso delicato: con allow_add, un nome già presente può essere interpretato come riferimento a una voce esistente anziché come nuova voce. Se il client genera chiavi duplicate, rischi di aggiornare un elemento diverso da quello atteso.

Per questo una collezione robusta deve stabilire chi assegna gli identificatori, come vengono verificati, cosa accade in caso di duplicati e quali operazioni sono consentite su ogni elemento. Non basta scegliere un UUID e considerare concluso il lavoro. Serve una regola di dominio, soprattutto quando più utenti possono intervenire sugli stessi dati.

Che cosa cambia davvero per CMS e gestionali

Il vantaggio più interessante non è scrivere meno codice per mostrare blocchi differenti. È poter modellare una collezione eterogenea senza perdere la tracciabilità delle singole voci. Un editor di landing page, un configuratore di prodotti o un gestionale con sezioni ripetibili hanno tutti bisogno di distinguere il tipo dell’elemento, la sua identità e il suo ordine.

Questa separazione aiuta anche i test: puoi verificare che un riordinamento non scambi i dati, che un tipo non autorizzato venga respinto, che l’inserimento con una chiave duplicata non sovrascriva silenziosamente una voce e che una modifica parziale non alteri campi non coinvolti. Sono controlli più importanti dell’effetto visivo con cui trascini un blocco.

Chi segue l’evoluzione del framework può leggere anche l’analisi delle nuove verifiche di ExpressionLanguage in Symfony 8.2: il filo conduttore è simile. Un sistema maturo cerca di rendere gli errori visibili nel punto in cui nascono, non quando sono già diventati dati incoerenti o configurazioni in produzione.

Una novità da valutare, non da installare alla cieca

Al momento dell’annuncio Symfony 8.2 è ancora in sviluppo. Prima di adottare questi componenti in produzione bisogna verificare API definitive, compatibilità con il proprio stack, comportamento dei transformer e casi limite dei form esistenti. Una migrazione sensata parte dai test sulle collezioni che oggi dipendono dagli indici, non dalla sostituzione indiscriminata dei tipi di campo.

La lezione, comunque, va oltre Symfony: quando un’applicazione comincia a gestire dati eterogenei e modificabili, l’identità deve essere una proprietà esplicita del sistema. Il framework può offrirti gli strumenti. Decidere quali invarianti proteggere resta un lavoro di architettura.