Tutorial Ajax - Capitolo 2

Come abbiamo visto nel capitolo precedente, il cuore della tecnologia Ajax e’ il componente XMLHttpRequest, per il quale abbiamo visto un paio di tecniche di caricamento in memoria.
Abbiamo anche mostrato quali metodi ed attributi vengono forniti con esso, e introdotto il concetto di transazione asincrona tra browser e web server utilizzando il protocollo http.

A quest punto lasciatemi fare un una piccola analogia.

Abbiamo ora a disposizione una bella ruota, non resta che costruirci attorno un’ automobile. Dapprima vedremo come costruire una utilitaria, ovvero come circondare il componente asincrono con un motore semplificato che possa gestire le operazioni basilari che vogliamo implementare sulla nostra web application (l’Ajax Engine). Successivamente raffineremo l’Ajax Engine e lo completeremo con un modulo di interfacciamento con l’Application Server ed aggiungeremo altre librerie di supporto alla GUI per arrivare ad avere una bella macchina sportiva, attraente come aspetto e valida dal punto di vista prestazionale.


AjaxCore – L’Ajax Engine di base.

Una volta scritta la funzione loadXHR() , bisogna definire il set di funzioni che si occupano del vero e proprio caricamento asincrono dei dati utilizzando il metodo GET oppure POST messi a disposizione, a seconda che si richiedano dei dati al server oppure si voglia anche trasferire un set di parametri preliminari contestalmente alla richiesta. Di solito si omette di utilizzare il metodo PUT.

Quindi il nostro Ajax Engine potra’ contenere le due funzioni seguenti:





Queste due funzioni si occupano della richiesta di una pagina page - statica o dinamica - al web server, definendo un contenitore di destinazione dest dove poi dovremo smistare il risultato ottenuto eventualmente dall’esecuzione di questa pagina sul server , accompagnando la richiesta con un set di parametri pars per costruire la querystring completa da inviare nel caso di utilizzo del metodo POST.

Vediamo un po’ piu’ nel dettaglio il comportamento delle due funzioni.


loadHTMLDoc: dopo aver caricato, se occorre, l’oggetto HDR si crea l’”event handler” collegato all’evento onreadystatechange . Un event handler non e’ altro che l’operazione che deve essere eseguita ogni qualvolta il browser attiva questo evento (event fired) segnalando la variazione di stato dell’oggetto HDR.

Se quindi lo stato dell’oggetto HDR e’ cambiato si controlla quale e’ lo stato attuale, e nel piu’ semplice dei casi si prosegue solo quando (x.readyState == 4 && x.status == 200) , ovvero quando lo stato indica che si e’ ricevuta una risposta dal webserver, e tale risposta ha codice 200 – OK.

In questo caso si associa l’eventuale risposta (responseText o responseXML) all’elemento del Document Object Model passato come contenitore di destinazione per i dati richiesti.


ResponseText, responseXML e DOM

Una volta ricevuti i dati richiesti in modo asincrono al web server, come si “inglobano” nella pagina HTML correntemente visualizzata sul browser? In che formato devono essere trasmessi i dati dal web server?

Per rispondere a queste domande, e soprattutto per capire le scelte fatte nel nostro framework Ajax, occorre considerare il seguente aspetto: come si visualizza una pagina web sul browser?

Generalmente il browser legge il codice sorgente HTML della nostra pagina web inviatogli dal web server. Ne effettua il parsing e interpreta i tag html per formattare il documento e visualizzarlo all’interno della finestra del browser. Durante l’operazione di parsing viene costruita in memoria una struttura ad albero di quella che e’ la struttura interna al documento – il Document Object Model o DOM.

Il DOM non e’ altro quindi che la rappresentazione nella memoria della macchina client della struttura del documento visualizzato dal nostro browser.


Document Object Model (DOM) è una forma di rappresentazione dei documenti strutturati come modello orientato agli oggetti. DOM è lo standard ufficiale del W3C per la rappresentazione di documenti strutturati in maniera da essere neutrali sia per la lingua che per la piattaforma. DOM è inoltre la base per una vasta gamma delle interfacce di programmazione delle applicazioni; alcune di esse sono standardizzate dal W3C.
DOM è stato inizialmente supportato dai browser per modificare gli elementi in un documento HTML. DOM è stato un modo per accedere e aggiornare dinamicamente il contenuto, struttura e stile dei documenti. A causa delle incompatibilità nell'esecuzione di DOM fra i vari browser, il W3C ha fornito delle specifiche standard.DOM non mette limitazioni sulla struttura dei dati del documento. Con DOM, un documento ben formato può essere visto come un albero. La maggior parte dei parser XML (come Xerces) e i processori XSL (per esempio Xalan) sono stati sviluppati per usare la struttura ad albero. Questa implementazione richiede che l'intero contenuto di un documento venga analizzato e salvato in memoria. Quindi, DOM può essere usato molto bene per applicazioni dove gli elementi del documento devono essere trovati in modo random e modificati. Per le applicazioni basate su XML che usano un processo di lettura e scrittura per analisi, DOM presenta un grande spreco di memoria; per questo tipo di applicazioni si consiglia di usare il modello SAX.



Questo Document Object Model e’ accessibile al programmatore come struttura XML. A grandi linee l’albero del Document Object Model e’ composto da elementi chiamati Nodi.

· I Nodi identificano i vari elementi, o contenitori, della pagina html .
· I dati veri e propri della pagina, ovvero il contenuto degli elementi html sono rappresentati come attributi dei vari nodi.

Per modificare dinamicamente il contenuto di una pagina web occorre sostanzialmente identificare all’interno dell’albero del DOM il nodo o i nodi che contengono i dati che si vogliono modificare e “appiccicare” il nuovo contenuto al nodo preso come riferimento (parent node), togliendo eventualmente anche i sottonodi (child nodes) con i dati precedenti.

Ad esempio se vogliamo modificare il contenuto di una cella che costituisce una tabella html, occorre modificare il testo racchiuso nei tag … .
Bisogna cioe’ recuperare un riferimento o “reference” della cella/nodo in questione, e cambiare il contenuto interno, sovrascrivendo quello precedente.

Il modo piu’ semplice per sostituire il contenuto della cella in modo dinamico e’ quello di definire il nuovo contenuto valorizzando l’attributo innerHTML del nodo interessato.

Non appena il comando viene interpretato dal browser si ha il refresh automatico di quanto si sta visualizzando sullo schermo, e viene mostrato il nuovo contenuto della cella modificata all’interno della tabella visualizzata nella nostra pagina html caricata, senza doverla ricaricare da zero.

Nel caso di modifiche piu’ complesse si puo’ definire direttamente la struttura del codice html che deve diventare il nuovo valore dell’attributo innerHTML del nodo di riferimento, oppure si puo’ costruire direttamente la struttura XML dei nuovi nodi che devono far parte del DOM modificato.

La prima strada presuppone che il nuovo dato ci venga fornito nativamente come codice html preformattato, mentre la seconda strada lascia una liberta’ maggiore sul formato che devono avere i nuovi dati nel caso vengano forniti da terze parti, magari recuperandoli in remoto da un database server.

Il vantaggio del primo metodo e’ una semplicita’ intrinseca nell’inserimento dei nuovi dati all’interno del DOM preesistente (si valorizza l’attributo innerHTMLdel nodo padre), il vantaggio del secondo e’ una maggiore liberta’ rispetto a fornitori di dati esterni che possono utilizzare il formato XML o altri formati per l’interscambio dei dati, come il formato JSON.

Nel nostro framework semplificato abbiamo optato per mantenere inizialmente una elevata semplicita’ di integrazione della nuova tecnologia all’interno dell’applicazione. Grazie a cio’ la progettazione dei fornitori dati attivati sul webserver rimane pressoche’ invariata rispetto alla normale progettazione di pagine HTML/JSP/ASP.NET, a meno di piccole variazioni che vedremo piu’ avanti nel dettaglio.

Quindi l’impostazione con cui si opera utilizzando i vari fornitori dati e’ la seguente:

- si individua il punto destinazione all’interno del DOM
- si richiama il fornitore dati sul webserver, solitamente una pagina dinamica, a volte un file html preformattato
- si attiva la funzione loadHTMLDoc o loadHTMLPost a seconda del metodo GET o POST di trasmissione necessaria.

Resta ora da capire come individuare all’interno del Document Object Model il punto di inserimento dei dati restituiti dal web server in modo asincrono.


Referenziazione di uno o piu’ elementi all’interno del Document Object Model


Il linguaggio JavaScript fornisce tre metodi principali per ottenere un reference ad uno o piu’ elementi all’interno del DOM ricostruito in memoria:

- document.getElementById();
- document.getElementsByTagName();
- document.getElementsByName();

Tutti e tre i metodi sono metodi associati all’oggetto document, elemento principale del nostro DOM, che rappresenta la nostra pagina web.


Il primo metodo restituisce un reference ad un elemento singolo identificato dall’attributo html ID=”…” all’interno di un Tag. Tale attributo deve essere unico all’interno di tutto il documento. Se cosi’ non avviene si ottiene un reference non valido.




