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?

9 Commenti

  1. fra la 7 e la 11 non è cambiato molto. con la 12, oltre al cambio del formato ci sono state parecchie modifiche sotto il cofano riguardanti l'effettiva operatività di alcune funzioni fondamentali (Evaluate() su tutte ) e grandi miglioramenti nel refresh dei dati. Anche FileMaker Go funziona molto meglio.

    • Mi sembra che tu non abbia risposto, alla luce del passaggio all’architettura del 12/13 consiglieresti ancora la separazione dei dati?
      A me non piace per nulla.

      Un abbraccio Germano

      • Buongiorno, Germano.

        A mio avviso il cambio di formato migliora le prestazioni in caso di separazione, che peraltro erano uno dei punti dolenti del metodo di separazione, soprattutto relativamente al refresh dei dati.
        Tuttavia, questo non influisce minimente sulle considerazioni strategiche relative al deployment del prodotto, che sono le uniche che possono fornire una risposta sulla giustezza o meno dell'utilizzo del modello, che ha grandi vantaggi e altrettanti limiti. 🙂
        Il "se farlo o meno" dipende quindi dalla diffusione e dalla quantità di dati presenti nell'applicativo, oltre che dal livello di personalizzazione accessibile all'utente finale. A mio parere quindi, la risposta è influenzata più che dal tipo di formato, dalla disponibilità della banda larga, degli strumenti di accesso remoto e dall'utilizzo con di tablet e smartphone.

        Non dico che il modello di separazione dati sia l'optimum, anzi è un rimedio alla mancanza di una caratteristica necessaria, ma perché ne sei così contrario?

        .g.

  2. Premetto che sviluppo una sola applicazione freeware da anni (Dento con Sandro Bramati) e ritaglio la mia considerazione su questa sola esperienza.
    Col passare del tempo il rischio di appesantimento di funzioni, relazioni, formati è già alto senza la separazione dei dati che aggiungerebbe una complicazione in più.
    Un accurato sistema di esportazione/importazione dati mi sembra risolva bene il problema aggiornamento delle versioni all’utente finale che mi pare uno dei vantaggi della separazione dati interfaccia.
    In alcune prove fatte su un piccolo applicativo in separazione non sono mai riuscito ad avere solo dati puri da una parte.

    • Ho presente Dento e ne ho sentito parlare molto bene - fra l'altro Sandro Bramati è il nostro PointBreak man - e il tuo non è un punto di vista sbagliato 🙂
      buona parte delle problematiche che sollevi verranno analizzate nei prossimi articoli sulla separazione, e non vorrei anticipare troppo. Tuttavia ci sono casi in cui l'importazione semplicemente non è possibile (con molti dati e indici ci puoi mettere anche più di una giornata a tabella) e altri in cui puoi decidere di lasciare impostare alcune cose al cliente (ad esempio le stampe) e in quel caso è molto comodo un modello di separazione. 🙂
      Anche il poter semplicemente dare istruzioni di aggiornamento sul tipo "chiudete FileMaker e fate doppio clic qui" ha un suo perché. Io personalmente non ho mai amato le procedure di importazione scriptate (probabilmente una eredità delle vecchie versioni di FM, in cui spesso uscivano fuori duplicazioni con le chiavi primarie.

  3. Questo argomento è sempre stato foriero di discussioni. C'è chi predilige la separazione (addirittura ci sono una serie di articoli, risorse, podcast e quant'altro in Rete da parte di superGuru cintura nera 9° dan) e altri che non la sopportano.
    Secondo me, come in tutte le cose, ci sono i pro e i contro sia per la soluzione non-separata sia per quella in separazione
    SOLUZIONE NON-SEPARATA (mono file o cmq dove dati e interfaccia risiedono nello stesso file)
    PRO: fai prima. Se devi modificare un campo vai direttamente nella definizione database e agisci, lavori meno per creare l'impianto relazionale della soluzione.
    CONTRO: a ogni minima modifica che devi apportare, o importi i dati dalla vecchia alla nuova release (e quando si tratta di soluzioni un po' ciccione fa caldo..) oppure "replichi" (dalla tua soluzione di sviluppo a quello in produzione) tutte le modifiche che devi fare. Se sono poche fai presto, se devi sviluppare nuovi moduli o anche solo report un po' più articolati, impieghi un bel po' di tempo. Puoi anche lavorare direttamente in linea ma... devi farlo in orari in cui gli utenti non martellano dentro dati (per evitare rallentamenti o casini potenziali) il che ti costringe a lavorare con orari da metronotte. Inoltre non puoi fare test quando le modifiche sono più consistenti: cosa succede se uno script non funziona e altera il contenuto del database?? E se poi la connessione non va? Sei fermo con il lavoro...

    SOLUZIONE IN SEPARAZIONE
    PRO: l'esatto contrario della precedente. Puoi lavorare quando vuoi nella soluzione di sviluppo e poi, quando si tratta di replicare il tutto nella soluzione in produzione, replichi la struttura dati (anche in linea) con campi e relazioni, quindi per TUTTO ciò che riguarda interfaccia e script, sostituisci un file. Fine.
    CONTRO: devi smazzarti di più. Bisogna conoscere meglio l'argomento, bisogna impostare sostanzialmente 2 schemi relazionali (uno pre le relazioni strutturali, quelle dei dati, che servono per i calcoli e l'altro per le relazioni funzionali, dell'interfaccia, che serviranno per far funzionare le procedure), quando devi lavorare sulla base dati devi spostarti nel file "dati", lavorare, fare le tue belle relazioni strutturali e poi passare nell'interfaccia e, eventualmente, replicare alcune relazioni anche li (ma non è detto al 100%...)

    Nella mia esperienza posso dire che non esiste una regola valida in assoluto. Dipende dalla situazione contingente e da come siamo abituati. Oltre che dalla nostra logica operativa. In effetti ognuno di noi è diverso
    In generale se tu hai una soluzione di cui TU sei il diretto responsabile e ci metti le mani direttamente, forse la soluzione non-separata è più vantaggiosa. In tutti gli altri casi, e a meno che non si tratti di rovini semplici, io propendo per la separazione.

    Ipse dixit 🙂

  4. Ciao, io ho optato al seguente modello.

    Tre file:

    Gestionale vero e proprio con dentro tutto il db e il codice, layout ecc. ecc.;
    Container con dentro solo una tabella che archivia tutti i campi container;
    Personalizzazioni con dentro le personalizzazioni del cliente , report, layout ecc. ecc.

    PRO:
    Facile gestione dello sviluppo dell'applicazione;

    Migliore gestione del versioning tra codice e db che di solito viaggiano di pari passo;

    Separazione in volume dei dati, il file Container diventa presto molto grande ma non necessita mai di modifiche strutturali e quindi non deve essere aggiornato. Il file Personalizzazioni scorpora tutto ciò che è stato sviluppato appositamente per il cliente (Report, script, ecc. ecc.) e non viene modificato dagli aggiornamenti.

    Il ridotto numero di file ottimizza la distribuzione in cloud su hosting filemaker (Di solito c'è un limite nel numero di file).
    Ci sono hosting a 19$ al mese per 3 file fino 2 GB.

    CONTRO:
    Gestione in modo trasparente al cliente del travaso dei dati dalla versione vecchia alla nuova.
    Io ho risolto con una serie di script di esportazione e importazione globale.
    Distribuisco la nuova versione gestionale vuota e all'avvio lancio lo script di importazione dalla versione vecchia.

    Cartone

LASCIA UN COMMENTO

Please enter your comment!
Please enter your name here