Il Visualizzatore Web in FileMaker: cosa è davvero e come usarlo.
Il Visualizzatore Web è uno strumento che molti vedono come croce e delizia. Permette di raggiungere risultati impossibili — o estremamente complessi — da ottenere con l’interfaccia classica FileMaker, ma ci catapulta decisamente fuori dalla nostra comfort zone. Soprattutto se dobbiamo utilizzarlo in ambito Web.
E la confusione aumenta quando dobbiamo gestire una app multipiattaforma, magari Windows, Mac e WebDirect. Finché lavori in FileMaker Pro tutto sembra “quasi” semplice. Poi su Mac i caratteri accentati funzionano e su Win no. Poi pubblichi in WebDirect, e scopri che il WebViewer non è “un oggetto FileMaker con HTML dentro”. È un motore browser incapsulato dentro FileMaker. E qui iniziano le vere regole.
Cos’è davvero data:text/html
Quando scrivi nel Visualizzatore Web:
"data:text/html," & $htmlnon stai passando “un testo HTML”. Stai creando un Data URL, la cui sintassi generica è:
data:[mediatype][;base64], … e che significa: “Quello che segue non è un indirizzo web. È il contenuto stesso.” È un modo per incorporare direttamente dei dati dentro un URL, senza doverli caricare da un file o da un server.
Perché in FileMaker si usa così spesso
Il WebViewer in FileMaker non funziona come un browser normale. Un browser normale può aprire file dal filesystem, caricare URL locali, gestire percorsi relativi e fare richieste a risorse locali con più libertà. Il WebViewer no. Soprattutto in WebDirect: non puoi leggere direttamente dal filesystem del server, non puoi referenziare file locali arbitrari, non hai una “cartella progetto” come in un ambiente web classico, e non puoi fare affidamento su path relativi stabili. Quindi cosa fai? Costruisci l’HTML in una variabile $html e lo passi direttamente al WebViewer tramite data:. È una soluzione elegante perché è autonoma, non dipende da file esterni, non richiede endpoint ed è immediata.
Perché è comoda… ma anche pericolosa
Utilizzando data:etc… stai infilando tutto dentro una stringa: HTML, CSS, JavaScript, JSON ed eventuali dati dinamici. Tutto dentro un’unica data URL. Finché l’HTML è semplice, funziona benissimo. Ma quando cominci ad avere script lunghi, JSON complesso inline, librerie Javascript, caratteri speciali, CSS con url, stringhe dinamiche generate da FileMaker e dati che cambiano frequentemente, stai iniziando a “spingere il motore al massimo”.
Cosa significa “spingere il motore al massimo”
Significa che stai aumentando la dimensione della data URL, stai aumentando la complessità del parsing, stai aumentando la probabilità che caratteri particolari interferiscano e stai usando il WebViewer come runtime applicativo completo. Il WebViewer non è nato per essere un framework frontend completo: è un componente di rendering. Quando lo trasformi nel cuore della tua applicazione (timeline, editor, dashboard, parser, ecc.), lo stai usando come motore applicativo. Funziona. Ma richiede precisione.
Il classico errore: il MIME type sbagliato
Nella sintassi data:etc il pezzo prima della virgola è fondamentale.
Se scrivi data:text/html stai dichiarando un contenuto HTML.
Se scrivi data:txt/html oppure data:text/thml stai dichiarando un tipo non valido.
Il motore non riconosce il contenuto come HTML e in WebDirect può non renderizzare, interpretarlo come download o comportarsi in modo incoerente. Una lettera sbagliata cambia completamente il comportamento. E la cosa diabolica è che spesso FileMaker Pro “perdona”, adattandosi all’errore, il WebDirect mai. Quindi puoi avere un Visualizzatore web che su FileMaker Pro funziona benissimo e su WebDirect si limita a scaricare un file senza mostrare nulla, permettendo anche all’utente di vedere il codice. Oltre il danno la beffa, e solo perché ha scritto data:txt/html invece del corretto data:text/html.
Perché NON serve URL-encodare tutto
Qui bisogna essere chiari: spesso è inutile o controproducente. Se imposti come valore:
"data:text/html," & GetAsURLEncoded($html) trasformi l’HTML in %3Chtml%3E%3Cbody%3E… e WebDirect non sempre lo decodifica prima del rendering. Risultato: vedi caratteri percent-encoded invece dell’HTML renderizzato. Quindi, se il classico “data:text/html,” & $html funziona, va bene lasciarlo così. Scegliendo di utilitari questo metodo è bene utilizzare la forma:
"data:text/html;charset=utf-8," & GetAsURLEncoded($html)e ricordarsi di disabilitare il flag nel visualizzatore web Codifica Automatica URL, che rischia di codificare due volte il testo con effetti imprevedibili.
Quando usare base64
Se l’HTML è molto complesso o vuoi robustezza totale, allora usa:
"data:text/html;base64," & Base64EncodeRFC ( 4648 [o 3548] ; $html )Importante: non usare mai la funzione “classica” Base64Encode perché inserisce una serie di a capo ogni 76 caratteri per avere un base64 con righe di lunghezza uguale, cosa che non viene vista bene in molti ambiti.
Il punto chiave
Il WebViewer non è un “campo testo evoluto”. È un motore browser. Quando usi data:text/html stai dichiarando tipo di contenuto, modalità di interpretazione e formato di trasporto.
- Se sbagli dichiarazione, il motore cambia comportamento.
- Se carichi troppo contenuto, aumenti la complessità del parsing.
- Se infili tutto in una stringa unica, riduci la separazione tra struttura e dati.
Alla fine funziona, ma stai facendo sviluppo web dentro FileMaker, e devi necessariamente scendere a compromessi.
Conclusione
Il data: URL è uno strumento potentissimo nel WebViewer perché ti permette di non dipendere dal filesystem, non dipendere da endpoint, generare HTML completamente dinamico e mantenere l’app autonoma. Ma non è magia: è uno standard web. E quando lavori con standard web dentro FileMaker, i dettagli contano: MIME corretto, sintassi corretta, scelta corretta tra chiaro e base64. Il WebViewer è croce e delizia perché ti permette di superare i limiti di FileMaker. E spesso, anche i tuoi. Fra una imprecazione e un’altra .
Responses