Il secondo metodo getElementsByTagName(“”) restituisce un array di elementi che hanno il Tag html indicato come parametro (incluso tra doppi apici).



Il terzo metodo getElementsByName e’ l’analogo del secondo, ma punta non agli elementi con un TAG specifico, ma con un attributo HTML NAME=”…” identico. Allo stesso modo del metodo precedente ritorna quindi un array contenente i riferimenti a tutti gli elementi con un dato valore dell’attributo NAME.



Per concludere, molto spesso si utilizza una combinazione di questi tre metodi per recuperare i reference degli oggetti desiderati, raggruppati all’interno del nostro documento sfruttanto gli attributi NAME e i TAG.
Il piu’ delle volte comunque si ha necessita’ di recuperare il reference ad un singolo elemento, per cui nel nostro framework, per ottimizzare le dimensioni del sorgente Javascript, e’ stata implementato un wrapper dedicato:


Passaggio di parametri al Web Server e chiamata di pagine dinamiche lato server.


Resta ora da risolvere un altro punto importante all’interno dell’architettura delle applicazioni web tradizionali: come facciamo a richiamare funzioni remote sul web server per effettuare ad esmpio l’inserimento di dati sul Database che contiene i dati mostrati e modificati sul nostro client?

Da quanto analizzato in precedenza si deve utilizzare una variante della funzione loadHTMLPost, per poter passare tutti i parametri col metodo POST. Nel nostro framework aggiungeremo una funzione getBeanResult ed un wrapper setValToDB.

Innanzitutto si e’ scelto di differenziare il metodo base loadHTMLPost per fornirgli maggiori potenzialita’, includendo anche un parametro con cui indicare diversi metodi alternativi nel caso in cui dovessimo trattare in maniera diversa i dati restituiti dal server. Il wrapper serve per semplificare la chiamata del metodo sottostante ottimizzandone le dimensioni del codice.

Stiamo ipotizzando di dover attivare un file getBean.jsp, che utilizza le Java Server Pages per poter interagire con un DB server remoto tramite una libreria di funzioni richiamabili traite il meccanismo dei JavBeans.





Il wrapper nasce dal fatto che la chiamata diretta al metodo sottostante puo’ essere scomoda da usare a causa della complessita’ di formato nel caso particolare in cui occorra inserire dati sul Database, mentre il wrapper ha un formato decisamente piu’ standard:



In questo modo possiamo richiamare una pagina dinamica scritta in JSP passando tutta una serie di parametri costruendo una querystring opportuna. Il risultato ottenuto, ovvero il codice html generato dall’application server, puo’ servire per modificare un attributo all’interno di un nodo, un nodo completo o un insieme di nodi all’interno del nostro Document Object Model.


Come si attiva l’Ajax Engine


Una volta capito come richiedere i dati al web server e come smistarli all’interno della nostra pagina all’interno del browser, ci resta da comprendere come integrare il nostro Ajax Engine semplificato scritto in Javascript all’interno della nostra applicazione.

L’applicazione di codice Javascript ad una pagina web e’ una operazione molto semplice; tutto cio’ che occorre e’ usare il tag seguente:

<#script type="text/javascript">
// codice vero e proprio dello script
<#/script>

Per i browser piu’ datati, oppure se vogliamo utilizzare lo XHTML (la nuova versione dell’html) al posto di quello solito, abbiamo bisogno di commentare il codice per avere la sicurezza che il browser non lo mostri all’interno della pagina o cerchi di interpretarlo come tag html.

Esistono die diversi stili per commentare il codice. Per i documenti html e per quelli xhtml in stile “transitional” si usano i normali commenti html:

<# script type="text/javascript">
<#!--
// codice vero e proprio dello script
--#>
< #/ script>

Per I documenti scritti usando l’ xhtml secondo lo stile “strict” occorre usare la sintassi di commento CDATA. percio’ solitamente in questa tipologia di documenti si preferisce utilizzare codice Javascript solo all’interno di file di scripting a parte.
In questo caso si inserisce all’interno della sezione ... della pagina web il riferimento al file esterno.


Resta da capire, una volta che sappiamo come caricare il file esterno con il nostro script, come far interagire lo script con la pagina web, ovvero in che modo attivarlo.
Finora, nel web 1.0, ci sara’ capitato di scrivere codice javascript in relazione al metodo submit() di un form. In quel caso l’azione scatenata dal metodo richiamato dal form richiamava le funzioni javascript che eventualmente avevamo scritto per gestire la validazione dei dati interni al form, oppure per effettuare una prima fase di trasformazione dei dati stessi prima di inviarli al wb server.

Per attivare il nostro Ajax Engine sfrutteremo il seguente meccanismo implementato nel nostro browser per segnalare l’avvenuto caricamento iniziale della nostra pagina web. Il browser riceve dal web server il codice html della nostra pagina; costruisce in memoria il suo DOM a mano a mano che effettua il parsing dell’html, carica in memoria anche gli evetuali fogli di stile esterni, ed il nostro ajax engine.

Quando questa serie di operazioni termina, prima di effettuare il rendering della pagina, ovvero la visualizzazione del contenuto sul pannello principale del browser, viene lanciato un avviso di avvenuto caricamento, intercettabile tramite un event handler Javascript collegato all’evento onLoad().

Oppure possiamo anche sfruttare una caratteristica propria del caricamento del file javascript esterno. Il codice in esso contenuto viene caricato nella memoria del browser ed immediatamente parserizzato e caricato in memoria se si tratta di variabili o funzioni oppure eseguito se si tratta di una invocazione ad una funzione.

Il primo approccio subordina l’esecuzione del codice javascript ad un evento specificamente conseguente al caricamento della nostra pagina web, mentre il secondo presuppone l’esecuzione del codice non appena il browser ha questa possibilita’. Puo’ anche darsi prima dell’attivazione dell’evento onLoad(). Sinceramente penso dipenda dai meccanismi interni ai vari browser. se vi interessa potrete verificare sulla documentazione rilasciata con i vari browser per vedere quale meccanismo usino.

Il punto importante secondo me e’ che se siamo costretti a subordinare l’esecuzione del nostro codice javascript solo dopo il caricamento di tutti gli elementi della nostra pagina dobbiamo utilizzare la prima tecnica. La seconda e’ utile in tutti gli altri casi, non avendo il vincolo di attivare quell’event handler. All’inizio consiglio l’approccio piu’ prudente, utilizzando l’evento onLoad(), anche per evitare noiosissimi problemi di sincronizzazione tra codice javascript e pagina web, assai ostici da individuare e risolvere.


Attenzione alla Cache

Normalmente la cache del nostro browser ci torna utile. Il browser memorizza i file caricati, cioe’ l’utente non deve caricare ogni volta gli script. Pero’ nell’ approccio Ajax questa tecnica di caching puo’ causare dei problemi.

Il browser Safari e’ quello piu’ pericoloso per noi, perche’ almeno nelle versioni precedenti memorizzava lo status della risposta ottenuta dal web server e non segnalava piu’ le sue variazioni.
Le ultime versioni di questo browser potrebbero non avere piu’ questo comportamento specifico.

Comunque evitare questi problemi di caching e’ relativamente semplice: prima di chiamare il metodo send() nel componente XMLHttpRequest e’ sufficiente aggiungere una intestazione specifica alla richiesta che stiamo effettuando con quel componente.

Questa intestazione ( o header ) segnala al browser la necessita’ di testare se la data e’ variata rispetto ad una data di riferimento. Basta inizializzare questa data di riferimento su una data passata al momento in cui scriviamo il codice:




Riassunto

Abbiamo visto come progettare una piccola libreria JavaScript che ci permette di effettaure richieste HTTP in modo asincrono direttamente al web server per richiedere dati generati in modo statico oppure con una pagina web dinamica senza dover pero’ ricaricare la pagina correntemente visualizzata sul browser. Abbiamo anche compreso come ridistribuire i dati richiesti e ricevuti all’interno del documento visualizzato e come attivare questa libreria all’interno di un documento html. Il vantaggio che immediatamente ci salta all’occhio e’ dato dal fatto di non dover ricaricare la maggior parte di una pagina web nel caso avessimo bisogno di aggiornare solo piccole porzioni se non un singolo dato visualizzato nella nostra interfaccia grafica sul client. L’aggiornamento di pochi dati generalmente e’ pressoche’ istantaneo, riducendo solitamente a pochi bytes il codice trasmesso dal server al client. Anche per dati piu’ corposi di solito l’utente continua a lavorare con la sua applicazione web senza i tempi morti e lo sfarfallio che avviene sul browser dovuti al ricaricamento della pagina completa che si avevano nelle applicazioni tradizionali.

Thin Client o Fat Client?

Il Fat Client

Uno dei problemi che uno sviluppatore di applicazioni web in Ajax deve affrontare quando inizia a progettare una nuova RIA, e' come architettare il sistema affinche' risulti veramente innovativo ed interattivo.

In poche parole il sistema deve rispondere idealmente in modo istantaneo alle richieste dell'utente, avendo dal lato opposto il fatto che le risposte dal server possono essere lente in modo avvertibile per l'utente a causa di overheads di processamento e di trasferimento dal server al client.

