Questa è la traduzione dell'articolo User-Proofing Ajax di Peter Quinsey, pubblicato originariamente su A List Apart il 5 dicembre 2006. La traduzione viene qui presentata con il consenso dell'editore (A List Apart Magazine) e dell'autore.
Abbiamo tutti apprezzato il funzionamento senza problemi di qualche applicazione Ajax ben progettata. Ma ora tornate un attimo indietro con la vostra memoria e ripensate all'ultima volta in cui qualcosa è andato storto usando un'applicazione Ajax: come vi siete sentiti?
Probabilmente vi siete sentiti un po' disorientati. Probabilmente siete rimasti a guardare mentre girava la rotellina che indica l'attesa chiedendovi se fosse o meno il caso di fare refresh della pagina. Vi sarete magari chiesti, controllando l'orologio, se la vostra richiesta fosse stata davvero inviata. Di fatto non sapevate cosa stesse accadendo. E voi siete degli sviluppatori! Pensate a cosa va incontro un utente comune ogni volta che si trova davanti ad un problema.
Quando le buone applicazioni vengono rovinate
Ajax è pratico perché evita comportamenti non necessari del browser come il reload della pagina, ma può essere pure pericoloso perché evita comportamenti utili come la gestione degli errori. Mesaggi di errore tipo "Server non trovato" non ne vedete più. E non parliamo poi dei problemi dovuti all'uso del tasto Back del browser. In pratica, quando Ajax si sovrappone con certe interazioni a queste utili funzionalità del browser, dobbiamo fare in modo di sostituirle quanto meglio è possibile.
Pensare sempre a soluzioni alternative
Una delle regole chiave dello scripting client-side è di venire incontro alle esigenze degli utenti che hanno gli script disabilitati. Lavorando con Ajax ciò è semplice: quando si agisce su un link o su un form per attivare una funzionalità Ajax, assicuratevi che il link o il form puntino anche ad un URL valido e funzionante che porterà a termine nel modo desiderato l'interazione usando il metodo tradizionale:
<form action="traditional_action.php" method="post"
onsubmit="perform_ajax_action(); return false;">
Adottando questo approccio, i browser che supportano gli script eseguiranno le interazioni Ajax, mentre gli altri browser, non riconoscendo né l'evento onsubmit né la direttiva return false, invieranno il form normalmente e ripiegheranno sul tradizionale meccanismo di gestione dei form.
Piccola nota a margine. È sempre una buona pratica inserire il codice per l'attivazione dei form all'interno del Javascript. La gestione degli eventi inline, come nell'esempio, è qui usata solo per finalità dimostrative.
Potremmo anche fare un ulteriore passo avanti pensando anche a quei browser che sono in grado di gestire gli script in generale, ma non l'oggetto XMLHttpRequest. Invece di usare un esplicito return false nel gestore di eventi onsubmit, verificheremo il supporto di Ajax, portando a termine l'interazione Ajax in caso affermativo ed inviado il form nel modo tradizionale in caso negativo. Diciamo di avere una funzione Javascript chiamata createAjaxRequest( ) che crea un oggetto XMLHttpRequest oppure restituisce false in caso di mancato supporto:
var request; // our request object
function perform_ajax_action(){
if ( !request = createAjaxRequest() ){
return true; // abort Ajax attempt, submit form
}
// proceed with your regular Ajax functionality
// ...
return false; // do not submit the form
}
A livello del nostro form, dovremmo riscrivere il nostro gestore di eventi per ripiegare su un tradizionale invio di moduli appena si presenta qualche problema:
<form action="traditional_action.php" method="post"
onsubmit="return perform_ajax_action();">
Se tutto va bene, il codice Ajax verrà eseguito e l'invio del form sarà saltato. Se accade qualcosa di problematico con il browser, il modulo sarà inviato nel modo normale.
Informare gli utenti
Molte funzionalità Ajax si sovrappongono a quelle presenti nell'interfaccia standard del browser. Abbiamo così bisogno di rimpiazzare in qualche modo tali funzionalità, dal momento che gli utenti sono abituati a contare su di esse. Innanzitutto, dobbiamo pensare alla gestione degli errori. Il modo in cui implementare una soluzione per riportare gli errori all'utente dipende dall'applicazione su cui si sta lavorando. Nei miei esempi inserisco il messaggio di errore all'interno di un div nascosto che viene visualizzato quando si verifica un errore.
Ma che tipo di errori dovremmo riportare? Errori di connessione, per iniziare. Se ci sono problemi nella connessione ai file dell'applicazione che agiscono dietro le quinte, il browser non li riporterà nel modo consueto. Se non si ottengono risposte con un normale codice di errore HTTP, possiamo sfruttare i messaggi forniti dall'oggetto XMLHttpRequest. Ecco un esempio:
if ( request.readyState == 4 ){ // 4 is "complete"
if ( request.status == 200 ){
// HTTP OK, carry out your normal Ajax processing
// ...
}else{
// something went wrong, report the error
error( "HTTP "+request.status+". An error was »
encountered: "+ request.statusText );
}
}
Altri tipi di errore da gestire sono quelli a livello di applicazione. Questi errori si verificano quando nel contesto dell'applicazione qualcosa non va come dovrebbe. Sebbene i modi in cui affrontare queste situazioni dipendano dal tipo di applicazione, ci sono alcuni principi di base da tenere sempre a mente.
Lasciare integro il ciclo
Prima di tutto, il ciclo di comunicazione tipico delle interazioni Ajax deve essere preservato. L'esecuzione lato server deve essere sempre portata a termine e deve sempre restituire un documento XML valido. Se così non avviene, si lascia il browser (e l'utente) in fase di stallo, senza che vi sia una traccia per capire cosa sta accadendo. Se il vostro script lato server va in crash, il messaggio di errore andrà perso. Ecco perché è essenziale effettuare continue verifiche sul codice, come avviene in questo snippet di codice PHP in cui un errore viene registrato e l'esecuzione interrotta quando un file non può essere aperto:
if ( !$fp = fopen( $filename, "r" ) ){
$error_msg = "Could not open file " . $filename;
exit();
}else{
// proceed with the rest of the program
// ...
}
È una buona pratica di programmazione buona e valida in generale, ma in questa situazione è vitale per salvaguardare l'usabilità dell'applicazione.
Comunicare l'errore
Una volta che l'esecuzione lato server sia stata completata, bisognerebbe verificare se tutto è andato bene e riportare eventuali errori all'utente. Il documento XML restituito dal server dovrebbe sempre restituire un messaggio di errore, seppure in forma sintetica.
In questo esempio, il documento XML ha un elemento success che contiene il valore "1" se tutto è andato bene, "-1" in caso di errore. Il documento XML porta con sé anche un elemento error che contiene il messaggio da riferire all'utente. Lo script lato server verifica la presenza di errori, restituisce il messaggio e tiene così informato l'utente su quanto sta accadendo. Nel caso dell'esempio la verifica avviene sulla validazione del contenuto inserito.
Il problema degli 'errori silenziosi'
Che dire degli 'errori silenziosi' come i timeout e i pacchetti di dati persi? In genere, quando gli utenti si trovano davanti ad applicazioni web che cessano di funzionare perdono la pazienza. Cominciano a premere sul pulsante Back e a provare e riprovare. Non sarà questa la situazione ideale per la vostra applicazione Ajax: senza reload della pagina, il pulsante Back porterà l'utente molti passi indietro. Se l'applicazione è ben progettata, non si dovrebbero perdere informazioni, ma è comunque un passo extra che all'utente dovrebbe essere risparmiato.
Come? Informandolo. Tenete traccia del tempo passato dal momento in cui è stata fatta la richiesta. Se passa un periodo di tempo che va oltre il ragionevole, informate in qualche modo l'utente che potrebbe esserci stato qualche problema. Spiegate la situazione suggerite una soluzione. È un modo semplice per far sì che l'utente continui a fidarsi della vostra applicazione.
Questo secondo esempio mette in pratica questa idea lasciandovi impostare un ritardo nella risposta lato server. Se una volta effettuata la richiesta passano più di 30 secondi, appare un messaggio che chiede all'utente cosa vuole fare.
È solo l'inizio
Questa non è certamente una guida onnicomprensiva alla gestione degli errori in applicazioni Ajax. Ci sono tanti altri modi per usare Ajax per migliorare l'usabilità della vostra applicazione, e tanti altri problemi e soluzioni vedranno la luce man mano che questa tecnologia maturerà. Qualunque metodo adottiate, ricordate che Ajax è nato per creare una user experience migliore, per cui assicuratevi che anche la gestione degli errori si adatti al contesto. Più gentile sarà tale gestione degli errori, più la vostra applicazione meriterà la fiducia e l'apprezzamento di chi la usa, anche quando qualcosa va storto.
