Questo esempio è probabilmente il più complesso poichè l'insieme delle operazioni client/server è abbastanza numeroso. I commenti sul codice in questo caso non sono estremamente rilevanti, restano comunque presenti all'interno dei file allegati, invece esaminiamo quello di spiegare tutte le varie analisi fatte prima e durante la realizzazione.
Scegliamo di lavorare usando chiamate di tipo POST. L'elemento di markup più idoneo allo scopo è il form. Quindi creiamo una semplice applicazione per gestire un'anagrafica clienti. I dati necessari a descrivere ogni cliente potrebbero essere veramente tanti, ed un form ha potenzialmente la capacità di inviare una enorme quantità di informazioni. In questo caso ci limitiamo a 3 campi: ragione sociale, indirizzo email e numero di telefono del cliente.
Come per gli altri esempi della guida, la cosa importante è capire come funzionano le interazioni. Poi le possibilità di implementare controlli, ottimizzare il codice, riadattare il tutto, saranno innumerevoli.
Le pagine che compongono l'applicativo sono 3, una dedicata all'inserimento, una all'eliminazione dei clienti e l'ultima che mostra la lista dei clienti, comprensiva di informazioni aggiuntive.
Abbiamo scelto di non usare un database per non distrarci dal contesto delle richieste asincrone, invece usiamo un file di testo, senza perderci nei dettagli di connessione, gestione, sicurezza o altro ancora ... Quindi si legge il file, si scrive il file. Fine delle operazioni.
Nel file di testo ogni cliente è rappresentato da una riga ed i campi sono separati da un carattere barra verticale, '|'. Le righe (i record) vengono separati con i classici caratteri di ritorno a capo "rn". Sono regole rudimentali, comunque sufficienti per gestire l'archivio proposto.
Questo applicativo dovrebbe poter stare all'interno di un'area di amministrazione e sarà quindi mostrato all'interno di una pagina più complessa. Aggiungendo l'amministrazione, quindi, le pagine utili all'esempio diventano quindi 4. Per confrontare i 2 linguaggi adottati, PHP e C#, si è scelto di utilizzare una sorta di sistema template, molto casalingo ma adatto alla situazione.
La pagina generica di amministrazione avrà quindi un aspetto di questo tipo, con link in grado di reindirizzare l'utente in ogni sotto sezione.
Questo menu è stato preso dal sito A List Apart dove è ben documentato in ogni parte. Le sezioni, mostrano ciascuna il markup utile per le operazioni. Ad esempio, la pagina di inserimento dati sarà popolata solo da un form ed avrà un aspetto di questo tipo:
Esplorando il codice verifichiamo che esiste un template per il menu e che ogni funzione ha un proprio template (HTML) che viene chiamato all'occorrenza. La separazione di markup per ogni pagina ha una logica ben precisa. I link del menu gestiti in AJAX devono essere degradabili, ma per leggere solo il necessario in modo asincrono sarebbe inutile caricare tutta l'area e scorporare solo la parte interessata, inoltre sarebbe inutile rielaborare l'intera pagina del menu amministrazione per il cambio di una singola parte.
Un approccio di questo tipo suggerisce l'utilizzo di chiamate in GET per la scelta della sezione ed in POST per l'invio dei dati di ogni sezione.
Potremmo creare un oggetto diverso per ogni richiesta, ma sarebbe complesso evitare l'effetto delle richieste multiple. Tutto il sistema è quindi pilotato da un solo oggetto asincrono, in questo modo nessuna operazione è sovrapponibile. Questo grazie al controllo del parametro readyState: se l'oggetto ha questo parametro uguale a zero, è possibile eseguire la richiesta, altrimenti si dovrà attendere che sia finita quella precedente. Quindi mentre si inserisce un cliente non è possibile cambiare sezione e mentre si sceglie una sezione non è possibile effettuare altre operazioni.
Dopo aver definito dove gestire i dati, il file di testo, come operare su tali dati, sezioni dedicate, non resta che scrivere codice server e codice client.
Quando si ha a che fare con un database bisogna comunque fare gli opportuni controlli sul server, quelli effettuati dal JavaScript potrebbero infatti essere scavalcati. Il server dovrà quindi comportarsi da filtro per le operazioni ed in questo caso capire se la richiesta è stata effettuata o meno da AJAX.
Controllo tipico di ogni sezione sarà il seguente:
- chi ha effettuato la chiamata, AJAX o il form?
- devo elaborare i dati o devo solo mostrare l'output?
All'interno di queste differenti situazioni si devono poter effettuare le operazioni sui dati quali:
- aggiunta di un cliente, possibilmente cercando di non creare duplicati
- eliminazione di un cliente, verificando che la ragione sociale sia già presente in database
- mostrare la lista di tutti i clienti, in modo utile per effettuare i controlli via codice e con l'ausilio di una funzione dedicata per mostrare tale lista all'utente.
Dovendo svolgere operazioni di verifica per ogni pagina, la soluzione più idonea è quella di una classe esterna usata da tutte le sezioni. Da questa esigenza nasce il file ManagerClienti.class, con estensione php o aspx, e metodi analoghi a prescindere dal linguaggio scelto.
Le ultime doverose considerazioni servono a chiarire punti fondamentali di questo esempio. In primo luogo, la soluzione proposta non è da considerarsi un modello assoluto di scrittura applicativi AJAX, poichè è stato necessario trovare un sistema familiare agli sviluppatori PHP, analogo e per questo non eccellente per quelli C# ma soprattutto in grado di sfruttare la stessa struttura di base con entrambe le tecnologie, come i files html in grado di generare le pagine, il css ed il codice client presente all'interno del file gestoreclienti.js, dove molto è vincolato dalla variabile server e dalla natura multi piattaforma dell'applicativo stesso.
In aggiunta non sono stati fatti controlli rigorosi sui dati quindi non c'è da sorprendersi se scrivendo in un campo un carattere uguale a '|' il database non funzioni più correttamente.
Per concludere il sistema non è da considerarsi accessibile al 100%, visto che alcuni contrasti non sono a norma e che, come detto in precedenza, i controlli sull'evento onkeypress dovrebbero essere strutturati in modo tale da accettare solo determinati tasti e non uno qualunque ma anche questo esula dal fine dell'esempio e della guida.