Il consiglio e' quindi quello di effettuare chiamate remote solo quando non c'e' modo efficiente di ottenere lo stesso risultato sul browser. All'estremo si potrebbe eseguire tutte le operazioni che non coinvolgono una base dati direttamente sul browser.

Solitamente una RIA e' composta da diversi livelli logici o moduli:

• L'interfaccia Utente (detta piu' comunemente GUI o Graphical User Interface)


• Il livello della logica dell'Applicazione o della logica applicativa


• Il livello della logica di Business


• Il modulo che si occupa dell'accesso ai dati


• Il modulo che si occupa della comunicazione esterna al sistema

La GUI e' l'insieme di oggetti che l'utente vede e con cui puo' interagire. La logica applicativa e' quell'insieme di funzioni che regolano il dialogo tra l'utente e il computer, la consequenzialita' delle azioni da compiere, la regolazione del flusso di informazioni verso e dal server. Il livello della logica di Business riguarda la conoscenza del dominio e delle policies dell'owner del sito. Il modulo per l'accesso ai dati riguarda l'interazione con un database. Infine l'ultimo livello riguarda un aspetto comune a molti sistemi aziendali.

Le applicazioni web tradizionali concentrano il codice dell'interfaccia utente nel browser sul client, con un mix di HTML e CSS, con un po' di Javascript utilizzato per eseguire qualche semplice task. Tutto il resto viene gestito sul server web.

Noi pero' in Ajax vogliamo fare di meglio, vogliamo migliorare la suddivisione di questi moduli tra web server e client per ottimizzare la reattivita' della nostra applicazione e minimizzare le latenze che possono esserci.

Se spostiamo l' Application Logic (sicuramente)e anche la Business Logic (forse) sul client si migliora la nostra web application Ajax rispetto ad una tradizionale. Adesso e' il browser che controlla il flusso delle attivita'. Quindi quando un utente compie una qualche azione usando la GUI, e' il browser che prende la decisione su come agire in risposta, e invia una richiesta al server solo se necessario, e per servizi specifici.

Riguardo lo spostamento della Business Logic, assolutamente da evitare nelle applicazioni tradizionali, occorre valutare attentamente i possibili pro e contro a causa di alcuni problemi che potrebbero presentarsi:

• Spostare una Business logic magari basata su PHP, Java o C# in Javascript puo' essere arduo perche' le API standard sono minime e non si hanno a disposizione molti costrutti dei tipici linguaggio che si possono utilizzare lato server.


• Ci puo' essere un problema di portabilita' dovendo aderire agli standard diversi che ogni browser implementa. Un aiuto a cio' puo' essere dato dall'utilizzo di un framework Javascript.


• Lo sviluppo di moduli Javascript complessi non ha ancora a disposizione il supporto di un buon ambente integrato di sviluppo come avviene lato server. Percio' si introduce un livello di difficolta' aggiuntiva per lo sviluppatore inesperto.


• Il codice Javascript puo' essere visionato liberamente rivelando la Business Logic sottostante, a meno di attuare strategie opportune di offuscamento del codice.


• I dati web non vengono generalmente salvati sul client. Percio' e' comunque necessario avere una parte della business logic sul server in connessione con il modulo dell'accesso al database.

Raccontata cosi' sembra una catastrofe. Per fortuna si possono risolvere questi problemi nei modi seguenti:

• Javascript si rivela essere un linguaggio molto potente, scoprendo che nelle applicazioni web tradizionali e' stato sostanzialmente sottoutilizzato. Se poi si utilizza un framework dedicato lo sviluppo in javascript diventa molto piu' semplice e puo' dispiegare appieno tutte le sue potenzialita' finora inespresse.


• Il problema dei diversi browser viene ovviato usando un framework che incapsula e nasconde le varie differenze allo sviluppatore finale.


• Ci sono librerie che forniscono molti ambienti di Logging, Debugging, DOM Inspection e Traffic Sniffing che semplificano lo sviluppo dell'applicazione javascript e la sua manutenzione.

Di sicuro la programmazione in Javascript non e' piu' "produttiva" rispetto all'utilizzo di un linguaggio lato server. I benefici che si ottengono pero' dallo spostamento dei moduli sul client possono portare a spostare anche la Business Logic oltre che l'Application Logic.

Occorre ancora ribadire che Javascript "gira" piu' lentamente delle equivalenti applicazioni desktop, cosi' che l'ottimizzazione e' molto importante. Occorre anche tenere presente l'utilizzo della memoria di sistema ed evitare i bachi specifici di ogni browser che possono portare a sprechi e inefficienze nella memoria utilizzata.

Alternative al Fat Client

Il Thin Client

Un client leggero contiene solo il codice Javascript basilare ed effettua frequenti richieste al server conseguenti all'interazione con l'utente. Questo approccio e' utile quando:

• La business logic richiede tecniche e librerie complesse che possono essere implementate solo lato server


• Ci sono degli impedimenti sullo spostamento verso il client dell' Application e della Business Logic

Il Desktop Client

E' sostanzialmente l'approccio tradizionale della creazione di applicazioni che vengono eseguite sul client direttamente, che hanno bisogno di una installazione preventiva e che si appoggiano direttamente al sistema operativo della macchina dell'utente.

Solitamente la connessione con un database server viene effettuata usando un connettore al database server o attraverso connessioni che si appoggiano su un socket di rete dedicato verso una parte server dell'applicazione.

Tutorial Ajax - Capitolo 1

Capitolo 1 - La “Tecnologia” AJAX

Introduzione

Fino all’avvento della tecnologia AJAX, l’interazione tra client e server veniva effettuata in modo sincrono.

I dati presenti in un FORM venivano inviati tramite la funzione SUBMIT al web server, specificando con il metodo GET oppure POST la modalita’ con cui veniva effettuata la transazione e la trasmissione delle variabili – in chiaro oppure no – richiedendo l’esecuzione di una azione specifica da parte dell’application server in risposta a questa richiesta.

Solitamente si tratta dell’apertura di una pagina dinamica lato server (scritta di solito in JSP, PHP,o ASP) che si occupa del trattamento dei dati inviati, presenti nel form.

Questa pagina eventualmente effettua delle interazioni con un database server, e infine si occupa della creazione dell’output successivo che viene inviato dal webserver al browser dell’utente che aveva attivato l’operazione iniziale di Submit.

Successivamente il browser deve effettuare di nuovo il parsing – ovvero l’interpretazione del codice html e javascript ricevuto - , la costruzione del Document Object Model (DOM) in memoria e la visualizzazione della nuova pagina web come risultato finale di tutte queste operazioni.

Probabilmente non ci siamo nemmeno tanto preoccupati della fase di creazione del modello ad oggetti di rappresentazione della pagina che vogliamo visualizzare dentro il nostro browser, quello che viene detto Document Object Model, poiche’ raramente avremo avuto necessita’ di intervenire su di esso una volta creato.

Facciamo ora qualche considerazione su questo flusso di operazioni, puntando la nostra attenzione sull’efficienza complessiva.
Tutto il processo appena descritto – anche se per sommi capi - implica i seguenti punti critici di inefficienza:

- Nel caso di POST tutti gli stati attuali degli oggetti interni alla pagina contenente il form vengono inviati verso il web server remoto.
- il web server deve inviare una nuova pagina completa al browser come risultato delle operazioni di trattamento dei dati inviati.
- la pagina visualizzata sul browser viene “distrutta” quando si riceve la nuova pagina di risposta, e si ha di conseguenza la perdita dello stato di tutti gli oggetti che compongono la vecchia pagina nella memoria del browser, e la ricostruzione integrale del Document Object Model della nuova pagina da visualizzare.


Se abbiamo a che fare con il caricamento di una pagina totalmente diversa dalla precedente tutto cio’ e’ pressoche’ inevitabile.

E come vedremo sara’ cosi’ anche in Ajax.

Pero’ nel caso in cui viene modificato un unico dato di un form con diverse decine di elementi e dobbiamo ricaricare la stessa pagina aggiornata come conseguenza delle informazioni appena inserite, tipo il nostro esempio del CAP di una citta’ , tutta la pagina deve essere ricaricata completamente dal web server, perdipiu’ in modo sincrono.

Che significa in modo sincrono? Che l’utente non puo’ effettuare nessuna operazione sul form fintantoche’ non viene caricata la nuova versione aggiornata.

Per cui se il canale trasmissivo e’ congestionato, oppure stretto, o asimmetrico tra browser e web server, l’utente deve rimanere in attesa anche qualche secondo per poter continuare ad utilizzare il form in questione.

Se si trattasse di una applicazione desktop ci sarebbe gia’ un capannello di utenti pronti a farci la pelle se ci fossero questi tempo morti tra operazioni successive sullo stesso form!!!

Oltre a cio’ lo sviluppatore deve scontrarsi con il problema che le applicazioni web non riescono a mantenere lo stato degli oggetti interni come abbiamo visto prima.

