FileMaker è semplice e flessibile. Così semplice e così flessibile che spesso ci incoraggia a non tenere presenti degli accorgimenti che in altri ambienti di sviluppo sono quasi obbligati, come ad esempio la nomenclatura di campi e tabelle.

De Astratione, o la nomenclatura dei campi

Ovvero, come lo sviluppatore  pigro riesce a risparmiare tempo (dedicato a lpm)

FileMaker infatti accetta quasi qualsiasi maltrattamento a livello di nomi, e non è raro trovare campi con nomi del tipo “% che uso in caso di @ ma senza #”. In questo siamo spesso incoraggiati dal fatto che buona parte dei lavori di sviluppo parte da (o "deve venire a patti con") una serie di dati e strutture pregresse. Viene quindi spontaneo riprendere i nomi dei campi e delle tabelle dalla struttura originale, anche solo per semplicità di importazione dati.

In molti casi l’utente (o anche lo sviluppatore interno, o di non lunghissimo corso) non riesce ad astrarsi a sufficienza dai dati per concentrarsi sulla struttura del DB.  Anzi, spesso finisce per confondere i due piani, incoraggiato in questo dall’interfaccia utente di FileMaker, la quale tende a mischiare le due cose con ammirevole pertinacia.

Questione di metodo

A questo punto sorge spontanea una domanda: “ma se il mio metodo funziona, perchè cambiarlo?”.

Le risposte sono diverse.

La prima è che magari alcune funzioni future non funzioneranno poi benissimo: provate ad usare una funzione di EseguiSQL() con il campo che abbiamo menzionato prima e ve ne accorgerete subito.

La seconda è che se qualcun altro (o anche lo stesso sviluppatore a distanza di parecchio tempo) dovesse metterci le mani successivamente,  può già prenotare in anticipo un soggiorno in una clinica disintossicante.

La terza è che, in ultima analisi… si perde tempo.

La quarta (ma è puramente soggettiva) è che trovare metodi intellettualmente stimolanti è molto più divertente e permette di imparare molto di più.

Sviluppare con FileMaker: gli errori più comuni

Ecco la triade degli errori classici (e che fanno perdere un sacco di tempo):

  1. nomenclatura pigra delle occorrenze di tabella. Scenario tipo: riprendo il lavoro dopo due settimane, e... quale diavolo era il contesto della tabella magazzino 4? O aspetta, era magazzino 3?
  2. Denominare le chiavi primarie delle tabelle (perche voi usate le chiavi primarie, vero?) in maniera diversa. Se ad esempio usiamo sempre id_riga o kp, automaticamente negli script e nei calcoli possiamo usare senza paura nometabella::id_riga, senza starci a chiedere ogni volta se è il caso di chiamare ID_pratica, ID_commessa o che altro.
  3. Usare nomi diversi per gli stessi campi. Nello specifico: se ho un luogo di consegna, non ha senso avere un pratiche::luogo di consegna, preventivi::cliente_luogo_consegna, ddt::luogo consegna, etc.

Poi ci sono le derivazioni ossessivo-compulsive (per fortuna rare), quali ad esempio quella di numerare i campi per tabella uno per uno (tipo 1_ID, 2_ragione sociale, etc.). O ancora, fare relazioni basate sulla descrizione/nomecognome quando invece servirebbe una chiave primaria. Tutte cose che fanno sì che gli sviluppatori chiamati a mettere le mani sulla soluzione corrano subito alla ricerca di pece, piume, e di una fiaccola con cui accendere il rogo sotto i piedi del creatore di tale abominio.

Facciamo un esempio molto pratico. Poniamo di dover aggiungere i luoghi di consegna alla nostra soluzione, in quattro diverse tabelle: pratiche, preventivi, ddt e fatture. Abbiamo per ciascuna tabella una bellissima relazione che mostra solo i luoghi i consegna relativi al cliente in oggetto, e un bellissimo popover come interfaccia.

A questo punto dobbiamo effettuare lo scripting.

Ci sono vari livelli di sofisticazione:

  • Primitivo: per ciascun popover inseriamo semplicemente un Imposta campo (senza nemmeno lo script). Semplice, ma lungo. Senza contare che per modificare qualcosa in uno va rifatto da capo in tutti, che poi il popover va chiuso a mano, e così via.
  • Base: come sopra, ma con quattro script diversi. Nulla da dire, ma per modificare qualcosa devo sempre operare quattro volte.
  • Medio: uno script con quattro if, a seconda della tabella. Meglio del Base, ma non il massimo della vita.
  • Sviluppatore Pigro: un unico script, tre istruzioni in tutto:
  1. Imposta Campo per Nome
  2. Chiudi Popover
  3. Aggiorna Finestra

Nell’istruzione di Imposta Campo per Nome dobbiamo inserire mediante il motore di calcolo sia il campo che il valore. Se non abbiamo impostato bene la nostra soluzione, per il nome del campo ci può toccare un calcolo del genere:

Casi(

Get(NomeTabellaFormato)="pratiche";"pratiche::luogo di consegna" ;

Get(NomeTabellaFormato)="preventivi";"preventivi::cliente_luogo_consegna" ;

Get(NomeTabellaFormato)="fatture";"fatture::luogo di consegna" ;

Get(NomeTabellaFormato)="ddt";"ddt::luogo consegna" ;

"")

Se invece abbiamo fatto tutto comme il faut, è sufficiente un

Get(NomeTabellaFormato) & "::luogo_consegna”

Un discorso analogo esiste per la nomenclatura delle TO.

Possiamo dover combattere con:

Casi(

Get(NomeTabellaFormato)="pratiche";"clienti_fornitori_indirizzi_cliente_pratiche::" ;

Get(NomeTabellaFormato)="preventivi";"clienti_fornitori_indirizzi_cliente_preventivi::" ;

Get(NomeTabellaFormato)="fatture";"clienti_fornitori_indirizzi_cliente_fatture::" ;

Get(NomeTabellaFormato)="ddt";"clienti_fornitori_indirizzi_cliente_ddt::" ;

“”)

o con un semplicissimo:

"clienti_fornitori_indirizzi_cliente_" & Get(NomeTabellaFormato) & "::"

da aggiungere al calcolo vero e proprio.

Quindi per uno script che opera in quattro tabelle differenti, se abbiamo impostato bene la nostra soluzione può bastare una singola istruzione,  con ovvio risparmio di spazio, tempo e neuroni:

Imposta campo per nome [Get(NomeTabellaFormato) & "::luogo di consegna");

Dichiara( suff=; "clienti_fornitori_indirizzi_cliente_" & Get(NomeTabellaFormato) & "::");

Valutazione(suff&"indirizzo") & ¶ & Valutazione(suff&"cap") & " - " & Valutazione(suff&"città") & If( not EVuoto(Valutazione (suff&"provincia") ); "( " & Valutazione(suff&"provincia") & " )" ; "" ) & ¶ & Valutazione(suff&"nazione")
)]

A livello di calcolo, la funzione Valutazione() è uno dei migliori amici dello Sviluppatore Pigro. In sostanza la funzione valuta la formula inserita fra parentesi, quindi un calcolo Valutazione(“nometabella::nomecampo”) riporterà il contenuto del campo stesso, ovviamente se corretto o presente.

Le possibilità sono talmente tante (anche nell’ambito della separazione dati /interfaccia) che saranno presto oggetto di un articolo dedicato.

Hai trovato una soluzione pigra ma geniale e vuoi condividerla coi nostri Guru? Scopri la Comuunity FileMaker Guru su Guru Corner!

LASCIA UN COMMENTO

Please enter your comment!
Please enter your name here