FileMaker 2026: la rivoluzione silenziosa dei tool a riga di comando
C’è un filo che attraversa FileMaker 2026 e che rischia di passare inosservato tra le novità più appariscenti come l’AI e il Remote Backup. È un filo sottile ma robusto, fatto di XML, di terminali, dell’inizio di uno sviluppo basato su XML, e di automazione. È la storia di come Claris abbia deciso, con questa release, di trasformare seriamente il modo in cui gli sviluppatori lavorano con le soluzioni FileMaker al di fuori dell’interfaccia grafica.
I protagonisti di questa storia sono tre: FMDeveloperTool, FMUpgradeTool e e il potenziamento della funzione Salva copia come XML presente in FileMaker Pro. Presi singolarmente, ciascuno porta miglioramenti concreti. Presi insieme, delineano qualcosa di più ambizioso: una piattaforma di sviluppo dove FileMaker può partecipare a workflow DevOps, a pipeline automatizzate e persino a scenari di generazione assistita dall’AI.
Non è una direzione casuale. Nel suo articolo pubblicato il 5 maggio 2026 sul blog Claris, il CEO Ryan McCann è esplicito sulla strategia: Claris sta lavorando per rendere FileMaker un obiettivo di sviluppo prioritario all’interno degli strumenti di programmazione agentica, con agenti AI che leggono lo schema del file, comprendono il linguaggio di scripting e scrivono script e oggetti nativi direttamente nella soluzione. Perché tutto questo sia possibile, però, serve un’infrastruttura e un linguaggio documentato, e i tool di questa versione rappresentano i primi esponenti di quell’infrastruttura.
Salva copia come XML: non è più il vecchio DDR
Per anni, l’unico modo per esportare la struttura di una soluzione FileMaker in forma testuale è stato il DDR (sigla per Database Design Report) uno strumento pensato per la documentazione, non per l’automazione. Il DDR produceva un file XML monolitico, spesso enorme, che includeva tutto e non era facile da gestire programmaticamente. Oppure un HTML che aveva come unico pregio quello di poter essere letto da un essere umano. Un intero ecosistema di tool di analisi (BaseElements, Inspector Pro, FMPerception, solo per citarne alcuni) è fiorito proprio attorno a questo output.
FileMaker 18 ha affiancato un nuovo comando, con una diversa filosofia: Salva copia come XML. Leggermente diverso nella sintassi e focalizzato sul singolo file piuttosto che su tutti i file della soluzione.
FileMaker 2026 aggiunge flessibilità a Salva copia come XML: adesso è possibile selezionare esattamente quali aree — più precisamente catalog in inglese — includere nell’output. Si può scegliere di esportare solo gli script, solo i layout, solo le relazioni, o qualsiasi combinazione tra i venti cataloghi disponibili — da AccountsCatalog a ValueListCatalog, passando per ScriptCatalog, FieldCatalog, ThemeCatalog e molti altri.
La novità più importante è la possibilità di suddividere l’output in file separati per area. Invece di un unico XML da decine di migliaia di righe, si ottiene una directory organizzata di file più piccoli e gestibili, ognuno dedicato a un aspetto specifico della soluzione. Trovare le differenze tra due versioni degli script diventa molto più semplice, così come alimentare un sistema di version control o isolare la parte di schema su cui si sta lavorando.
C’è anche il controllo sul posizionamento dei dati binari. In precedenza, i dati binari associati agli oggetti di layout venivano riportati sia direttamente nel codice che nel LibraryCatalog, con duplicazione. Ora lo sviluppatore può scegliere: tenerli nel LibraryCatalog centralizzato, oppure includerli direttamente sotto il nodo dell’oggetto a cui appartengono. La prima opzione è più compatta, la seconda è più autonoma — utile quando si vuole lavorare su un sottoinsieme di layout senza portarsi dietro tutto il catalogo.
Queste stesse opzioni sono disponibili anche da riga di comando tramite FMDeveloperTool, con il comando --saveAsXMLarricchito di nuovi parametri: -catalog_list per specificare i cataloghi da includere, -split_catalogs per suddividere l’output in file separati, -standalone_binaryData per controllare il posizionamento dei binari, e -include_ddrinfo per includere informazioni aggiuntive in stile DDR. Questo rende l’intera operazione automatizzabile senza dover aprire l’interfaccia grafica.
FMDeveloperTool: nuove capacità dalla CLI
Il FMDeveloperTool riceve in questa versione un’estensione significativa alla sua interfaccia a riga di comando. La novità più concreta è la possibilità di cambiare le password degli account di un database direttamente dalla CLI, con la nuova sintassi --changeAccountPassword. Il comando accetta il file sorgente, il nome utente dell’account amministratore con cui autenticarsi, la sua password, e opzionalmente la chiave di cifratura del file. Si può poi specificare un account target diverso dall’account autenticante e una nuova password da impostare:
FMDeveloperTool --changeAccountPassword <source_filename> <username> <password>
[-encryption_key | -e <key>]
[-target_useraccount | -tu <accountname>]
[-new_password | -np <password>]Per chi gestisce deployment automatizzati di soluzioni FileMaker, questo è tutt’altro che un dettaglio minore. Significa poter inserire la rotazione delle credenziali in una pipeline di deployment senza dover aprire FileMaker Pro, senza dover interagire manualmente con la UI.
L’altro miglioramento riguarda --sortBySize: questo comando ora restituisce i Table ID allineati con quelli del file TopCallStats.log, insieme ai nomi delle tabelle corrispondenti. Prima c’era un disallineamento che rendeva difficile correlare i dati di performance con le tabelle reali. Ora il profiling delle performance diventa finalmente leggibile e correlabile con i log di server.
FMUpgradeTool: da patcher a generatore di database
La trasformazione più radicale — e quella che ha più implicazioni a lungo termine — riguarda il FMUpgradeTool, che acquisisce una capacità del tutto nuova: generare file .fmp12 a partire da file XML.
FMUpgradeTool è stato rilasciato con la versione 19, più come proof-of-concept che come strumento con un utilizzo pratico — non perché non funzionasse, ma perché la creazione del file di patch XML da applicare era quasi interamente manuale, e prendeva talmente tanto tempo da risultare poco pratica. Claris ha continuato ad aggiornarne le funzioni nel tempo, fino a cambiare lo scenario: con FileMaker 2026, FMUpgradeTool è ora in grado di leggere un file XML formattato secondo la grammatica XML 2.0 e generare da esso un file .fmp12 funzionante, tramite il comando:
FMUpgradeTool --generateDBFile -src_path <percorso_al_file_xml>Fino ad oggi, il ciclo di vita di uno schema FileMaker era necessariamente monodirezionale: si lavorava nel file, si poteva esportare lo schema in XML, ma non si poteva tornare indietro. L’XML era documentazione, non sorgente. Il flusso diventa bidirezionale: si esporta la struttura di una soluzione in XML tramite Salva copia come XML, si modifica il testo — rinominando campi, aggiornando script, cambiando etichette di layout — e poi si genera un nuovo file FileMaker che rispecchia le modifiche. Le possibilità sono notevoli: modifiche massive nei nomi dei campi, modifica dell’XML mediante procedure automatiche o agenti AI, e in futuro generazione di soluzioni prototipo direttamente da template XML.
Vale la pena ricordare onestamente i limiti attuali, che sono accuratamente documentati. In particolare, la gestione XML non è ancora completa: alcuni elementi dello schema non vengono preservati nella creazione, tra cui
- i flag di metadati del database (griglie, guide, righelli),
- la vista tabella nei formati,
- le funzioni personalizzate che utilizzano altre funzioni personalizzate,
- i campi nelle tabelle ombra ESS,
- i formati numerici con segno.
Sono limitazioni note che ci si aspetta vengano ridotte nelle versioni successive.
Anche le capacità di ReplaceAction nella funzione di patching hanno vincoli importanti da tenere presenti:
- Modificare uno script richiede di sostituire l’intero script, non le singole istruzioni, con la conseguenza di rompere tutti i riferimenti a quello script.
- Le funzioni personalizzate non possono essere modificate nelle formule: vanno eliminate e ricreate.
Il problema è che il tool conferma comunque la corretta applicazione indipendentemente dall’esito reale, il che significa che ogni patch deve essere verificata manualmente in FileMaker. Sono comportamenti da gestire prima di implementare qualunque procedura in produzione, cosa che rende il tool non è ancora maturo. Tuttavia è un passo avanti impressionante, che aspettavamo da anni.
Metadati di schema: commenti, annotazioni e DDL per l’AI
Fin qui abbiamo parlato di come esportare e manipolare lo schema. Ma la qualità di quello schema — quanto è comprensibile, quanto è documentato, quanto è leggibile da un sistema esterno — è altrettanto importante. Ed è qui che FileMaker Pro 2026 introduce una serie di novità che completano il quadro in modo significativo.
La prima è la nuova funzione di calcolo CommentoTabellaBase(fileName; tableName), che restituisce il commento associato a una tabella (non Occorrenza di Tabella, proprio Tabella). Può sembrare una piccola aggiunta, ma le implicazioni sono notevoli: i commenti delle tabelle erano già definibili nella gestione Database, ma fino ad ora erano informazioni statiche, visibili solo nell’interfaccia. Ora diventano metadati accessibili ad altre tecnologie, utilizzabili in script, in funzioni personalizzate, in payload JSON inviati a sistemi esterni, nei prompt manuali per le connessioni AI e naturalmente inclusi nell’output XML. Uno sviluppatore può finalmente costruire strumenti di documentazione automatica, console di amministrazione dinamiche, o sistemi di controllo dello schema che si aggiornano al variare della soluzione.
La seconda novità, più sottile ma forse più profonda, riguarda l’annotazione dei campi per l’AI. In FileMaker 22.0 era stato introdotto il tag [LLM] nei commenti dei campi, come modo per fornire contesto ai modelli linguistici sul significato di un campo al di là del suo nome tecnico. Il problema di quel sistema era la promiscuità: l’annotazione per l’AI e il commento leggibile dall’utente convivevano nello stesso testo, con conseguente fragilità e scarsa manutenibilità.
FileMaker 2026 separa i due concetti. In Gestione Database, cliccando sul pulsante Avanzate posto accanto al commento di un campo, si accede a una nuova sezione dedicata all’annotazione AI, indipendente dal commento testuale. L’annotazione è una stringa JSON che può definire nomi di visualizzazione alternativi per contesti diversi (esportazione, ordinamento, vista tabella, interfaccia comune) tramite chiavi come fm_export, fm_sort, fm_table_viewe fm_common. C’è anche una checkbox esplicita per includere o escludere il campo dal DDL inviato ai modelli AI: una forma di controllo granulare su cosa i modelli “vedono” dello schema.
La funzione di calcolo AnnotazioneCampo(fileName; fieldName) completa il meccanismo, rendendo accessibile a runtime l’intera annotazione JSON di un campo — e quindi utilizzabile negli stessi contesti in cui si usa BaseTableComment: script, JSON, prompt AI, strumenti di documentazione.
Mettendo insieme questi elementi, emerge un sistema di metadati di schema a tre livelli: il nome tecnico del campo (invariante, usato internamente), il commento testuale (documentazione per sviluppatori), e l’annotazione JSON (metadata strutturato per sistemi esterni e AI). È una separazione pulita e ben pensata, che risolve la tensione tra convenzioni di naming interne e rappresentazione pubblica dello schema, un problema che chiunque abbia mai dovuto mantenere una soluzione con nomi di campo come a014__nomeContattoPrincipale o z_ordinamentoportale conosce bene.
Tutto questo si collega direttamente ai tool a riga di comando: quando si esporta uno schema con Salva copia come XML o con --saveAsXML, questi metadati vengono inclusi nell’output. L’XML che esce dal sistema non è più solo struttura, è struttura annotata, documentata, pronta per essere consumata da strumenti che ragionano sul significato, non solo sulla forma.
La command line come catalizzatore AI
Con questi pezzi al loro posto, il quadro complessivo diventa più chiaro, e si allinea precisamente con la direzione strategica che McCann delinea nel suo articolo. Il CEO descrive agenti AI capaci di leggere lo schema del file, comprendere il linguaggio di scripting e scrivere script nativi direttamente nella soluzione, seguendo le migliori metodologie operative dello sviluppatore. Aggiunge che è possibile introdurre il proprio approccio, con standard di programmazione, convenzioni per l’assegnazione dei nomi e modelli di progettazione propri. Tutto questo presuppone che lo schema sia leggibile, annotato e accessibile programmaticamente: esattamente ciò che le novità descritte in questo articolo rendono possibile.
Un modello linguistico comprende le relazioni tra tabelle se vengono espresse con la sintassi FOREIGN KEY, una sintassi SQL familiare e machine-readable, ora supportata nel parser FQL di FileMaker Server. Può leggere un export XML di una soluzione e ragionare sulla sua struttura. Può interpretare le annotazioni dei campi per capire il significato di a014__nomeContattoPrincipale senza dover indovinare dalle convenzioni di naming. Può generare XML che descrive tabelle, campi, relazioni e script, e quel XML può essere convertito in un file FileMaker funzionante tramite FMUpgradeTool. La pipeline completa :
descrizione testuale → XML annotato → file.fmp12
è ora tecnicamente praticabile, anche se siamo ancora in una fase sperimentale con limitazioni reali da considerare.
Le prime anteprime per sviluppatori della funzionalità di programmazione agentica dovrebbero arrivare nell’estate 2026, dopo il rilascio di FileMaker 2026: quello che questa release consegna oggi è l’infrastruttura su cui quella funzionalità si appoggerà. I tool a riga di comando sono le fondamenta di quel ponte, e i metadati dello schema sono il linguaggio che lo percorre.
Cosa significa in pratica per chi sviluppa soluzioni
Per il consulente FileMaker che lavora su soluzioni di medie dimensioni, il vantaggio immediato è la gestibilità. Avere l’XML della soluzione suddiviso per catalogo, gestibile con Git, comparabile con un tool standard per identificare le differenze a livello di nodo, significa poter finalmente applicare alle soluzioni FileMaker le stesse pratiche di change management che si usano nel resto dello sviluppo software.
Aggiungere commenti alle tabelle e annotazioni ai campi per anni è stata vista come un qualcosa di inutile – complice anche la difficoltà di consultazione lato interfaccia. Ora non è più solo buona pratica documentale, è diventato un investimento in un’infrastruttura che paga dividendi ogni volta che uno strumento esterno, umano o artificiale, deve interagire la soluzione.
Anche McCann nel suo post inquadra il cambiamento di prospettiva in termini più ampi: quando il codice è abbondante, chi capisce il contesto diventa la risorsa più rara. Gli sviluppatori FileMaker hanno lavorato in questo modo per decenni — il loro ruolo non è mai stato scrivere ogni singola riga di codice, ma progettare e orchestrare le soluzioni comprendendo l’azienda abbastanza a fondo da tradurne le esigenze in software che regge in condizioni reali. Le novità di questa release potenziano esattamente quella capacità: rendono lo schema più espressivo, più automatizzabile, più comprensibile ai sistemi che verranno a supportare quel lavoro.
Per chi gestisce deployment su scala più ampia, come hosting provider, o solution provider con clienti multipli, la possibilità di automatizzare il deployment delle nuove versioni, gestire la rotazione delle password e di scriptare operazioni di patching strutturale riduce sensibilmente il costo operativo della manutenzione.
Per chi costruisce strumenti di terze parti, come analizzatori di schema, generatori di documentazione o sistemi di testing automatizzato, l’export XML granulare, controllato e arricchito di metadati è un’infrastruttura su cui costruire con molto più controllo di quanto fosse possibile prima.
FileMaker 2026 non ha trasformato la command line in un’interfaccia di primo livello — la piattaforma rimane orientata alla GUI. Ma ha compiuto passi concreti e deliberati verso un ecosistema in cui lo sviluppo, il deployment e la manutenzione delle soluzioni possono essere automatizzati, scriptati, e integrati con il resto della toolchain moderna. E ha dotato quello schema di un vocabolario semantico che lo rende comprensibile non solo agli sviluppatori, ma anche ai sistemi che verranno dopo di loro.
L’unica cosa che adesso manca è una documentazione più strutturata della sintassi XML degli oggetti FileMaker: ma la aspettiamo prestissimo.
Vuoi automatizzare la tue procedure di gestione degli aggiornamenti della tua soluzione o della tua infrastruttura al meglio e ti serve un FMGuru? Non esitare a scriverci o chiamarci!
Responses