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.