Questo insieme di inefficienze era un aspetto imprescindibile nella costruzione delle interfacce grafiche “stateless” che hanno caratterizzato le applicazioni web fin dall’origine – per cui si parla comunemente di prima generazione di web applications, o Web 1.0.

Nel frattempo era avvenuta una innovazione che, come capita spesso con le innovazioni, non riscosse il meritato interesse.

Nel 2000 Microsoft sviluppa Outlook Web Access – OWA - , un prodotto per fornire una interfaccia web per il proprio Mail Server Outlook; OWA al suo interno contiene il componente ActiveX “XMLHTTP”.

Originariamente questo componente e’ stato scritto dal team di sviluppo di OWA, e successivamente venne incluso in Internet Explorer 5.0 e reso accessibile sul browser tramite vari linguaggi di scripting supportati da IE, tra cui Javascript, JScript e VBScript.
Il progetto Mozilla successivamente incorpora la prima implementazione nativa compatibile dell’oggetto XMLHttpRequest nel browser Mozilla 1.0 nel 2002. Successivamente seguita dalle implementazioni native nei browser Safari, Konqueror, Opera, Firefox e iCab.

Quindi vediamo che l’oggetto che sta alla base della nuova filosofia AJAX e’ presente in tutti i browser da molti anni. Questo componente permette agli script eseguiti sul browser di effettuare richieste HTTP in modo diretto senza passare dalla funzione Submit interna ad un form.

Nessuno pero’ aveva colto le potenzialita’ progettuali offerte da questo componente disponibile su tutti i browser. La ruota era stata inventata; restava da capire a cosa potesse servire e come poterla utilizzare!

