È esplosa la moda, è sempre più usata, l'interazione asincrona è ormai parte integrante del Web 2.0, ma la strada scelta dagli svilupatori non è sempre vincente: i problemi sono sempre dietro l'angolo.
Premessa
Scrivendo la Guida Ajax non ho fornito sufficienti dettagli per evitare alcune delle problematiche trattate nel seguito dell'articolo. Gli argomenti però sono vari ed andrebbero tutti analizzati a fondo. Ecco, lo scopo di questo articolo è quello di dare semplici consigli sul quando, il come ed il perché sia corretto utilizzare Ajax.
Il primo errore, il più grave di tutti
Il ruolo dello sviluppatore JavaScript è ben definito come quello del web designer o del programmatore server-side. Purtroppo molto spesso in Italia questo non è vero e addirittura qualcuno pensa che non esista una figura di questo tipo. Nella maggior parte dei casi probabilmente è così ma il fatto di non considerare tale figura professionale non può mettere in dubbio la sua reale esistenza.
È una figura che dovrebbe avere il compito di tenersi aggiornato sulle librerie, sul codice cross-browser, sulla semantica, la sintassi e le problematiche del solo JavaScript, conoscendo anche poco di markup e stili e volendo ancora meno di programmazione server-side e/o database.
Molto spesso questa figura viene sostituita dal webmaster "tuttofare" di turno o dal solo web designer, il quale si ritrova a dover sapere un po' di tutto senza avere conoscenze sufficientemente adatte per coprire bene le tre figure distinte prese in considerazione, sfruttando magari le sole funzioni base del WYSIWYG preferito.
Non si tratta, non in questa sede, di accusare qualcuno, bensì di capire bene che se si vuole implementare Ajax e non si ha una persona di riferimento o sufficiente conoscenza delle problematiche server-side non si dovrebbe implementare Ajax.
Questo è infatti l'errore più grave in assoluto, avere conoscenze troppo superficiali delle problematiche server-side ma volere ugualmente usare Ajax nei propri progetti.
Considerando che ogni richiesta asincrona è una chiamata al server e considerando che senza un linguaggio server, un database o un XML dedicato Ajax sia praticamente inutile, è facilmente deducibile che conoscere JavaScript è quasi superfluo se non si conosce bene l'insieme di tecnologie utili a rendere Ajax efficace e soprattutto sicuro.
Ecco quindi il consiglio sul punto in esame: non implementare Ajax se non si conosce bene un linguaggio server. O meglio: approfondire prima tutte le problematiche legate alla gestione dati server-side per poi, eventualmente, scegliere di implementare Ajax.
Coloro che non hanno possibilità di approfondire dovrebbero evitare di usare il proprio codice ed imparare almeno ad utilizzare
qualche libreria server in grado di implementare o gestire in modo ottimale le interazioni asincrone. Proprio così: è sicuramente meglio conoscere una libreria nota ed affidabile che imparare bene il solo JavaScript ed i progetti come GWT ne sono un esempio lampante.
Secondo errore, l'abuso di Ajax
Molto spesso capita di imbattersi in soluzioni come pagine intere caricate tramite Ajax.
Oltre a ricordare che Ajax, per motivi di sicurezza, non può leggere, se non aiutato da un linguaggio server-side, pagine non appartenenti al proprio dominio, va tenuto bene a mente che Ajax non è affatto la soluzione ideale per caricare pagine complete, tanto più se comprensive di doctype o altro che potrebbero addirittura corrompere il layout se inserite brutalmente nel suo contesto. Una ridefinizione di una classe di uno stile, un'inclusione esterna di uno script, un layout complessivamente errato, più doctype, meta tag o altro, oltre ad essere pericolosi saranno sicuramente superflui, dato che da tanti anni viene sfruttato un iframe proprio per permettere inclusioni di questo tipo.
Un riquadro dedicato, un calendario con eventi, un motore con suggest, una ricerca mirata, una galleria, un login, un pannello, una utility o un modulo ... queste ed altre le componenti che vanno a nozze con soluzioni asincrone.
Caricamento dell'intero sito in modo asincrono, di una intera sezione, di pagine esterne sono invece situazioni dove usare Ajax può essere considerato solo un errore e non una feature.
Per rendere semplice e netta la distinzione basta considerare, nella maggior parte dei casi, che se il peso complessivo della pagina richiamata in modo asincrono supera, raggiunge o arriva a tre quarti di quello della pagina visualizzata in quel momento, l'interazione è superflua, inutile... in poche parole errata!
Stesso discorso se in una sola pagina ci sono più interazioni asincrone correlate tra loro, basta fare la somma e fare i giusti calcoli.
Una home page con solo markup, popolata di sezioni asincrone all'evento load, è una delle cose più sconsigliabili che ci siano per i seguenti motivi:
- i motori di ricerca non saranno in grado di indicizzare i contenuti della pagina principale del sito;
- il server si ritroverà moltiplicate le richieste per ogni utente;
- se il server si appoggia al database, questo si ritroverà a doversi connettere e sconnettere molte più volte del necessario;
- se il sito è gestito da un linguaggio server, questo basterà a mostrare con una sola chiamata tutte le N interazioni fatte per caricare contenuti parziali.
Questi concetti andrebbero presi in considerazione soprattutto per quanto riguarda il front end di un sito o di un applicativo, ovvero la parte rivolta al web, all'utenza e non la parte di amministrazione, dove in molti casi si potrebbe trarre perfino vantaggio dall'uso di richieste asincrone consistenti.
Il consiglio su questo punto è quindi il seguente: valutare quando una richiesta sia veramente utile o necessaria ai fini dell'usabilità o del servizio proposto. Evitare di aggiungere Ajax ovunque anche dove fino al giorno prima il linguaggio server poteva essere più che sufficiente. Analizzare quindi molto bene quando conviene richiamare una mole consistente di dati piuttosto che caricare semplicemente una nuova pagina.
Terzo errore, invio e ricezione di caratteri
Il numero di script, librerie, interazioni basate sull'utilizzo della funzione escapeè sicuramente eccessivo, soprattutto perchè questa funzione non è assolutamente la più indicata per non avere problemi con caratteri di ogni tipo.
La prima considerazione da fare è sul linguaggio stesso, il JavaScript, il quale è basato su unicode.
Unicode è uno standard che ha lo scopo di assegnare un codice univoco per ogni carattere, con la caratteristica di preservare i caratteri ASCII standard,
probabilmente i più usati nei sistemi o applicativi occidentali (per approfondire il discorso unicode e charset, si consiglia la lettura di questo tutorial curato dal W3C).
Tutto questo è strettamente correlato con escape, poiché questa funzione non è in grado di codificare in modo standard o comprensibile tutti i caratteri definiti da unicode. Una delle codifiche più usate, nonché adatta, per inviare, ricevere o leggere caratteri è quella UTF-8. Per essere quindi certi che non ci saranno problemi di comunicazione tra le stringhe JavaScript ed il linguaggio server-side è sempre consigliabile sfruttare questa codifica.
L'unica funzione in grado di fare bene questa conversione da carattere a codifica UTF-8 è la funzione encodeURIComponent.
Ajax si basa sullo scambio di coppie chiavi/valori ed un valore di tipo stringa potrebbe contenere tantissimi caratteri di vario tipo, compresa la e commerciale "&", il segno + e tanto altro ancora. Con encodeURIComponent ci si assicura che tali coppie vengano non solo preservate per l'integrità del dato, ma anche rese compatibili con tutti i linguaggi server-side attuali in grado di supportare o manipolare UTF-8.
La funzione escape invece non converte i caratteri in modo standard e codifica quelli esterni al range 0-255 in modo totalmente inutile per qualunque linguaggio, a meno che questo non preveda la ricezione di tali caratteri e non sia in grado quindi di riconvertire nuovamente gli stessi in un formato più utile. Un esempio è dato dal carattere unicode 256, rappresentato da escape come stringa %u100, fino all'ultimo supportato da escape, il carattere %uFFFF.
Sfruttando invece encodeURIComponent il server riceverà la giusta stringa in formato multibytes e non dovrà fare altro che, eventualmente, convertire tale formato in quello scelto per l'elaborazione dei dati. Nel caso di PHP, ad esempio, sarà sufficiente utilizzare la funzione utf8_decode prima di lavorare sui dati in ingresso, per poi eventualmente utilizzare utf8_encode prima di restituirli nuovamente al client.
Per vedere quali siano effettivamente le differenze tra l'uso di escape e di encodeURIComponentè possibile dare uno sguardo a questa tabella.
Per concludere l'argomento, ecco il consiglio: utilizzare sempre encodeURIComponent per inviare dati tramite Ajax al fine di universalizzare il dato in uscita e di semplificarne la ricezione da parte del linguaggio server. Qualora l'applicazione preveda browser datati che non supportano tale funzione (esempio Internet Explorer <= 5), non utilizzare escape nemmeno come alternativa ma sfruttare una delle funzioni disponibili in rete per la retrocompatibilità.
Conclusioni
Purtroppo ci sono tanti altri errori o problematiche inerenti lo scambio dati asincrono e questi analizzati sono forse i più comuni e quindi importanti. Discussioni sulla sicurezza, sull'uso di buone pratiche, sugli approcci e quant altro sono all'ordine del giorno nei siti internazionali dedicati all'interazione asincrona, il consiglio finale è quindi quello di approfondire sempre la questione a seconda delle esigenze di sviluppo del progetto.
