Sviluppare una soluzione in FileMaker: separare dati e interfaccia, giusto o sbagliato?

Negli articoli precedenti della rubrica “L’uomo che guarda” abbiamo fatto una piccola panoramica delle novità che FileMaker 13 ha apportato su argomenti particolarmente spinosi come la sicurezza, o sulla comodità di sfruttare la nuova funzione di codifica dei file mediante l’algoritmo Base64. Gli articoli di Sandro Bramati su come sviluppare una soluzione in FileMaker mi hanno spinto a rispolverare uno degli argomenti a me più cari: come separare dati e interfaccia.

Modifiche e aggiornamenti: che confusione!

La facilità di uso e l’interfaccia amichevole di FileMaker sono proverbiali, e sono le caratteristiche distintive che ne hanno sancito il successo.

Tuttavia, per mantenere al massimo livello queste caratteristiche, e contestualmente offrire una buona compatibilità fra le versioni (basti pensare anche solo al fatto che un file .fp7 può essere usato in contemporanea da FileMaker 7, 8, 8.5, 9, 10 e 11), nel corso del tempo sono stati necessari una serie di compromessi di progettazione, il più evidente dei quali è la struttura adottata: tutti i componenti di una soluzione (dati, script, elementi grafici e di interfaccia, relazioni, liste valori) sono contenuti in un singolo file.

Questo approccio garantisce sicuramente immediatezza, facilità di uso e rapidità di sviluppo, ma rende problematico l’aggiornamento della nostra soluzione, nel caso non si abbia un accesso continuo all’applicazione.

Come procedere?

Quando dobbiamo effettuare un aggiornamento, per quanto piccolo come una modifica ad uno script oppure un nuovo formato di stampa o di consultazione, interagiamo con un unico file e il nostro intervento coinvolge l’intera soluzione.

Questo approccio non è necessariamente negativo di per se’: se utente e sviluppatore della soluzione coincidono è possibile fare liberamente tutte le modifiche del caso, confermando la proverbiale velocità di sviluppo tipica di FileMaker. Più complesso è invece il caso in cui chi deve effettuare l’aggiornamento non ha accesso al file: per apportare modifiche alla soluzione si deve intervenire in loco oppure, se possibile, un referente interno deve inviare il file allo sviluppatore. Ecco sorgere alcuni problemi: innanzitutto l’invio del file non è sempre pratica realizzabile, per motivi di riservatezza o molto più banalmente di dimensioni; a livello operativo il programma da modificare non potrà essere utilizzato fino alla consegna dell’aggiornamento oppure alla consegna dell’aggiornamento i nuovi dati dovranno essere importati dentro al programma stesso, cosa di per se’ non necessariamente semplice o veloce.

A questo scenario si aggiunge l’utilizzo su dispositivi iOS: nel caso di una soluzione distribuita su vari dispositivi aziendali può essere necessario l’aggiornamento di ogni singola soluzione su ognuno di essi.

Con la sempre crescente diffusione delle banda larga e delle tecnologie di accesso remoto questo problema sta man mano perdendo di importanza; rimane invece molto attuale il caso di uno sviluppatore che voglia distribuire una propria applicazione. Per poter effettuare gli aggiornamenti è necessario impostare una procedura di importazione dati che sia trasparente per l’utente; l’operazione in se’ è solitamente complessa e, nel caso di una gran quantità di dati, spesso irrealizzabile (è sufficiente pensare all’importazione di una tabella con molti campi, molti calcoli e qualche centinaia di migliaia di record, che da sola può occupare molte ore).

L’unica alternativa, improponibile in caso di una diffusione anche media, è intervenire personalmente su ogni copia distribuita per effettuare l’aggiornamento.

Separazione tra dati e interfaccia

Per risolvere questo problema, sono state sperimentate molte soluzioni. Tuttavia, il modo migliore (applicabile a partire dalla versione 7 ) è l’impostazione di un modello di separazione dati/interfaccia per la propria applicazione, ovvero il dividere la propria soluzione in più file: uno contiene l’interfaccia utente, con il quale gli utenti interagiscono, gli altri altri file ospitano i dati oppure i formati di stampa.

L’utilizzo di questa soluzione offre evidenti vantaggi: dal momento che i dati risiedono in uno o più file separati, possiamo senza problemi effettuare modifiche all’interfaccia semplicemente sostituendo il vecchio file di interfaccia con il nuovo, senza toccare minimamente i dati. Naturalmente, nel caso si debba  comunque operare delle modifiche a livello di dati o struttura della soluzione, questi vantaggi non sussistono più. Inoltre questo approccio ha una complessità maggiore a livello di sviluppo e comporta alcune problematiche di aggiornamento di dati riassunti o calcolati. L’utilizzo di questo approccio comporta inoltre una cattiva esperienza utente con le prime versioni di FileMaker Go, che tendevano spesso a portare in primo piano i file di dati.

Interfaccia e dati: facciamo ordine

Dal momento che FileMaker non opera distinzioni strutturali fra dati e interfaccia, per prima cosa è necessario chiarire cosa è da intendersi come dato e cosa viceversa appartenga all’interfaccia: questa operazione deve essere svolta dallo sviluppatore, inizialmente a livello logico, quindi a livello pratico, suddividendo effettivamente la propria applicazione in più file. Ovviamente non si raggiungerà mai una separazione netta, come in altri ambienti che utilizzano la separazione a livello di a livello di architettura (multi-tier applications).

Dovremo quindi mediare le nostre esigenze con le caratteristiche e gli ottimi strumenti che FileMaker ci mette a disposizione.

In linea di massima possiamo affermare che:

• Tabelle e Campi rientrano nei dati (anzi, ne costituiscono l’ossatura)
• Formati, Menù e Pulsanti appartengono all’interfaccia
• Liste valori, Script e Relazioni sono in generale utilizzati come elementi di interfaccia, ma anche come dati.

Ad esempio, una lista valori basata su un campo sarà nel file interfaccia, pur operando sui dati; allo stesso modo una relazione può essere utilizzata nell’interfaccia (ad esempio in combinazione con un portale) o nei dati (quando serva a popolare dei campi con valori di riferimento), o anche in entrambi; analogamente, anche eventuali funzioni personalizzate e sorgenti dati esterne utilizzate dalla soluzione dovranno essere riportate in tutti i file.

Conclusione

Con l’articolo di oggi sono state prese in considerazione le possibili difficoltà pratiche che si incontrano quando si ha la necessità di dover apportare modifiche, seppur minime, a una soluzione a cui non si ha direttamente accesso. Come soluzione abbiamo proposto la separazione tra dati e interfaccia. I prossimi articoli approfondiranno i vari metodi per affrontare questo procedimento in modo pratico. Il tema è controverso (la FileMaker stessa non ha mai fatto mistero di deprecare il modello di separazione), molto articolato e in alcuni aspetti si sovrappone alle problematiche di aggiornamento dati in remoto fra FileMaker Go e un server centrale.  E voi? Che approccio preferite?