Ma solo nel 2005, grazie ad un articolo di Jesse James Garrett – Ajax: A New Approach to Web Applications (http://www.adaptivepath.com/publications/essays/archives/000385.php) si comincia a parlare di un nuovo approccio di progettazione delle web applications che fa uso di tecnologie esistenti, comunemente utilizzate, e che non richiedono l’aggiunta di plugin o componenti esterni aggiuntivi ai browser utilizzati.

La tecnica Ajax utilizza una combinazione di:

- HTML(o XHTML) e CSS (Cascading Style Sheets) per il markup e lo stile;

- DOM (Document Object Model) manipolato attraverso un linguaggio ECMAScript come JavaScript o JScript per mostrare le informazioni ed interagirvi;


- l'oggetto XMLHttpRequest per l'interscambio asincrono dei dati tra il browswer dell'utente e il web server. In alcuni framework Ajax e in certe situazioni, può essere usato un oggetto IFrame invece di XMLHttpRequest per scambiare i dati con il server e, in altre implementazioni, tag "script" aggiunti dinamicamente (JSON – Javascript Object Notation);

- in genere viene usato XML come formato di scambio dei dati, anche se di fatto qualunque formato può essere utilizzato, incluso testo semplice, HTML preformattato, JSON e perfino EBML. Questi file sono solitamente generati dinamicamente da script lato server.

Come il DHTML (o LAMP), Ajax non è una nuova tecnologia individuale, piuttosto è un gruppo di tecnologie utilizzate insieme.

Tutti I browser odierni possono utilizzare l’oggetto “XMLHttpRequest” che permette di effettuare richieste di carattere asincrono tra browser e webserver.

Mozilla Firefox ha questo componente direttamente disponibile – embedded nel codice del browser, mentre per Internet Explorer occorre caricare esplicitamente il componente ActiveX esterno “Microsoft.XMLHTTP”.

Come si fa a caricare il componente ActiveX XMLHTTP esterno?


Il codice Javascript seguente serve per il caricamento del componente activeX puo’ essere simile a questo:

Questo semplice codice associa alla variabile loadXHR il riferimento ad una funzione anonima che istanzia un oggetto HDR e vi associa il componente ActiveX Microsoft.XMLHTTP oppure l’oggetto nativo XMLHttpRequest( ) a seconda del browser (IE oppure Mozilla).

Internet Explorer, fino alla versione 6, non possiede l’oggetto nativo XMLHttpRequest, mentre Mozilla-Firefox e gli altri browsers non riescono a caricare gli oggetti ActiveX.

Per cui testando il caricamento degli oggetti ActiveX riusciamo a discriminare IE6 dagli altri browsers.

Se con IE non riesce a caricare il componente standard, si tenta di caricare una libreria alternativa – Msxml2. Se non riesce a caricare nemmeno questa seconda ritorna al chiamante un oggetto referenziato in modo “undefined”. Se invece abbiamo a che fare con un altro browser allora caricheremo, se disponibile, l’oggetto XMLHttpRequest nativo.


Dall’ ultima versione di Internet Explorer, la versione 7, si e’ reso nativo il componente, equiparando il tutto al caricamento dell’oggetto XMLHttpRequest.



In questo caso proviamo innanzitutto a caricare il componente nativo. Se cio’ non ha esito positivo (entriamo cioe’ nel ramo “catch”), probabilmente ci troviamo in un browser IE6 o precedente; percio’ tentiamo dapprima di caricare il componente ActiveX alternativo, che si suppone sia quello avanzato piu’ recente; se anche questo secondo tentativo non va a buon fine cerchiamo di caricare il componente primitivo come ultima possibilita’.


Dobbiamo vedere adesso quali funzionalita’ sono offerte dal componente appena caricato.

Prenderemo in esame il componente nativo, dato che quello piu’ datato e specifico per IE6- offre le stesse funzionalita’ differenziandosi solamente nel numero di stati collegati all’attributo readyState.

L’Oggetto XMLHttpRequest - XMLHTTP

Sia che si utilizzi l’oggetto nativo XMLHttpRequest che il controllo ActiveX Microsoft.XMLHTTP, si hanno a disposizione I seguenti metodi e i seguenti attributi:

Metodo	Descrizione
abort()	Cancella la richiesta in atto.
getAllResponseHeaders()	Restituisce sotto forma di stringa tutti gli header HTTP ricevuti dal server
getResponseHeader( nome_header )	Restituisce il valore dell'header HTTP specificato
open(metodo,URL )open(metodo,URL,async )open(metodo,URL,async,userName )open(metodo,URL,async,userName,password)	Specifica il metodo, l'URL, and altri parametri opzionali per la richiesta. Il parametro metodo può assumere valore di "GET", "POST", oppure "PUT" ("GET" è utilizzato quando si richiedono dati, mentre "POST" è utilizzato per inviare dati, specialmente se la lunghezza dei dati da trasmettere è maggiore di 512 bytes). Il parametro URL può essere sia relativo che assoluto. Il parametro "async" specifica se la richiesta deve essere gestita in modo asincrono oppure no – "true" significa che lo script può proseguire l'elaborazione senza aspettare la risposta dopo il metodo send(), mentre "false" significa che lo script è costretto ad aspettare una risposta dal server prima di continuare.
send( content )	Invia la richiesta
setRequestHeader( chiave, valore)	Aggiunge la coppia chiave/valore alla richiesta da inviare.
onreadystatechange	Gestore dell'evento lanciato ad ogni cambiamento di stato.
readyState	Restituisce lo stato corrente dell'istanza di XMLHttpRequest: 0 = non inizializzato, 1 = aperto, 2 = richiesta inviata, 3 = risposta in ricezione e 4 = risposta ricevuta.
statusText	Restituisce lo status in forma di stringa descrittiva (per esempio. "Not Found" oppure "OK").
responseText	Restituisce la risposta del server in formato stringa
responseXML	Restituisce la risposta del server come XML, che potrà essere analizzato e parsato come secondo le specifiche DOM del W3C.
status	Restituisce il codice HTTP restituito dal server (per esempio 404 per "Not Found" e 200 per "OK").

Perche’ AJAX?


Se consideriamo il termine nella sua accezione originaria esso e’ l’acronimo di “Asynchronous JAvascript and Xml”, che possiamo tradurre come “(utilizzo di) Javascript ed XML in modo asincrono”.

A come Asincrono


Il termine “asincrono” significa che lo script che utilizza l’oggetto XMLHttpRequest puo’ proseguire nell’elaborazione del codice successivo senza attendere il risultato atteso dopo il metodo send() fino a che sia reso effettivamente disponibile da parte del web server .

Ovvero, per chi conosce il meccanismo degli event handlers in Javascript, si definisce l’event handler associato all’evento onreadystatechange .

Quando l’engine javascript ricevera’ i dati dal web server verra’ richiamato l’event handler , eseguendolo non appena possibile, cioe’ appena terminata l’istruzione corrente che si trovava in esecuzione che probabilmente appartiene ad una diversa porzione del codice dello script, opure immediatamente se l’engine si trova in uno stato di inattivita’.

Per la precisione e’ possibile forzare l’oggetto per renderlo sincrono rispetto al resto dello script. In questo caso si interrompe l’esecuzione delle istruzioni successive al send() finche’ non si riceve la risposta da parte del web server.
Pero’ in questo modo non possiamo continuare ad eseguire altro codice nell’attesa, e se il web server non fornisce una risposta non possiamo riprendere l’esecuzione dello script.

Personalmente preferisco lasciare attivata l’impostazione asincrona, permettendo l’eventuale completamento dello script mentre si attendono i dati richiesti al server.


JA come JAvaScript

Se nel web 1.0 l’utilizzo del linguaggio Javascript era limitato a qualche riga di codice necessario a validare i campi di un form prima di inviare i dati al server, oppure a sviluppare qualche elemento visuale sul client come un menu ad albero (TreeMenu), nel nuovo approccio progettuale Javascript assume il ruolo principale per la creazione di un Engine global del client.

Nella sostanza, non avendo teoricamente piu’ la necessita’ di utilizzare gli oggetti Form e il loro meccanismo di Submit, potremmo non dover piu’ dismettere una pagina web e caricarne una nuova che contenga i dati aggiornati, ma caricare solo e soltanto i dati aggiornati e smistarli nella pagina web attuale.

Vedremo nel dettaglio quanta importanza assumera’ il linguaggio JavaScript nell’ambito della progettazione di una applicazione web Ajax.


- inizializzare la nostra applicazione caricando l’oggetto XMLHttpRequest
- intercettare le azioni effettuate dall’utente tramite l’interfaccia grafica
- identificare gli oggetti visuali coinvolti e gestire i valori associati ad essi
- gestire le condizioni per attivare l’evento send() , costruendo la richiesta che vogliamo effettuare in modo opportuno
- smistare i dati ricevuti in risposta dal serverIl linguaggio Javascript ora ci serve per:

Tutto cio’ e’ accompagnato dall’utilizzo delle strutture - funzioni di libreria ed attributi - rese disponibili all’interno del Document Object Model della pagina web . Percio’ alla base dell’utilizzo del javascript deve esserci una buona conoscenza del DOM creato da parte del browser all’atto del caricamento di una pagina web.

X come XML (eXtensible Markup Language)


Non preoccupatevi, l’utilizzo dell’xml non e’ obbligatorio. Gia’ vi sentivo: “va bene dover utilizzare javascript, un linguaggio ritenuto ostico, ma non anche l’xml...” .

Semplicemente Jesse James Garrett ha preso in considerazione l’xml come formato dei dati da ridistribuire all’interno di una pagina una volta che siano arrivati a fronte di una richiesta asincrona fatta al web server.

In realta’ oltre all’xml si puo’ utilizzare direttamente l’html oppure JSON (javascript Object Notation) come formato dei dati scambiati in modo asincrono. Il formato che preferisco per la flessibilita’ offerta e’ JSON, mentre l’HTML permette la massima velocita’ di ridistribuzione dei dati all’interno della pagina.

Personalmente non utilizzo l’XML, che secondo me comporta la scrittura di piu’ linee di codice e una maggiore lentezza per smistare i dati negli oggetti voluti.

Analizzeremo comunque successivamente le varie tecniche che possono essere utilizzate per formattare i dati scambiati tra client e server in modo asincrono secondo questi tre formati elencati, provando ad elencare pregi e difetti di ognuno secondo la mia personalissima esperienza.

Tutorial Ajax - Introduzione

Premessa

Questo Tutorial e’ indirizzato a programmatori che si trovano gia’ a progettare applicazioni aziendali fruibili attraverso Internet utilizzando un browser per visualizzare l’Interfaccia Grafica – o GUI , Graphical User Interface – che siano gia’ in possesso di una buona conoscenza del linguaggio HTML abbinato alla conoscenza dei Fogli di Stile a Cascata e ai piu’ elementari rudimenti del linguaggio JavaScript .

I CSS o Cascading Style Sheets riguardano gli aspetti progettuali per quanto concerne gli stili da applicare ai documenti html o xhtml, utili per separare i contenuti dalla formattazione. Javascript e’ il linguaggio di scripting maggiormente utilizzato per scrivere codice eseguibile all’interno del browser.

Reputo facoltativa ma caldamente consigliata la conoscenza specifica di un linguaggio per la progettazione di pagine web dinamiche, poiche’ nel corso di questo manuale si introdurranno comunque delle tecniche di programmazione di contenuti dinamici sul webserver/application server utilizzando JSP e ASP.NET+C#.
Ritengo che possa essere ugualmente utile la conoscenza alternativa di uno degli altri linguaggi , PHP, Ruby, VB.NET , ASP 3.0, che oggigiorno e’ possibile utilizzare per creare contenuti dinamici sul web.

Sono anche consigliate le conoscenze basilari riguardo aspetti correlati alla progettazione web quali quelle relative al Document Object Model di un browser, le modalita’ di trasmissione dati attraverso il protocollo HTTP, e la conoscenza dell’architettura di un WebServer quale puo’ essere Apache o IIS, o meglio di un Application Server quale Tomcat (per il JSP) oppure IIS abbinato al Framework .NET (per ASP.NET+C#).

Per chi volesse invece intraprendere da zero l’arte della progettazione di pagine web, statiche e dinamiche, consiglio la lettura preliminare di un manuale introduttivo all’ html/xhtml abbinato ad un manuale di JavaScript e a un tutorial introduttivo per quanto riguarda i CSS.

Se fate parte di un team di progettazione web in cui i ruoli tra gli sviluppatori della parte client e gli sviluppatori della parte server sono separati tra loro, la conoscenza dei linguaggi dinamici e dei meccanismi che sottostanno ad un web/application server non saranno necessari.

Se invece, come me, vi siete sempre occupati di tutti gli aspetti inerenti la progettazione di web applications, non mi rimane che augurarvi buona lettura, con la speranza – ma anche la certezza - di potervi essere utile con questo manuale per scoprire tutte le potenzialita’ che Ajax puo’ offrire per migliorare le web applications che ci troveremo a progettare, per quanto esse possano diventare complesse.

Introduzione

Ormai sono quasi due anni da quando mi sono imbattuto, navigando in rete alla ricerca di articoli e manuali per accrescere il mio background tecnico relativo alla progettazione di applicazioni web, nel termine forse attualmente piu’ alla moda nel panorama della progettazione web – la Tecnologia AJAX.

Parlando di progettazione di applicazioni web mi voglio riferire non ai siti web tradizionali – siti di News , di Informazioni tecniche, che normalmente immaginiamo di incontrare durante la nostra esperienza di navigazione sul web, ma a quelle applicazioni che possono essere distribuite su un browser all’interno di una Intranet Aziendale, come puo’ essere una applicazione per gestire i Fogli Ore dei Dipendenti oppure l’applicazione per la Posta Elettronica , o una applicazione per la gestione delle Commesse Clienti o del Magazzino.

Gli esempi di applicazioni aziendali o di carattere personale possono essere innumerevoli; pensiamo ad esempio alla gestione della propria rubrica telefonica o ad una applicazione per gestire le entrate/uscite familiari.

Tecnologia AJAX – Di quale diavoleria ultra sofisticata stiamo parlando?

Fino a quel momento conoscevo le seguenti tecnologie web per costruire siti “dinamici” : PHP, ASP, JSP, ASP.NET. Le avevo gia’ utilizzate tutte quante negli anni precedenti per progettare piccole applicazioni web aziendali per vari clienti.

Dall’applicazione che gestiva l’anagrafica degli sportelli di un grande Istituto Bancario, al progetto di un portale per la gestone dei Fogli Ore e delle Note Spese dei dipendenti e dei consulenti per una azienda di consulenza informatica. Dal portale per la gestione degli ordini e del catalogo prodotti di una azienda di serramenti al sito web di supporto ad una serie di corsi relativi alla progettazione di siti web dinamici da me tenuti all’interno di una commessa relativa all’erogazione di corsi di tecnologie informatiche.

Sono sempre stato attratto dalle novita’ collegate al mondo della programmazione web, e stavo anche prendendo in considerazione la prospettiva di approfondire le mie conoscenze anche sul framework delle Java Server Faces e di Struts, come pure del linguaggio Ruby e del framework Ruby on Rails. Di queste tecnologie piu’ o meno ne avevo sentito parlare diffusamente ,ma quando mi sono imbattuto in Ajax non immaginavo proprio di cosa si trattasse.

Conoscevo d’altronde, come tutti, le Google Maps (e chi non le conosce, direte voi). E mi ero sempre chiesto quale fosse il trucco grazie al quale i programmatori di Google avessero potuto creare una applicazione web veloce e cosi’ “avanti” rispetto alle applicazioni che si riuscivano a fare normalmente.

Avevo sentito nominare Ajax solo una volta, relativamente ad un’altra applicazione in fase di sviluppo sempre da parte di Google per ricreare un foglio di calcolo Excel-like sul web, pensando tuttavia che potessero fare uso dello stesso “trucco” delle Maps, un qualche plugin proprietario blindato e quindi non utilizzabile nelle applicazioni di tutti i giorni.

Quando mi e’ capitato sottomano il libro “Pragmatic Ajax – A web 2.0 primer – sono stato preso dalla curosita’ di vedere effettivamente in cosa consisteva questa tecnologia che nel frattempo acquisiva sempre maggior fama sui siti tecnici di programmazione web, promettendo la possibilita’ di progettare applicazioni web innovative e rivoluzionarie (appunto si parlava di web 2.0, una nuova era per il web), le cosiddette Rich Internet Applications – o RIA, come capita spesso di leggere sul web.

Da allora e’ passato un po’ di tempo, circa un anno e mezzo, e quello che vorrei fare ora e’ raccontare la mia personalissima esperienza con questa tecnologia, sperando che possa essere di un qualche aiuto per comprenderla almeno un poco, ma soprattutto per farvi capire per quale motivo ha rivoluzionato lo scenario della progettazione delle applicazioni web, come anche la mia esperienza lavorativa .



Il Web 1.0 – Che noia!

Se avete cominciato a progettare pagine web da qualche tempo, il percorso che probabilmente avrete seguito puo’ essere simile al mio:

· si parte imparando un po’ di HTML, si fanno le prime paginette statiche – qualche immagine, qualche link qua e la’, la immancabile immaine/barra “Under Construction” con l’omino che lavora.
· Si aggiungono i contenuti dinamici – la data attuale, pagine variabili a seconda dell’utente collegato
· Si gestisce il collegamento con un database per recuperare dinamicamente i dati da visualizzare e per memorizzare i dati immessi. Si cominciano a progettare i primi form piu’ o meno complessi.
· Si progettano form sempre piu’ complessi su pagine diverse, gestendo le operazioni di “Submit” grazie ad un linguaggio dinamico tra quelli visti prima (PHP, ASP, o JSP) e memorizzando le informazioni comuni a varie pagine tramite le variabili di sessione.
· Si gestisce il mantenimento dello stato all’interno di una stessa pagina sempre grazie alle variabili di sessione, o magari grazie ai meccanismi propri dei JavaBeans nel caso del JSP o grazie ai meccanismi interni del framework .NET nel caso dell’ASP.NET

Non e’ detto che tutti debbano seguire questo percorso. A me e’ capitato piu’ o meno questo; ma quando ho iniziato ad interessarmi alla programmazione web, nel lontano 1995 all’universita’ (in realta’ gia’ nel 1990 si usava internet all’universita’ ma all’epoca il www non esisteva ancora, c’erano pero’ le e-mail, usenet, gopher,l’ FTP, le BBS, le news, e soprattutto IRC tra le varie universita’ di Milano – bei tempi quelli....) esisteva solo l’HTML e le Common Gatweay Interfaces in Perl.

Finche’ si tratta di fare pagine web “classiche”, ovvero in cui c’e’ un testo da visualizzare, con immagini, link, a cui si puo’ applicare una formattazione con i fogli stile basata sui CSS, non ci sono molti problemi, e’ tutto sommato molto elementare, a mio avviso. Procede tutto liscio senza troppi inghippi anche quando si deve progettare un piccolo form per inserire qualche dato in un database, e visualizzare dinamicamente i risultati.

Si utilizza anche qualche linea di codice scritta in Javascript per validare i campi del form direttamente sul client senza dover effettuare una “Submit” e quindi fare la validazione sul server.
Ma fatti una volta o due va tutto bene. La maggior parte del valore aggiunto di un sito web di questo tipo si gioca o sulle caratteristiche grafiche del sito stesso, sulla sua ergonomia.
Diciamo che fatto uno, fatti tutti....personalmente mi annoiavo dopo un po’ quando progettavo siti web di questo tipo. Dopo un po’ non ci trovavo nulla di interessante, di stimolante.

Percio’ poi mi sono dedicato allo sviluppo non tanto di pagine web quanto di applicazioni aziendali distribuite sul web. Pero’ questo tipo di applicazioni non hanno mai avuto un enorme successo per una serie di difficolta’ tecniche e pratiche.



Il problema del Web 1.0 – I Browser sono smemorati!


Il grosso problema che avevo sempre incontrato nella progettazione di web-applications complesse come gestione dell’interazione tra utente ed interfaccia grafica era che il browser, lo user-agent su cui si “eseguono” le pagine stesse, non fosse in grado di mantenere lo stato delle variabili contenute nel codice dinamico nel passaggio da una pagina ad un’altra.

Mi spiego meglio. Supponiamo che nella prima pagina di un form per inserire il i dati anagrafici di un dipendente devo popolare i dati di citta’ e CAP, devo gestire l’inserimento del secondo campo subordinandolo alla scelta del primo. Quindi per caricare l’elenco dei CAP collegati ad una citta’ sono costretto a scegliere tra le due alternative:

- O carico l’elenco completo di tutti i CAP di tutte le citta’ che l’utente puo’ scegliere
- O faccio una submit verso il server della citta’ scelta per caricare i CAP relativi.

Il primo caso e’ poco efficiente, perche’ magari devo caricare un elenco lunghissimo di CAP che non mi servono, e per cui devo trovare anche un modo per “nascondere” i CAP che non corrispondono alla citta’ che l’utente potra’ scegliere.

Nel secondo caso si deve ovviare al problema che quando ricarico la pagina la seconda volta il browser non riesce automaticamente a “ricordarsi” cosa era stato selezionato sul form precedentemente. Ovvero il browser si “dimentica” quale fosse lo stato delle variabili sottostanti collegate ai vari elementi del form di inserimento.

Per questo motivo siamo costretti a mantenere traccia sul server della struttura e del valore di tutte le variabili del nostro form, di modo che l’operazione di submit trasmetta al server i valori attuali che poi il server restituira’ al client quando popolera’ la lista aggiornata dei CAP per la citta’ selezionata.

Questo non e’ nemmeno la situazione peggiore, anzi e’ una di quelle piu’ semplici da gestire.

In fin dei conti si tratta sempre della stessa pagina. Ma se dovessi passare dei valori da una pagina alla successiva o magari rendere disponibili dei valori comuni a tutte le altre pagine, e il loro comportamento dipende dal valore assunto da queste variabili “globali” che magari possono anche andare in conflitto tra loro?

Ecco l’incubo di chi ha progettato web-applications finora.

Dover riempire il codice dinamico da far eseguire all’application server di strutture di controllo, di costrutti “if ...then ...else”, di sezioni html “camaleontiche” per gestire le chiamate successive alla stessa pagina e i cambiamenti di stato delle variabili sottostanti.

Per non parlare dell’uso del Javascript sul client per preparare le variabili da trasmettere al server quando si attivava l’operazione di “submit” di un form.

A parte la difficolta’ tecnica di questo approccio, quello che piu’ mi infastidiva era che trovavo il tutto poco naturale e poco intuitivo da gestire rispetto all’approccio che si usava ad esempio nella progettazione di desktop-applications con un linguaggio event-based come VisualBasic o VisualC++, per non parlare della progettazione delle interfacce grafiche fatte in Java con la libreria SWING o fatte in applicazioni C# desktop usano VisualStudio.NET.

Sinceramente mi sarebbe piaciuto poter utilizzare la stessa impostazione per sviluppare delle applicazioni distribuite che avessero il browser come client, e non un client da installare su ogni postazione e da far girare sul desktop.


Ajax ed il web 2.0


Premetto una cosa: se pensate che quando si parla di Ajax si stia parlando di una vera e propria tecnologia, o se qualcuno ve lo vuol far credere, non e’ cosi’.

Alcuni definiscono Ajax come un nuovo approccio di progettazione, io tendo a considerarla come lo spostamento della visuale del progettista web verso lo stile di progettazione “ad eventi” tanto caro alle desktop-applications.

Chi ha programmato in VisualBasic non deve imparare un nuovo approccio, ma si ritrova a dover utilizzare quello seguito abitualmente.

Per brevita’ usero’ comunque io stesso il termine “tecnologia” associato al terine “Ajax”, intendendo pero’ quanto detto prima.

Prima di cominciare con i dettagli tecnici vorrei aggiungere una cosa soltanto: questo nuovo approccio permette davvero di poter creare applicazioni web innovative, con un elevato valore aggiunto rispetto a quelle che potreste aver sviluppato finora, ma tutto cio’ non “viene via gratis”.

In un certo senso preparatevi a dover imparare quasi da zero a progettare e sviluppare web-applications; quello che vi serve probabilmente lo conoscete gia’: html, javascript, dhtml/DOM, ed un linguaggio di programmazione lato server come php, jsp o asp.net+c#. Bisogna solo imparare ad usarli in modo diverso rispetto a quanto fatto finora.

Come migliorare le prestazioni di una Rich Internet Application Ajax minimizzando i caricamenti dei files JavaScript e CSS

Tutti quelli che hanno sviluppato software sanno che le performances di un programma contano tantissimo, e che un codice scritto senza tenere conto delle sue prestazioni in esecuzione puo' generare un programma lento e quindi poco efficiente.

Che si fa nei casi in cui si scopre che un codice "gira" lento? Per prima cosa si cercano i punti critici di inefficienza e quindi si cerca di intervenire utilizzando algoritmi piu' efficienti per migliorare le prestazioni della porzione di codice causa di inefficienza.

Per far cio' viene in aiuto tutta la Teoria della complessità computazionale, che misura l'efficienza degli algoritmi. Di sicuro un algoritmo di ordinamento che in un numero di passi finito possa trattare infiniti dati sarebbe il non-plus-ultra per un progettista di software. Ma sappiamo anche che un algoritmo con complessita' O(log n) e' piu' efficiente di un algoritmo con complessita' O(n).

Ma come interviene questo discorso nelle nostre Rich Internet Applications sviluppate col paradigma Ajax?

Innanzitutto occorre dire quali possono essere i punti piu' critici nello sviluppo di una RIA Ajax per quanto riguarda le performance della nostra applicazione: Javascript senza dubbio.

Non per colpa sua, secondo me, ma per colpa del browser su cui deve essere interpretato ed eseguito.

Si, certo, e' un linguaggio interpretato in run-time, e come tale non il massimo della vita in termini di efficienza in fase di esecuzione. Credetemi se non l'avete mai provato, ma ad esempio anche Flex usa un linguaggio , l' ActionScript, che e' cugino di Javascript perche' aderisce alla medesima standardizzazione, l'ECMAScript. Ed anche ActionScript viene interpretato dalla propria Virtual Machine.

Ma una applicazione sviluppata in Flex e' molto piu' veloce di una RIA Ajax in Javascript.

Perche' la macchina virtuale che interpreta il codice Javascript all'interno dei vari browser non e' mai stata ottimizzata come si deve, secondo me.

Ad esempio, utilizzando Internet Explorer, se si esegue una procedura Javascript il browser facilmente utilizzera' tutte le risorse a disposizione in termini di percentuale di CPU e anche la piu' semplice delle operazioni eseguita su una macchina non aggiornatissima in termini di CPU, se non ottimizzata, puo' portare a tempi di esecuzione di qualche secondo.
E qualche secondo con la CPU al 100% puo' far innervosire l'utente finale che nel frattempo difficilmente potra' fare qualcos'altro se non attendere che il browser abbia terminato.

I 4 principale browser utilizzati oggigiorno, IE 7, Firefox 2, Safari 3 ed Opera 9 hanno fatto comunque importanti passi in avanti riguardo alle performances con Javascript rispetto alle versioni precedenti.
Ed in particolare Safari 3 ha raggiunto un ottimo livello di velocita'. Ma ancora non basta.

Quindi nelle nostre applicazioni web Ajax assume grande importanza avere un codice Javascript un minimo ottimizzato. Cioe' non scritto con i piedi, per intenderci...

Questo per quanto riguarda aspetti comuni anche con tutti gli altri linguaggi di programmazione.

Pero' c'e' un aspetto peculiare delle web applications che assume ancor piu' rilevanza in Ajax: i tempi di caricamento delle pagine web.

Se assimiliamo la nostra web application complessa ad una pagina web, si hanno piu' fasi da considerare quando un utente vuole utilizzare questa applicazione sul suo browser.

• La prima, se la nostra pagina e' dinamica, e' data dal tempo impiegato dal server a creare l'output html da inviare al client.
• La seconda fase e' quella del caricamento della pagina dal web server al client.
• Poi interviene il parsing del codice JavaScript e la costruzione del Document Object Model sul client.
• Infine c'e' una fase di rendering degli elementi che si vogliono visualizzare sullo schermo.

A questo proposito si puo' vedere il link seguente per vedere una applicazione di benchmark che mette a confronto diverse tecnologie per implementare Rich Internet Applications riguardo le varie fasi di caricamento.

Riguardo al primo punto non sempre avviene, se ad esempio costruiamo la nostra web application con una pagina introduttiva snella e soprattutto statica.

E' la seconda fase a darci i problemi maggiori di solito. Usando il paradigma Ajax si ha a che fare ora con un sistema di gestione della nostra applicazione scritto in Javascript che deve essere eseguito ora sul client.
Chiamero' questo sistema di gestione "engine", o motore, della nostra applicazione.

L'engine Ajax si deve occupare delle richieste asincrone da inviare al server usando l'oggetto XMLHttpRequest, della distribuzione dei dati risultanti ricevuti dal serve negli elementi della nostra applicazione, e dell'interazione con l'utente.

Facilmente si deve implementare un engine complesso qualche migliaio di linee di codice e grande qualche centinaio di KB. Commenti nel codice a parte.

E la criticità' di questa fase e' dovuta alla banda disponibile nel collegamento tra client e server.

Se dobbiamo caricare diverse centinaia di kiloBytes con un modem a 56Kbit dovremo mettere in conto anche qualche decina di secondi di attesa.

Se poi dobbiamo caricare piu' files Javascript il browser per ognuno di essi deve aprire una sessione di caricamento, aumentando cosi' il tempo totale impiegato. Stesso discorso per tutti gli altri files eventualmente da caricare, come possono essere i files CSS.

Quindi alla fine dei conti non e' infrequente trovarsi a dover attendere qualche secondo di caricamento iniziale anche disponendo di un collegamento a banda larga verso il web server.

Come si puo' operare allora per migliorare le performances di caricamento iniziale?

Innanzitutto diminuendo il numero di files accessori che si cerca di caricare. Cioe' se abbiamo per ipotesi 5 CSS e 5 Javascript, proviamo a mettere tutto il codice CSS in un singolo file per il fogli di stile e tutto il codice Javascript in un unico file per lo script lato client.

Poi sta alla sensibilita' di ogni progettista mediare tra la necessita' di diminuire le richieste verso il server e mantenere comunque una discreta manutenibilita' dei vari files di scripting, per cui magari si preferisce tenere separate parti di codice in unita' logiche distinte.

Secondo punto su cui e' possibile intervenire e' comprimere il codice Javascript.

Teniamo presente che, trattandosi di un linguaggio interpretato, i commenti vengono ignorati dal motore del browser in fase di parsing.

Quindi potremmo creare una versione dell'engine Ajax di debug o di sviluppo, con tutti i commenti presenti, e poi una versione di "produzione" in cui si e' fatto lo "stripping" dei commenti, degli spazi in eccesso, dei ritorni di riga, e di tutti quegli elementi ignorati in fase di parsing del codice.

Gia' cosi' un listato Javascript, con commenti ridotti all'osso puo' "dimagrire" dal 10% al 30%. Si dice quindi che un file viene "minimizzato".

Poi un file javascript puo' anche venire compresso.

In un codice Javascript a parte le parole chiave proprie del linguaggio, compaiono sostanzialmente nomi di variabili/oggetti e nomi di funzione. Trovare un oggetto "itemImageArray" o delle funzioni "setControlText" o "disp_controlUserCountryEditing" e' la normalita'. Di solito tendiamo a scrivere codice criptico per gli altri, ma per noi che lo scriviamo comunque ha un suo senso, una sua logica per i nomi che abbiamo utilizzato al suo interno.

Di certo e' raro che scriviamo un codice con oggetti denominati _a, xy, s3 oppure funzioni g6( ), 4h( ), qw( ). Senno' una volta scritto il nostro programma diventa incomprensibile anche a noi stessi che lo abbiamo pensato!!!

Esistono quindi strumenti tipo packer che effettuano questa trasformazione dei nomi di variabile e di funzione, costruendo uno spazio dei nomi abbreviati - incomprensibili per una persona - e comprimendo di fatto le dimensioni del file javascript originale anche fino all'80%!!!!

Capita quindi che da un file di partenza di 100KB o piu' si riesca ad ottenere un file di 10KB o meno. E su una connessione a banda stretta la differenza nei tempi di caricamento e' notevole.

Uno svantaggio dell'utilizzo di uno strumento come packer e' che se manca un ";" come chiusura di una funzione anonima, il parser javascript non riesce piu' ad interpretare il file, mentre normalmente cio' non accade con la versione non minimizzata e/o compressa anche se previsto dal linguaggio.

Vabbe', meglio direi io, cosi' si e' obbligati a scrivere codice migliore e piu' robusto, dovendo seguire per forza le regole formali del linguaggio.

Un ulteriore vantaggio e' ottenere un minimo grado di "Obfuscation".

Siccome Javascript richiede un sorgente da interpretare, chiunque puo' scaricare un engine Ajax e fare "retro-engineering" del codice e sfruttare il lavoro fatto da altri. Utilizzando packer si rende il codice incomprensibile ad una lettura superficiale. In realta' e' possibile risalire al codice originale compresso, con strumenti come "unpacker".

Se si volesse rendere ancora piu' difficile il la retroingegnerizzazione del codice occorrerebbe usare strumenti piu' avanzati che non permetterebbero la decompressione del codice una volta processato.

Ma cio' trascende le mie conoscenze e quindi lo spirito di questi post.

Un ultimo accenno ancora: su Internet Infomation Services 6.0 (IIS) il web server Microsoft presente su WindowsXP Server 2003, e mi pare anche su Windows Vista, esiste la possibilita' di attivare una opzione per gzippare lo stream di dati inviato dal web server ai vari client.

Chi di voi non ha mai zippato un file? Ecco, gzip e' uno dei tanti programmi per comprimre un file, compatibile con il formato di compressione ZIP. E i browser recenti hanno la possibilita' di ricevere uno stream di dati compresso con gzip effettuandone la decompressione "al volo" una volta ricevuti i file compressi.

IIS 6.0 si occupa quindi della compressione in automatico di un file javascript, html o css e dell'invio al client del file in versione compressa. Poi ci pensa il browser a decomprimerlo e ad utilizzare correttamente il file originale.

Personalmente non ho mai avuto occasione di provare la compressione HTTP diretta anche se mi aspetto comunque un ulteriore dimagrimento dell'Ajax engine da caricare, magari minimo, a fronte di una latenza aggiuntiva dovuta alla decompressione sul client del file zippato.

Occorrerebbe quindi verificare di caso in caso se e' maggiore il risparmio dovuto al dimagrimento del file o la latenza aggiuntiva. Se non si utilizza packer pero' e' sicuramente maggiore il vantaggio dato dalla compressione del file con gzip rispetto alla latenza per la sua decompressione, soprattutto con un hardware del client di ultima generazione.

Chi volesse puo' leggere l'articolo seguente che spiega come attivare la compressione HTTP: Using HTTP compression with IIS 6.0. So che anche con Apache e' possibile effettuare la compressione HTTP diretta, e doverbbe essere facile reperire informazioni tecniche a riguardo su www.apache.org sui moduli mod_gzip e mod_ziplook e mod_deflate.

Che cosa e' Ajax?

Quando si cerca di spiegare a qualcuno cosa e' Ajax, si possono seguire due strade. La prima e' quella che spiega il termine come acronimo di Asynchronous JAvascript and XML. La seconda invece e' quella che parla di una tecnica per creare applicazioni web interattive usando richieste asincrone di dati fatte al web server.

In entrambi i casi pero' probabilmente c'e' bisogno di capire cosa significa il termine "asincrono" nella progettazione di applicazioni web.

Spero innanzitutto che sappiate come creare una pagina web, statica o dinamica che sia.

Quando volete visualizzare una pagina web sul browser dalla vostra macchina locale viene inviata una richiesta al web server remoto dove e' pubblicata. Il web server ricevendo questa richiesta reagisce inviando al computer richiedente tutto il codice html che compone la pagina statica richiesta. A questo punto il browser interpreta il codice html che ha ricevuto e comincia a ricostruire in memoria l'insieme di elementi ed oggetti che poi mostrera' a video.

Se invece e' stata richiesta una pagina web dinamica allora il web server esegue il codice dinamico, che in sostanza e' un programma, sul server remoto. Il risultato dell'elaborazione di questo codice e' una pagina html che viene restituita e segue infine il percorso precedente fino alla visualizzazione sullo schermo dell'utente.

In questo scenario l'interazione tra client, la macchina dell'utente che vuole visualizzare la pagina web all'interno del suo browser, ed il web server, dove risiede fisicamente la pagina web, e' sincrono.

Cioe' quando il client invia una richiesta, rimane in uno stato di attesa, fino a quando non riceve una risposta di qualche tipo dal web server o finche' non viene raggiunto un periodo timeout. Questo sincronismo viene governato dal protocollo HTTP, cui client e web server aderiscono, e che regola il meccanismo di richiesta-risposta che intercorre tra le due macchine collegate in rete.

Se l'utente richiede un aggiornamento di una pagina che mostra in tempo reale l'andamento dell'indice azionario di borsa, il client richiede al server una versione aggiornata, se esiste, della pagina web. In caso affermativo il server invia al client il codice html della pagina web che conterra' al suo interno le informazioni aggiornate da visualizzare sullo schermo.

Se dalla visualizzazione precedente e' cambiato solo un valore tra molti indici azionari mostrati in una tabella, qualcuno potrebbe chiedersi se non sia piu' efficiente da parte del web server inviare solo i dati che sono cambiati rispetto alla pagina mostrata in precedenza. Di sicuro verrebbero trasmessi molti meno dati dal web server verso il client. E se si sta navigando su internet con un modem a 56k, come avveniva fino a qualche anno fa, trasmettere qualche centinaio di kbytes piuttosto che solo qualche byte fa una bella differenza.

Qualcun'altro a questo punto potra' ribattere che ormai quasi tutti hanno connessioni veloci, ADSL o su fibra ottica, e risparmiare qualche millisecondo (!!!) non fa nessuna differenza.

Dobbiamo tenere presente anche di un'altro aspetto che avviene quando ricarichiamo una pagina web: la ricostruzione del Document Object Model.

Il browser quando interpreta il codice html costruisce in memoria un modello degli elementi che compongono la pagina. La sezione di "head", la sezione di "body", la presenza di paragrafi di testo, di caselle di input, di bottoni, di immagini, di checkbox, di un Form. Ovvero tutti gli elementi che possono essere inseriti in una pagina html hanno la loro controparte in quello che viene chiamato DOM, ovvero Modello ad Oggetti del Documento.

In questo modo abbiamo un mezzo per agire in modo programmatico sul nostro documento visualizzato usando un linguaggio di scripting direttamente sul client, come puo' essere il JavaScript.

Il classico esempio che si riporta e' quello della validazione dei dati di un Form quando si inviano i dati al server. Se dobbiamo valorizzare un campo data dobbiamo controllare che l'utente stia digitando la data nel formato desiderato. E che stia immettendo una data "lecita". Il mese numero 13 ad esempio non esiste sul calendario!

Un programmatore di applicazioni web sa bene che quando possibile e' sempre meglio effettuare la validazione dei dati direttamente sul client per risparmiare l'invio di dati scorretti al server che altrimenti dovra' lui provvedere ad effettuare questo controllo.

Dicevo, quando una pagina web viene ricaricata, anche per la variazione di un singolo dato al suo interno, il browser distrugge il DOM precedentemente memorizzato e ricostruisce da zero il DOM della "nuova" pagina caricata.

Questo e' uno dei motivi per cui la programmazione tradizionale delle applicazioni web basate su pagine dinamiche non ha avuto sviluppi eclatanti. Le pagine web tradizionali non riescono a mantenere lo "stato" delle variabili che compongono il DOM della pagina stessa e che "descrivono" lo stato attuale dell'applicazione sul browser nel client di un dato utente.

Se l'utente ha valorizzato il campo data con la proria data di nascita, non potremmo mantenere "viva" questa informazione quando passiamo ad un'altra pagina e nemmenoquando ricarichiamo quella attuale, se non grazie al supporto del web server a cui magari abbiamo passato il valore di quella variabile da memorizzare come variabile di sessione interna al web server.

Quanti di voi hanno avuto a che fare con questi meccanismi? Tanti imnagino se avete creato qualche piccola applicazione web usando una tecnologia come php, jsp o asp(.net).

Solo per citare gli aspetti piu' elementari della progettazione di una web application.

Torniamo ora alla nostra questione iniziale: le richieste asincrone.

Nella progettazione di una pagina web si ha a disposizione un oggetto manipolabile con Javascript - l'oggetto XMLHttpRequest, o il componente ActiveX corrispondente su IE6 - che puo' effettuare richieste asincrone al web server.

Cioe' richieste che non implicano necessariamente che il client rimanga in attesa della risposta dal server bloccando l'interazione con l'utente della pagina visualizzata, ne' tantomeno la distruzione del Document Object Model quando riceve la risposta alla richiesta effettuata.


E' un po' come se il browser abbia la possibilita' di effettuare operazioni in multithreading nella gestione di una pagina web, grazie allo scambio in background di pacchetti di dati con il server, così che l'intera pagina web non debba essere ricaricata ogni volta che l'utente effettua una modifica.

In realta' Javascript, che e' un linguaggio interpretato in run-time, non ha capacita' di multithreading come linguaggio di scripting/programmazione all'interno di un browser, ed anzi e' molto rigido e perfino oscuro a volte sui meccanismi interni di gestione temporale dell'esecuzione delle sue istruzioni.

In piu', non dovendo ricaricare la pagina completa ad ogni fase di interazione con il web server, come avveniva nelle applicazioni tradizionali, si riesce facilmente a mantenere lo stato delle variabili in gioco nel DOM di un documento visualizzato quanto si vuole. Ovvero fino alla dimissione di quel documento e al caricamento di un'altra pagina.

In sostanza Ajax e' questo. Un nuovo approccio nella realizzazione di applicazioni web. Puo' intervenire anche l'XML, come metodo per l'interscambio dei pacchetti dati asincroni con il server, come menzionato nell'acronimo iniziale, ma vedremo successivamente che alla fine l'uso dell' XML e' piuttosto inusuale nelle applicazioni complesse, preferendo l'utilizzo di altre tecnologie/metodologie pu' facilmente manipolabili da parte del Javascript.

Come si puo' facilmente intuire poi, l'utilizzo di Javascript assume ora un ruolo assolutamente predominante, anche rispetto all' html, mentre prima aveva sicuramente marginale, limitato solo a determinate operazioni limitate all'interno del documento visualizzato.

Adesso Javascript e' lo strumento principale per gestire tutte le interazioni tra utente ed interfaccia grafica visualizzata sul browser, e per la gestione di tutte le richieste asincrone di scambio dati con il server, che puo' avvenire in entrambe le direzioni, e della gestione delle eventuali risposte che ci si aspetta dal web server.