Progettazione e sviluppo di interfacce web 2 -...

POLITECNICO DI TORINO

Facolta di Ingegneria dell’InformazioneCorso di Laurea in Ingegneria Informatica

Tesi di Laurea Magistrale

Progettazione e sviluppo diinterfacce web 2.0

Un caso di studio: ricerca brevettuale

Relatore:prof. Fulvio Corno

Candidato:Davide Manganaro

Aprile 2007

Ringraziamenti

Alla fine di questo percorso di studi, desidero ringraziare tutti coloro che hannocontribuito, con i loro consigli, allo svolgimento di questo lavoro di tesi, rendendopossibile la realizzazione del progetto trattato nella tesi e permettendomi il raggiun-gimento di un traguardo importante quale la laurea. La speranza e che questo lavorodi tesi possa essere utile non soltanto a me stesso.

Il ringraziamento piu speciale va ai miei genitori e a mio fratello, i quali mi hannosostenuto e incoraggiato in ogni modo durante il faticoso cammino universitario,avendo sempre fiducia nelle mie scelte.

1

Indice

Ringraziamenti I

1 Introduzione 11.1 Obiettivi della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivazioni della revisione della GUI di IntelliPatent . . . . . . . . . 21.3 Requisiti generali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Introduzione al Web 2.0 92.1 Che cos’e il Web 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Analisi storica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Differenze e confronti con il Web 1.0 . . . . . . . . . . . . . . . . . . 112.4 Applicazioni di nuova generazione . . . . . . . . . . . . . . . . . . . . 15

3 Interfacce utente grafiche per il web 173.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Cenni sulle tecnologie usate per le GUI . . . . . . . . . . . . . . . . . 183.3 Caratteristiche delle GUI nelle applicazioni web . . . . . . . . . . . . 20

3.3.1 Eterogeneita delle esperienze degli utenti . . . . . . . . . . . . 203.3.2 Garanzia di funzionalita . . . . . . . . . . . . . . . . . . . . . 203.3.3 Nuovi strumenti offerti per il web . . . . . . . . . . . . . . . . 21

3.4 Effetti delle GUI sullo sviluppo di un’applicazione . . . . . . . . . . . 223.4.1 Bilanciamento delle operazioni . . . . . . . . . . . . . . . . . . 223.4.2 Universalita dell’interfaccia . . . . . . . . . . . . . . . . . . . . 243.4.3 Universalita degli script . . . . . . . . . . . . . . . . . . . . . 25

3.5 I requisiti emergenti dell’usabilita del web . . . . . . . . . . . . . . . 25

4 Le tecnologie AJAX 274.1 Introduzione: che cos’e AJAX e come si colloca nel web . . . . . . . . 274.2 Descrizione tecnica e teorica . . . . . . . . . . . . . . . . . . . . . . . 28

2

4.3 Introduzione ai fondamenti di AJAX . . . . . . . . . . . . . . . . . . 314.4 OpenAjax Alliance e framework AJAX . . . . . . . . . . . . . . . . . 34

4.4.1 Architettura client-side e server side . . . . . . . . . . . . . . . 344.4.2 Framework lato client procedurali e dichiarativi . . . . . . . . 36

4.5 Considerazioni lato utente . . . . . . . . . . . . . . . . . . . . . . . . 374.5.1 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.5.2 Svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.6 Considerazioni lato server . . . . . . . . . . . . . . . . . . . . . . . . 394.6.1 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.6.2 Svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.7 Problematiche relative al tempo di attesa . . . . . . . . . . . . . . . . 404.7.1 Perdita di una richiesta . . . . . . . . . . . . . . . . . . . . . . 404.7.2 Gestione dell’attesa . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Rich Internet Application mediante OpenLaszlo 435.1 Introduzione: che cos’e OpenLaszlo . . . . . . . . . . . . . . . . . . . 435.2 Architettura client e server . . . . . . . . . . . . . . . . . . . . . . . . 435.3 Architettura del server OpenLaszlo . . . . . . . . . . . . . . . . . . . 455.4 Architettura del client OpenLaszlo . . . . . . . . . . . . . . . . . . . 475.5 Messa in linea di un’applicazione . . . . . . . . . . . . . . . . . . . . 495.6 Richiesta di un’applicazione LZX . . . . . . . . . . . . . . . . . . . . 505.7 Caratteristiche supportate dalla piattaforma . . . . . . . . . . . . . . 50

5.7.1 Modello di Sicurezza . . . . . . . . . . . . . . . . . . . . . . . 505.7.2 Supporto della piattaforma per dispositivi differenti . . . . . . 505.7.3 Accessibilita . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.8 Il Linguaggio LZX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 Caso di studio: GUI di IntelliPatent 4.0 636.1 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2 Scelta delle tecnologie . . . . . . . . . . . . . . . . . . . . . . . . . . 646.3 Progettazione: implementazione mediante OpenLaszlo . . . . . . . . . 666.4 Valutazione dei risultati raggiunti . . . . . . . . . . . . . . . . . . . . 86

7 Conclusioni 94

Bibliografia 97

3

Elenco delle tabelle

1.1 Funzionalita principali dell’applicativo IntelliPatent 3.5 . . . . . . . . 22.1 Esempi di applicativi del Web 2.0 . . . . . . . . . . . . . . . . . . . . 123.1 Alcuni toolkit e framework di sviluppo che integrano il supporto del

progetto OpenAjax Hub . . . . . . . . . . . . . . . . . . . . . . . . . 226.1 Organizzazione delle pagine della GUI . . . . . . . . . . . . . . . . . 676.2 Requisiti di usabilita e risultati ottenuti . . . . . . . . . . . . . . . . . 916.3 Requisiti di accessibilita e risultati ottenuti . . . . . . . . . . . . . . . 926.4 Requisiti di funzionalita e risultati ottenuti . . . . . . . . . . . . . . . 926.5 Problematiche riscontrate con OpenLaszlo . . . . . . . . . . . . . . . 93

4

Elenco delle figure

1.1 Finestra di ricerca di IntelliPatent 3.5 . . . . . . . . . . . . . . . . . . 31.2 Finestra con la tabella dei risultati di IntelliPatent 3.5 . . . . . . . . 41.3 Caricamento delle informazioni brevettuali con IntelliPatent 4.0 . . . 61.4 Confronto dei brevetti con IntelliPatent 4.0 . . . . . . . . . . . . . . . 72.1 Immagine rappresentante le caratteristiche del Web 2.0 . . . . . . . . 92.2 Evoluzione tecnologica e sociale del Web . . . . . . . . . . . . . . . . 102.3 L’elaboratore di testi IucundeWeb (in secondo piano) e il foglio elet-

tronico NumSum (in primo piano) . . . . . . . . . . . . . . . . . . . 132.4 L’applicativo Gliffy, strumento per disegnare vari tipi di flow-chart . . 142.5 Schermate di Blogger . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1 Architettura three-tier o 3-tier (“a tre strati”) . . . . . . . . . . . . . 233.2 Confronto tra l’architettura web a 3 strati (a) e quella a 4 strati (b) . 244.1 Confronto tra il modello di interazione tradizionale delle applicazioni

web e il modello AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Confronto tra l’interazione sincrona client-server e quella asincrona

(AJAX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Modello di trasformazione AJAX lato utente . . . . . . . . . . . . . . 354.4 Modello di trasformazione AJAX lato server . . . . . . . . . . . . . . 364.5 Carico del server con e senza AJAX . . . . . . . . . . . . . . . . . . . 394.6 Rappresentazione di piu richieste ad un server con latenza e risposte . 404.7 Indicatori di attesa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.1 Architettura client-server OpenLaszlo . . . . . . . . . . . . . . . . . . 445.2 Architettura del server OpenLaszlo . . . . . . . . . . . . . . . . . . . 455.3 Architettura del client OpenLaszlo . . . . . . . . . . . . . . . . . . . 475.4 Interazione fra client e server OpenLaszlo . . . . . . . . . . . . . . . . 515.5 Tabella mediante codice LZX . . . . . . . . . . . . . . . . . . . . . . 545.6 Finestre e tooltip in OpenLaszlo . . . . . . . . . . . . . . . . . . . . . 565.7 Esempio di utilizzo di web service mediante codice LZX . . . . . . . . 585.8 Risoluzione 1024 x 768 (sinistra) a confronto con 1280x1024 (destra) . 615.9 Finestra del browser ridimensionata (sinistra) e successivamente al-

largata (destra) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5

6.1 Confronto tra lo stack DHTML e quello di OpenLaszlo . . . . . . . . 656.2 Diagramma di interazione dell’utente con la GUI di IntelliPatent 4.0 . 676.3 Gestione del login e del logout . . . . . . . . . . . . . . . . . . . . . . 716.4 Diagramma di gestione degli accessi non autenticati . . . . . . . . . . 726.5 Meccanismo di gestione degli accessi non autenticati . . . . . . . . . . 746.6 Meccanismo per gestire la chiusura automatica della sessione . . . . . 756.7 Meccanismo per gestire la chiusura automatica della sessione: caso di

perdita del segnale lato client . . . . . . . . . . . . . . . . . . . . . . 766.8 Meccanismo per gestire la chiusura automatica della sessione: caso di

perdita del segnale lato server . . . . . . . . . . . . . . . . . . . . . . 776.9 Flow-chart per il caricamento dei brevetti . . . . . . . . . . . . . . . . 806.10 Caricamento dei brevetti riga per riga . . . . . . . . . . . . . . . . . . 816.11 Meccanismo per la visualizzazione di un file XML . . . . . . . . . . . 836.12 Meccanismo per il salvataggio dei file . . . . . . . . . . . . . . . . . . 866.13 IntelliPatent 4.0: finestra di LOGIN . . . . . . . . . . . . . . . . . . . 876.14 IntelliPatent 4.0: finestra di SEARCH . . . . . . . . . . . . . . . . . . 876.15 IntelliPatent 4.0: finestra per la gestione degli ALERT . . . . . . . . 886.16 IntelliPatent 4.0: prima tabella con i risultati . . . . . . . . . . . . . 896.17 IntelliPatent 4.0: seconda tabella con i risultati aggiuntivi . . . . . . 90

6

Capitolo 1

Introduzione

1.1 Obiettivi della tesi

L’attuale sviluppo delle applicazioni B2B 1 distribuite richiede che esse risultino facilida progettare, da mantenere e da usare.

I primi due obiettivi possono essere colti disaccoppiando opportunamente l’inter-faccia utente grafica (GUI) dal resto del sistema e utilizzando soluzioni architetturaliquali AJAX e OpenLaszlo. L’ultimo obiettivo, invece, implica di seguire ben spe-cifiche guideline e best-practice, come indicato dal consorzio W3C, per ottimizzarel’usabilita e per adattarsi in modo semplice alle differenti capacita dello schermo adisposizione dell’utente. Quest’ultimo requisito viene anche definito con il terminedi “interfaccia liquida”.

Nella prima fase dello svolgimento della tesi, pertanto, ho effettuato lo studiodello stato dell’arte ed ho effettuato sperimentazioni e valutazioni relative a tutti ipunti precedentemente enunciati. In particolare, ho preso in esame lo studio delletecnologie emergenti AJAX e OpenLaszlo caratterizzanti la nascita del Web 2.0 eche permettono lo sviluppo delle cosiddette Rich Internet Application (RIA), ovve-ro applicazioni web che hanno le caratteristiche e le funzionalita delle tradizionaliapplicazioni desktop.

Nella seconda fase della tesi, ho proceduto applicando il know-how maturatoalla revisione dell’architettura e dell’implementazione dell’interfaccia utente graficadi IntelliPatent 3.5 presso l’azienda IntelliSemantic.

IntelliSemantic e una societa dell’incubatore I3P che opera nelle applicazioni diaccesso ad informazioni tecnologiche e di mercato utilizzanti la tecnologia semantica

1Business to Business, spesso abbreviato in B2B, indica le relazioni che un’impresa detienecon i propri fornitori per attivita di approvvigionamento, di pianificazione e monitoraggio dellaproduzione o di sussidio nelle attivita di sviluppo prodotto oppure le relazioni che l’impresa detienecon clienti professionali, cioe altre imprese collocate in punti diversi della filiera produttiva.

1

1 – Introduzione

e che ha stabilito una collaborazione con il gruppo di ricerca e-lite del Politecnicodi Torino.

IntelliPatent e un’applicazione web che facilita l’accesso e la manipolazione delleinformazioni fornite dalla base dati dell’European Patent Office (EPO) relative aibrevetti ed e stata sviluppata da IntelliSemantic come servizio ASP 2.

1.2 Motivazioni della revisione della GUI di Intelli-

Patent

Un’interfaccia utente grafica, come quella di IntelliPatent 3.5, assume un ruolo fon-damentale in un sistema software, in quanto mediante essa un utente si relaziona colsistema stesso per reperire informazioni e servizi. Le funzionalita principali, presentinell’applicativo IntelliPatent 3.5, sono riepilogate nella tabella 1.1.

Item Funzionalita1 Modalita di ricerca interattiva e in tempo differito2 Segnalazione automatica per e-mail di nuovi brevetti3 Ricerca completa di tutte le informazioni riguardanti i brevetti4 Memorizzazione del profilo di interesse e del profilo d’uso

dell’utente5 Funzioni di filtro e ordinamento sulla tabella dei risultati

individuati6 Visualizzazione e salvataggio delle informazioni ricercate nel

formato XML

Tabella 1.1. Funzionalita principali dell’applicativo IntelliPatent 3.5

In base alla tipologia di servizio offerto e all’utenza che si rivolge, un’interfac-cia deve, quindi, soddisfare determinati requisiti di usabilita, di accessibilita e difunzionalita.

Analisi sull’usabilita

Utilizzando l’applicativo IntelliPatent 3.5, dopo un’autenticazione mediante login,l’utente si trova di fronte ad un form di ricerca mostrato in figura 1.1.

2Application Service Provider (ASP) e un operatore che fornisce ai propri utenti serviziapplicativi tramite Internet su linea privata virtuale o su linea pubblica.

2

1.2 – Motivazioni della revisione della GUI di IntelliPatent

Figura 1.1. Finestra di ricerca di IntelliPatent 3.5

L’interazione dell’utente con l’applicazione avviene come una tradizionale paginaHTML sincrona, cioe ad ogni azione l’utente si trova davanti una finestra browservuota e un’icona a clessidra, aspettando che il server finisca l’elaborazione e resti-tuisca tutta la pagina per intero. E un modello adattato dall’uso originale del webcome un medio ipertesto, ma cio che rende il web adatto per l’ipertesto non lo rendenecessariamente adatto alle applicazioni software.

Il secondo ed inevitabile incomodo legato a questo meccanismo tradizionale el’attesa che trascorre tra una richiesta dell’ utente e la risposta del server. Data lanatura sincrona, la tabella con i brevetti ricercati puo essere restituita solo quando ilserver ha completato tutta la ricerca. Cosı, l’utente e costretto ad aspettare parecchiminuti prima di poter consultare ed elaborare le informazioni brevettuali.

3

1 – Introduzione

La figura 1.2 mostra il risultato di una ricerca brevettuale e come le varieinformazioni sono organizzate in tabella.

Figura 1.2. Finestra con la tabella dei risultati di IntelliPatent 3.5

Si puo notare come tali informazioni siano parecchie e la tabella risulti enormecon svariate colonne. Inoltre, la consultazione mediante l’uso della barra di scrollingorizzontale non risulta molto agevole come soluzione.

Analisi sull’accessibilita

L’utenza, per la quale e rivolto IntelliPatent, e costituita da studi brevettuali eda aziende di vari settori che intendano valutare le evoluzioni tecnologiche del lorosettore. Assume molta importanza che l’applicativo web sia supportato da varisistemi operativi e browser. Questa caratteristica viene, in molti casi, supportatada IntelliPatent 3.5, ma l’utilizzo di codice cross-browser agevolerebbe lo sviluppodel software da parte del programmatore che non si troverebbe a dover differenziareparti di codice in base ai vari ambienti in cui l’applicativo verrebbe utilizzato. Cioconsentirebbe una riduzione dei tempi di sviluppo, di testing e di manutenzione.

Per il momento non esistono altre particolari esigenze di accessibilita, caratteri-stica che in ogni caso rappresenterebbe un valore aggiunto.

4

1.3 – Requisiti generali

Analisi sulle funzionalita

Una tipica applicazione web viene di solito realizzata disaccoppiando la parte relativaall’interfaccia grafica dalla parte riguardante l’elaborazione dei dati che di solitorisiede sul server. In tale maniera diviene semplice effettuare cambiamenti alle varieparti del sistema software, in quanto indipendenti fra di loro. L’implementazionedella versione 3.5 di IntelliPatent non presenta una suddivisione netta dei vari modulidel sistema. Il disaccoppiamento dell’interfaccia dal resto del sistema permette anchedi alleggerire il server da alcune funzionalita che vengono date in gestione al browser,consentendo cosı di migliorare la scalabilta del sistema, ovvero la gestione di unnumero piu elevato di utenti che accedono simultaneamente.

1.3 Requisiti generali

I requisiti generali di un applicativo web di ricerca brevettuale, quale IntelliPatent,sono i seguenti:

• completezza: un unico ambiente di lavoro che raccoglie tutte le informazionirelative ai brevetti. Questa caratteristica agevolerebbe il lavoro dell’utenteche altrimenti sarebbe costretto a reperire le varie informazioni relative ad unbrevetto da piu fonti diverse, dovendo effettuare cosı piu ricerche.

• Velocita e interattivita. La ricerca di brevetti con determinate caratteristi-che spesso porta a trovare una grossa quantita di informazioni con conseguentitempi di attesa lunghi. Un programma che consente di visualizzare le informa-zioni man mano che vengono trovate, rende tali tempi accettabili e miglioracosı l’interazione con l’utente.

• Usabilita. Caratteristiche fondamentali di un’interfaccia sono la semplicitad’uso e la chiarezza delle varie funzionalita che si possono adoperare. Oltreall’intuitivita dell’applicativo, data la grossa quantita di dati che spesso sideve trattare, si rende necessaria una presentazione su schermo in una formacomoda per la visualizzazione, la consultazione e il confronto delle informazioniricercate.

• Accessibilita Web. Possibilita di fruire delle informazioni presenti nellepagine da parte del maggior numero possibile di persone, indipendentementedalle disabilita psico-fisiche e dalle dotazioni hardware e software disponibili.

5

1 – Introduzione

1.4 Risultati ottenuti

Si e sviluppata la versione 4.0 della GUI di IntelliPatent mediante la tecnologiaOpenLaszlo su ambiente runtime Flash. L’applicativo web realizzato e mostrato infigura 1.3 e presenta tutte le funzionalita della versione precedente, oltre ad ulteriorirequisiti raggiunti.

Figura 1.3. Caricamento delle informazioni brevettuali con IntelliPatent 4.0

Le peculiarita della nuova interfaccia sono le seguenti:

• miglioramenti degli aspetti di portabilita e accessibilita, dovuti alla disponibi-lita del plugin Flash per dispositivi, sistemi operativi e browser differenti;

• passaggio immediato dal modulo di ricerca alla tabella dei risultati e popola-mento di una riga alla volta della tabella man mano che vengono trovati i varibrevetti;

• consultazione e soprattutto interazione immediata con le informazioni bre-vettuali ricercate grazie al meccanismo asincrono di interazione tra client eserver;

• tabella compatta e organizzata in maniera tale da rendere piu agevole laconsultazione;

6

1.5 – Struttura della tesi

• la presenza della barra di scrolling verticale sulla tabella anziche solo sullapagina, permette all’utente di avere sempre sotto controllo tutte le funzionalitadell’interfaccia;

• possibilita di confrontare brevetti aprendo piu finestre contemporaneamentecome mostra la figura 1.4.

Figura 1.4. Confronto dei brevetti con IntelliPatent 4.0

1.5 Struttura della tesi

• Capitolo 2 - Introduzione al Web 2.0. Viene presentata un’analisi storicasull’evoluzione che ha subito il web dal punto di vista degli aspetti sociali, masoprattutto dal punto di vista tecnologico.

• Capitolo 3 - Interfacce utente grafiche per il web. Si effettua il puntodello stato dell’arte e si analizza l’architettura della GUI sia sotto l’aspettotecnologico, sia sotto l’aspetto dell’accessibilita e dell’usabilita.

• Capitolo 4 - Le tecnologie AJAX. Viene affrontato lo studio della tecnicaAJAX per la realizzazione di siti e applicativi web, fornendo un’analisi sugliaspetti positivi e negativi introdotti dal suo utilizzo.

7

1 – Introduzione

• Capitolo 5 - Rich Internet Application mediante OpenLaszlo. Sianalizza questa tecnologia open per creare RIA (Rich Internet Application).

• Capitolo 6 - Caso di studio: GUI di IntelliPatent 4.0. Viene applicatoil know-how maturato alla revisione dell’architettura e dell’implementazionedell’interfaccia utente grafica di IntelliPatent.

• Capitolo 7 - Conclusioni. Si effettuano delle valutazioni sui vari argomentitrattati e si traggono delle conclusioni sul lavoro sviluppato.

8

Capitolo 2

Introduzione al Web 2.0

2.1 Che cos’e il Web 2.0

Con il nome Web 2.0 o Internet 2.0 si intende un generico stato di evoluzione diInternet e in particolare del World Wide Web.

Figura 2.1. Immagine rappresentante le caratteristiche del Web 2.0

Alcuni hanno tentato di definire il Web 2.0 come una serie di siti web con in-terfaccia, facilita e velocita d’uso tali da renderli simili alle applicazioni tradizionaliche gli utenti sono abituati a installare nei propri computer.

Spesso vengono usate tecnologie di programmazione particolari, come AJAX(argomento trattato al capitolo 4 di questa tesi). Gmail usa largamente questatecnica per essere semplice e veloce.

I propositori del termine Web 2.0 affermano che questo differisce dal concettoiniziale di web, retroattivamente etichettato Web 1.0, perche si discosta dai classici

9

2 – Introduzione al Web 2.0

siti web statici, dall’e-mail, dall’uso dei motori di ricerca, dalla navigazione linearee propone un World Wide Web piu dinamico e interattivo.

Gli scettici replicano che il termine Web 2.0 non ha un vero e proprio significato,in quanto questo dipende esclusivamente da cio che i propositori decidono che debbasignificare per cercare di convincere i media e gli investitori che stanno creandoqualcosa di nuovo e migliore, invece di continuare a sviluppare le tecnologie esistenti.

2.2 Analisi storica

Originariamente il web e stato concepito come modo per visualizzare documentiipertestuali statici (creati con l’uso del linguaggio HTML). Questo approccio puoessere definito come Web 1.0.

In seguito, grazie all’integrazione con database e all’utilizzo di sistemi di gestionedei contenuti (CMS), Internet si e evoluta con siti dinamici (come ad esempio i forumo i blog). Questo web dinamico e stato da alcuni definito Web 1.5.

Le tappe fondamentali del mondo Internet vengono mostrate in figura 2.2.

Figura 2.2. Evoluzione tecnologica e sociale del Web

Attraverso l’utilizzo di linguaggi di programmazione come JavaScript, degli ele-menti dinamici e dei fogli di stile (CSS) per gli aspetti grafici, si possono creare dellevere e proprie “applicazioni web” che si discostano dal vecchio concetto di sempliceipertesto e che puntano a somigliare ad applicazioni tradizionali per computer.

Da un punto di vista strettamente tecnologico, il Web 2.0 e del tutto equivalenteal Web 1.0, in quanto l’infrastruttura di rete continua ad essere costituita da TCP/IPe HTTP e il meccanismo ipertestuale e ancora il concetto base delle relazioni tra icontenuti. La differenza, piu che altro, sta nell’approccio con il quale gli utenti sirivolgono al web, che passa fondamentalmente dalla semplice consultazione (seppuresupportata da efficienti strumenti di ricerca, selezione e aggregazione) alla possibilitadi contribuire popolando e alimentando il web con propri contenuti.

10

2.3 – Differenze e confronti con il Web 1.0

2.3 Differenze e confronti con il Web 1.0

Spesso appare comodo, nel descrivere le caratteristiche del Web 2.0, procedere perconfronto con il Web 1.0, indicando come nel passaggio di versione gli elementifondamentali si sono evoluti o sono stati sostituiti da nuovi. Si tratta, ovviamente,di un modo di rappresentare il Web 2.0 divulgativo e non prettamente tecnico, marisulta abbastanza efficace per riconoscere su Internet le “tracce” dell’una o dell’altraversione.

Dai siti web personali ai blog

Se prima la costruzione di un sito web personale richiedeva la padronanza di ele-menti di HTML e programmazione, oggi con i blog chiunque e in grado di esporrei propri contenuti dinamici dotati anche di veste grafica accattivante senza nessunaconoscenza tecnica particolare. Se prima le community web erano in stragrandemaggioranza costituite da esperti di informatici, oggi la situazione e completamenteribaltata. A farla da padroni sui blog sono scrittori, giornalisti, artisti o comunque“animi sensibili” con una preparazione informatica non necessariamente elevata.

Dai sistemi per content management ai wiki

La tecnologia Wiki (Wikipedia ne e la piu celebre applicazione) e il punto di arrivodel content management, in quanto ne implementa tutti i paradigmi. Se prima eranonecessarie piu applicazioni informatiche per la gestione del ciclo di vita dell’informa-zione (dall’intuizione alla fruizione), oggi una stessa tecnologia supporta al megliotutto il processo. Si fruisce dell’informazione nell’ambiente stesso in cui essa e nata.

Dalla stickiness al syndication

Le tecniche utilizzate fino a ieri per tenere piu tempo possibile i visitatori su un sitoweb (stickiness, letteralmente l’“appiccicosita” di un sito, cioe la capacita di tenere“incollati” gli utenti ad esso) stanno lasciando il posto ad altre concezioni di contattocon il fruitore. Attraverso le tecnologie di syndication (RSS, Atom, Tagging) chirealizza contenuti fa in modo che questi possano essere fruiti non solo sul sito, maanche attraverso canali diversi. Un esempio di questi nuovi canali sono i feed, cioedelle liste di elementi con un titolo (e.g. notizie di un giornale e thread di un news-group), che permettono il successivo collegamento ai contenuti informativi. Questiultimi possono essere aggiornati e consultati di frequente con programmi appositi oanche attraverso i browser e, quindi, consentono di essere sempre a conoscenza deinuovi contenuti inseriti su un sito senza doverlo visitare direttamente.

11


Strumenti per la creazione di contenuti

Tale possibilita di creazione e condivisione di contenuti su web, tipica del Web 2.0, edata da una serie di strumenti (tool in inglese) on-line che permettono di utilizzareil web come se si trattasse di una normale applicazione. In pratica il web di secondagenerazione e un web dove poter trovare quei servizi che finora erano offerti dapacchetti da installare sui singoli computer.

Esempi di applicativi del Web 2.0 sono rappresentati nella tabella 2.1, mentre lefigure 2.3 e 2.4 mostrano alcune schermate.

Nome Descrizione IndirizzoIucundeWeb elaboratore di testi http://www.iucundeweb.com/

FCKEditor elaboratore di testi http://www.fckeditor.net/

Writely elaboratore di testi docs.google.com/

NumSum sorta di foglio elettronico http://numsum.com/

Gliffy strumento per disegnareflow-chart e vari schemi

http://www.gliffy.com/

Tabella 2.1. Esempi di applicativi del Web 2.0

Oltre alla creazione condivisa di contenuto on-line, il Web 2.0 e caratterizza-to dalla pubblicazione immediata del contenuto e alla sua classificazione e indi-cizzazione nei motori di ricerca, in modo che l’informazione sia subito disponibi-le a beneficio dalla comunita, realizzando in maniera veloce il ciclo di vita delcontent management. Per la pubblicazione dei contenuti fanno da padrone sulweb di oggi i provider di blog come Blogger (http://www.blogger.com/), il qualeviene mostrato nella figura 2.5, Wordpress (http://wordpress.org/) e Splinder(http://www.splinder.com/), ma anche piattaforme commerciali come MicrosoftSharepoint Portal che nella prossima versione (3.0) accentuera le sue caratteristichedi collaborazione diventando la parte server di Office 12.

12

2.3 – Differenze e confronti con il Web 1.0

Figura 2.3. L’elaboratore di testi IucundeWeb (in secondo piano) e il foglio elet-tronico NumSum (in primo piano)

13


Figura 2.4. L’applicativo Gliffy, strumento per disegnare vari tipi di flow-chart

Figura 2.5. Schermate di Blogger

14

2.4 – Applicazioni di nuova generazione

2.4 Applicazioni di nuova generazione

L’introduzione della tecnica AJAX ha reso possibile l’evoluzione del Web, non so-lo dal punto di vista sociale, ma anche sotto quello tecnologico, permettendo lacreazione di applicazioni e servizi di nuova generazione. Il capitolo 4 approfondiscel’argomento relativo alle tecnologie AJAX.

Rich Internet Application (RIA)

Le Rich Internet Application (RIA) sono applicazioni web che hanno le caratte-ristiche e le funzionalita delle tradizionali applicazioni desktop (cioe residenti sulcomputer). Nelle RIA tipicamente e trasferita a livello client la parte dell’applica-zione che processa i dati e fornisce una pronta risposta all’interfaccia utente, mentrela gran parte dei dati e dell’applicazione rimane sul server.

Tipicamente le RIA girano in un comune web browser e non richiedono alcunainstallazione.

In un certo senso le RIA rappresentano una generazione di applicazioni che per-mette una “user experience” totalmente rinnovata, fondata sul meglio delle carat-teristiche funzionali e progettuali che finora erano prerogativa alternata del web odelle applicazioni desktop.

Adobe Flex si sta recentemente (2006) affermando quale principale piattaformatecnologica per la realizzazione di RIA.

Mashup, dashboard ed altre applicazioni composite

La tecnica AJAX permette di miscelare ed associare componenti multiple in una solaapplicazione. Cio permette agli sviluppatori AJAX di creare vari tipi di applicazionicomposite sfruttando le tecnologie fornite da vari provider.

• Mashup - Un mashup e un sito o un’applicazione web che utilizza contenutiprovenenti da piu di una fonte per creare un servizio completamente nuovo.Un esempio concreto e un’applicazione che fornisce mappe geografiche, checomunica (mediante XML) con il server di un’azienda richiedendo l’indirizzoe, quindi, il servizio di mappe (e.g. Google o Yahoo!) fornisce in risposta unamappa da visualizzare all’interno degli altri contenuti dell’applicazione. Spes-so, i mashup rendono possibile uno sviluppo rapido di applicazioni integrandocomponenti di terze parti pronti all’uso.

• Portali e dashboard - Sono composti da vari pannelli che, spesso, possonoessere configurati dall’utente. Inoltre, ogni pannello puo essere un’applicazioneseparata. Le tecnologie AJAX possono essere utilizzate per gestire sia l’interaapplicazione sia le singole sotto-applicazioni in essa integrate.

15


• Composizione di servizi - In ambiente SOA (architetture service-oriented),applicazioni commerciali composte assemblano molteplici servizi per crearenuove funzionalita che supportano un innovativo processo commerciale. Inalcuni casi, i servizi dai quali la nuova applicazione viene realizzata non hannointerfacce utente, quindi l’applicazione composta e la sola interfaccia utentedisponibile. In altri casi, i servizi che vengono aggregati hanno gia una lorointerfaccia grafica, quindi l’applicazione composita non deve soltanto aggregarei servizi offerti, ma anche le varie interfacce utente.

Collaborazione

AJAX rende disponibili applicazioni collaborative quali:

• Instant messaging (IM) e chat di nuova generazione - AJAX rendedisponibile lo scambio di messaggi attraverso applicazioni web che vengonoeseguite in un comune browser.

• Web meeting e whiteboarding - Le ricche funzionalita delle interfacceutente AJAX, la programmazione di rete e la grafica vettoriale fornisconol’infrastruttura per applicazioni browser per net-meeting e lavagne condivise(whiteboards).

• Creazione collaborativa di contenuto - Le applicazioni web collaborativecome i wiki possono evolvere dall’attuale condizione in cui gli utenti devonoimparare un linguaggio di markup tipico dei wiki a un’interfaccia utente gra-fica WYSIWYG (What You See Is What You Get), simile all’utilizzo delleapplicazioni desktop per la creazione di contenuti.

• Pianificazione - Un gruppo di persone puo utilizzare un’applicazione svilup-pata con AJAX per lavorare insieme e pianificare le proprie attivita.

• Condivisione di foto - AJAX permette una nuova forma di condivisione,che permette di aggiungere commenti, tag o contrassegnare una foto.

16

Capitolo 3

Interfacce utente grafiche per ilweb

3.1 Introduzione

L’interfaccia utente ha subito, nel corso degli anni, modifiche profonde che han-no cambiato anche il modo di concepire lo sviluppo stesso delle applicazioni suqualunque piattaforma. La crescita delle applicazioni per Internet fanno pensareche l’evoluzione delle GUI sia lungi dall’essere terminata. In particolare, l’affer-mazione di nuove concezioni e tecniche per il web comportano la nascita di nuovitipi d’interfaccia per soddisfare le esigenze degli utenti, come discusso nel capitoloprecedente.

Negli ultimi anni, l’interfaccia utente ha assunto un ruolo sempre piu incisivonello sviluppo di applicazioni, e si riscontra sempre piu spesso, anche nelle piccolerealta produttive, una maggiore attenzione e importanza al disegno della GUI eall’impatto che l’utente puo avere con essa.

L’evoluzione delle applicazioni accessibili attraverso Internet mostra che, versola meta degli anni ’90, esse erano di tipo “Information retrieval”, con un’interfacciamolto scarna che permetteva solo l’inserimento dei parametri per la ricerca dei dati.Oggi, quest’interfaccia sopravvive solo nei motori di ricerca ed in piccole applicazioniper siti web. In seguito, grazie anche allo sviluppo del concetto di Internet, compar-vero due tecnologie parallele, ovvero ActiveX ed Applet Java, volte ad arricchire leinterfacce visibili all’interno dei browser. Nonostante le potenzialita da esse offerte,non hanno mai avuto il successo sperato, tanto che sono state di fatto sostituite daaltre due nuove tecnologie, ovvero Dynamic HTML ed XML, piu vicine allo spiritooriginale del linguaggio HTML.

Queste ultime, unite allo sviluppo di applicazioni server sempre piu potenti eraffinate, hanno radicalmente modificato il modo di progettare le applicazioni web.

17

3 – Interfacce utente grafiche per il web

Cio che ci si aspetta dal web di oggi e di vedere delle GUI efficienti, funzionali epratiche sia in rapporto allo sviluppo delle applicazioni sia nei confronti dell’utente.

3.2 Cenni sulle tecnologie usate per le GUI

Di seguito vengono illustrati gli aspetti fondamentali dei linguaggi e delle tecnologieusate per creare GUI all’interno di un browser.

HTML

HTML e tuttora il linguaggio per eccellenza del mondo Internet. Il suo pregioprincipale consiste nella standardizzazione che, se rigorosamente seguita dagli svi-luppatori, ne permette la lettura da parte di tutti i browser attualmente disponibili.D’altra parte, il linguaggio HTML e statico e offre un basso numero di oggetti perla manipolazione dei dati. A causa di cio, l’utente non ha a disposizione alcuni stru-menti ai quali e abituato, come le barre degli strumenti (toolbar), i menu standard ocon effetto pop-up, eccetera. Inoltre, la mancanza di componenti legati ai campi deldatabase implica che le tecniche di programmazione abituali degli ambienti RAD(Rapid Application Development) devono essere modificate, per fornire alle paginebasate sul linguaggio HTML la possibilita di mostrare i dati richiesti.

Applet Java

Java e il linguaggio che maggiormente si e imposto all’attenzione del mondo Internet.Grazie alla possibilita di creare applet, esso e uno strumento privilegiato per superarele limitazioni, accennate in precedenza, del linguaggio HTML. Il linguaggio Javadispone di una grande quantita di oggetti ed essendo standardizzato avrebbe lecaratteristiche per poter diventare un linguaggio veramente universale. A questolivello, tuttavia, e difficile realizzare una connessione ad un database in manieraefficiente ed indipendente dal browser e la velocita di esecuzione degli applet e unaltro punto negativo tuttora insuperato.

ActiveX

La tecnologia ActiveX, proposta da Microsoft, e un tentativo in parte riuscito diavvicinare l’interfaccia del mondo Internet a quella dei programmi per Windows,allo scopo di rendere uniformi gli ambienti applicativi e di sfruttare il massimopossibile delle conoscenze acquisite dagli utenti. Inoltre, puo sfruttare una libreriadi componenti gia esistenti o di facile implementazione. Tale libreria ha il vantaggiodi essere praticamente illimitata. Si tratta, pero, di una tecnologia di proprieta

18

3.2 – Cenni sulle tecnologie usate per le GUI

privata, che dipende fortemente dal sistema operativo e dal browser. Non esiste unastandardizzazione, per cui gli utenti sono vincolati alle decisioni del produttore.

DHTML e XML

L’esperienza ha mostrato che nessuna delle tecnologie sopra descritte soddisfa piena-mente le esigenze emerse con lo sviluppo di Internet. Il linguaggio HTML, tuttavia,ha rappresentato una solida base su cui sviluppare nuove soluzioni. Le strade seguitesono state due:

• da un lato si e cercato di rendere dinamico il linguaggio HTML (DHTML),associandolo a potenti linguaggi di scripting, permettendo la modifica dei con-tenuti e della posizione dei componenti anche dopo la visualizzazione dellapagina;

• dall’altro, si e proposto un nuovo linguaggio (XML) per la separazione delcontenuto dalla formattazione.

Purtroppo, il linguaggio DHTML e nato al di fuori degli standard ed e difficileconciliare le versioni proposte dai due maggiori produttori di browser. Questo fattone ha impedito fino ad oggi la diffusione auspicata.

Adobe Flash

Adobe Flash, in precedenza chiamato Macromedia Flash e ancora prima FutureSpla-sh, e un software per uso prevalentemente grafico che consente di creare animazionivettoriali principalmente per il web. Viene utilizzato, inoltre, per creare giochi ointeri siti web e grazie all’evoluzione delle ultime versioni e divenuto un potentestrumento per la creazione di Rich Internet Application e piattaforme di streamingaudio/video.

Quando le tecnologie Java applet e DHTML hanno avuto un periodo stagnan-te, la tecnologia Flash ha guadagnato molta notorieta. Ormai, nel mondo Internetil formato Flash (estensione .swf), degli oggetti creati con l’omonimo programma,rappresenta uno standard per la creazione di contenuti animati ed interattivi. Difatto, la quasi totalita dei browser supportano nativamente questo formato che con-sente la visione appunto di animazioni grafiche, cosı come la visione in streaming oin progressive downloading di filmati video.

Questa tecnologia client rimane ancora oggi usata principalmente per giochi ebanner pubblicitari. La principale ragione di questa limitazione e dovuta all’adozionedi una tecnologia che non e open e che muta in continuazione. Inoltre, un ecceso difunzionalita, magari unite ad un’implementazione non ottimizzata, puo comportareun rallentamento del client.

19


3.3 Caratteristiche delle GUI nelle applicazioni

web

L’interfaccia utente di un’applicazione Internet possiede alcune caratteristiche che ladifferenziano fortemente da quelle dei programmi per desktop. Tali caratteristicheed i loro effetti nella progettazione della GUI vengono elencati di seguito.

3.3.1 Eterogeneita delle esperienze degli utenti

Uno dei piu importanti principi della progettazione delle GUI afferma che si devonoconservare le conoscenze acquisite dagli utenti nel corso delle loro esperienze infor-matiche. Cio ha portato alla creazione, per ciascuno dei principali sistemi operativipresenti sul mercato, di modelli per interfacce utente che, adottati dalle piu diverseapplicazioni, garantiscono una certa uniformita d’impiego. Tuttavia, le applicazioniweb spesso si rivolgono ad utenti dei quali non sono note ne le competenze informati-che, ne i sistemi operativi e browser che usano. In questo caso, e dunque impossibilesapere quali competenze conservare. L’introduzione delle tecnologie applet Java edActiveX ha cercato, come detto, di risolvere questo problema trasferendo nel mondoInternet gli stessi oggetti che gli utenti trovano quotidianamente sui propri computer,senza peraltro soddisfare pienamente il pubblico.

E, quindi, necessario cercare l’esperienza minima comune a tutti gli utenti poten-ziali ed e facile rendersi conto che essa consiste nell’uso del browser e della conoscenzadell’ipertestualita. Una GUI per applicazioni Internet dovrebbe, quindi, sfruttarele possibilita offerte, per esempio, dal linguaggio HTML per fornire all’utente lefunzionalita di base, lasciando alle altre tecnologie il compito di svolgere attivitaspecifiche all’interno dell’interfaccia, potenziandola.

3.3.2 Garanzia di funzionalita

E spontaneo chiedersi se con gli oggetti messi a disposizione dal linguaggio HTML siapossibile riprodurre tutte le sofisticate funzionalita offerte dalle GUI per applicazionidesktop. La risposta e negativa, come spiegato in precedenza. Pero, le funziona-lita di base, come la visione e la modifica dei dati, la creazione di statistiche e cosıvia, possono essere garantite se si valorizza il ruolo dell’ipertestualita e si fornisceall’utente un ambiente di lavoro facile, intuitivo e simile a quello sperimentato quo-tidianamente con la navigazione in Internet. Inoltre, aggiungendo la dinamicita dellinguaggio DHTML e unendo le funzioni di varie librerie che sono state sviluppateper tale linguaggio, si riescono a creare interfacce utente che riproducono quelle perdesktop, sia nella grafica (ovvero con tutti gli elementi tradizionali, quali barre deglistrumenti, icone, finestre a comparsa, eccetera), sia nelle funzionalita. Tutto cio,

20

3.3 – Caratteristiche delle GUI nelle applicazioni web

se usato in modo chiaro e coerente, e in grado di soddisfare pienamente le esigenzedegli utenti, indipendentemente dal contesto in cui l’interfaccia viene inserita.

3.3.3 Nuovi strumenti offerti per il web

Con lo scopo di garantire funzionalita, appena discusse, e sorta un’alleanza, “Open-Ajax Alliance”, che ha lanciato un progetto che rendera disponibili librerie AJAXstandard da utilizzare nelle applicazioni Web 2.0.

L’obiettivo principale e di illustrare e diffondere la tecnica AJAX (AsynchronousJavaScript and XML), spiegata al capitolo 4 di questa tesi, accelerando cosı l’av-vento del cosiddetto Web 2.0. A tale scopo, OpenAjax Alliance ha inaugurato unprogetto con il quale spera di risolvere i problemi di interoperabilita del mondo delleapplicazioni Internet.

Il progetto, sostenuto da decine di grossi nomi del settore software come IBM,Oracle, Sun, Adobe e Google, si chiama OpenAjax Hub ed e costituito da uninsieme di funzionalita JavaScript standard progettate per essere snelle e veloci.L’Alleanza sostiene che l’uso di queste funzionalita risolve i molti problemi di in-teroperabilita che oggi sorgono quando si utilizzano piu librerie AJAX all’internodella stessa pagina web. Il problema consiste nel fatto che gli oggetti JavaScript e itoolkit che gestiscono il codice HTML entrano in conflitto, impedendo la possibilitadi integrare funzioni come gli eventi “drag and drop”.

OpenAjax Alliance prevede di completare la prima versione del proprio insiemedi librerie runtime per l’inizio del 2007.

Il supporto del progetto OpenAjax Hub viene integrato in diversi toolkit e fra-mework di sviluppo, i cui aspetti tecnici vengono affrontati alla sezione 4.4 a pagina34. La tabella 3.1 riporta alcuni ambienti legati al progetto.

21


Nome IndirizzoDojo Foundation http://dojotoolkit.org/

Tibco http://www.tibco.com/

Backbase http://www.backbase.com/

JackBe http://www.jackbe.com/

Nexaweb http://www.nexaweb.com/

Tabella 3.1. Alcuni toolkit e framework di sviluppo che integrano il supportodel progetto OpenAjax Hub

Il sito http://www.openajax.org/ (Cf. [12]) riporta sia la lista completa di tuttele compagnie facenti parte dell’organizzazione, sia i riferimenti alle informazionidettagliate dei rispettivi progetti (tra cui e presente l’azienda Laszlo Systems con ilprogetto OpenLaszlo che viene ampiamente trattato nel capitolo 5). Inoltre, vieneriportato il documento dettagliato del progetto OpenAjax Hub (Cf. [14] per maggioridettagli).

3.4 Effetti delle GUI sullo sviluppo di un’applica-

zione

Un’interfaccia influenza fortemente tutta l’architettura del sistema ed un errore nellasua analisi puo condurre all’uso di tecnologie inadatte a raggiungere gli obiettiviprefissati, costringendo alla riscrittura dell’intera applicazione. Di seguito, sonoesposti alcuni punti critici individuati nella progettazione delle GUI.

3.4.1 Bilanciamento delle operazioni

Nel corso degli anni si e assistito ad una continua variazione del bilanciamento delleresponsabilita funzionali tra client e server, arrivando oggi, con il modello multi-tier, ad avere una distribuzione uniforme delle operazioni. Con l’adozione di questomodello, un’applicazione e divisa in moduli distinti, implementando separatamentel’interfaccia utente grafica (Presentation tier), la logica di gestione (Buisness logic oLogic tier) e la logica del database (Data tier). Questo modello puo essere conservatoanche per le applicazioni Internet. In questo contesto specifico il client e un browserall’interno del quale e mostrata l’interfaccia dell’applicazione e il modello 3-tierspinge ad una separazione quasi totale del livello del client dagli altri due, comeillustrato nella figura 3.1.

22

3.4 – Effetti delle GUI sullo sviluppo di un’applicazione

La logica di gestione, normalmente, e implementata all’interno di un’applicazio-ne residente sul server, come ad esempio un programma CGI (Common GatewayInterface) o un web service, scritti in qualsiasi linguaggio di programmazione.

Figura 3.1. Architettura three-tier o 3-tier (“a tre strati”)

Tuttavia, esigenze di carico della rete spingono spesso ad eseguire sul clientalcune operazioni, come i principali controlli di validita dei dati immessi, usandolinguaggi di script. Pertanto, lo strato intermedio viene suddiviso tra client e server(figura 3.2), come introdotto dalla recente tecnica AJAX (capitolo 4).

23


Figura 3.2. Confronto tra l’architettura web a 3 strati (a) e quella a 4 strati (b)

Da un lato, quante piu operazioni si delegano al client, tanto piu si rischia diessere vincolati al tipo di browser e di rallentare l’elaborazione. Dall’altro lato, siallegerisce il carico del server in presenza di piu utenti connessi contemporaneamen-te. Pertanto, con un equilibrato bilanciamento delle operazioni, l’interfaccia vienesollevata da molte responsabilita e questo ne favorisce la funzionalita. Inoltre, dele-gando al client le funzioni che riesce a svolgere senza perdita di efficienza, si potrebbemigliorare la scalabilita del sistema, ovvero avere la capacita di gestire un numerocrescente di utenti senza peggioramento delle prestazioni del servizio.

3.4.2 Universalita dell’interfaccia

Il fatto di operare all’interno di un browser obbliga l’interfaccia a rispettare alcunivincoli, che talvolta sono invece trascurati. Il principale, senza dubbio, e quello diessere universale, intendendo con questo il fatto di essere visibile nello stesso modoin tutti i browser.

Un’interfaccia universale permette una manutenzione semplice, allunga in mo-do significativo la durata di vita dell’applicazione ed e realmente cross-platform,risolvendo problematiche relative all’accessibilita software.

24

3.5 – I requisiti emergenti dell’usabilita del web

3.4.3 Universalita degli script

Come detto nella sottosezione 3.3.2, spesso e utile aggiungere codice lato client,attraverso linguaggi di scripting. Questo codice deve poter operare su piattaformedifferenti, all’interno di prodotti diversi dei quali non e nota a priori la versione. Emolto importante, quindi, prepararsi ad operare in ciascuno di questi ambienti.

Il linguaggio piu usato e JavaScript, perche attualmente e l’unico ad essere lettoda tutti i browser.

Le tecniche per operare su tutti i browser disponibili, molto sviluppate, si basanosu due strategie principali:

1. la moltiplicazione del codice, con riconoscimento del browser, che permette dieseguire solo il codice specifico per ogni browser;

2. la scrittura del codice per un browser specifico e, quindi, per una determinatagerarchia di oggetti, accompagnata da procedure che riproducono la suddettagerarchia nel caso in cui il codice stia girando nel browser non previsto.

Rendere universale gli script collegati all’interfaccia significa rendere piu robustele proprie applicazioni, ovvero maggiormente accessibili.

3.5 I requisiti emergenti dell’usabilita del web

Secondo una vecchia definizione data dalla norma ISO 9241 del 1993 riferita aiprodotti informatici, l’usabilita e il “grado in cui un prodotto puo essere usato da par-ticolari utenti per raggiungere certi obiettivi con efficacia, efficienza e soddisfazionein uno specifico contesto d’uso.”

Gli aspetti fondamentali da rispettare per permettere un’efficace fruizione delleinformazioni sono elencati di seguito:

• navigabilita: esistenza di un sistema di navigazione e di orientamento nelsito. Si deve evitare il senso di smarrimento, permettendo all’utente di saperedove si trova e come puo ritornare facilmente ad un punto precedente. Anchei link devono dare anticipazioni corrette su dove porteranno.

• Utilita attesa: disponibilita di informazioni e/o servizi che corrispondonoalle aspettative degli utenti. L’utente web ha delle aspettative di ritorno peril tempo che dedica alla visita del sito. Bisogna evitare che le promesse delsito siano disattese o addirittura false.

• Completezza dei contenuti: presenza di contenuti informativi a livello didettaglio desiderabile per gli utenti. E molto difficile che un sito soddisfi il

25


bisogno informativo di ogni tipologia di utenti. Per un portale e importanteche l’ampiezza di contenuti e il loro livello di dettaglio si adattino ad ognitipologia, mentre per un sito specialistico e importante che sia subito definital’audience a cui si rivolge.

• Comprensibilita delle informazioni: la forma e la qualita con cui l’in-formazione e i contenuti vengono presentati nel sito. Molto importante illinguaggio usato, soprattutto per operazioni interattive. Deve esistere un si-stema di classificazione delle informazioni comprensibile da tutti, anche se ilcontenuto finale puo essere specialistico.

• Efficacia comunicativa: la strategia comunicativa del sito. L’efficacia co-municativa e una misura della credibilita del sito e si basa sia sul marchio del-l’istituzione/struttura che rappresenta, sia sulla capacita di essere persuasivie seducenti per portare ad una relazione di fiducia con gli utenti.

• Attrattivita grafica: la qualita della grafica e la piacevolezza visiva delsito. La grafica deve portare ad un giusto equilibrio tra emozioni e comfortche induce sull’utente ed un utilizzo consapevole dei contenuti. Non devenascondere il vero scopo del sito.

26

Capitolo 4

Le tecnologie AJAX

4.1 Introduzione: che cos’e AJAX e come si col-

loca nel web

L’acronimo AJAX, che significa esattamente Asynchronous JavaScript And XML,ovvero JavaScript Asincrono ed XML, e stato enunciato per la prima volta da JesseJames Garrett, nel 18 Febbraio 2005, come titolo di un post all’interno del suoblog [9]. Jesse James Garrett e il fondatore e presidente di Adaptive Path, un’aziendadi San Francisco (California, US) che ha molti anni di esperienza in ambito diapplicazioni interattive per il web.

Nell’articolo, dal titolo “AJAX: A New Approach to Web Applications”, vienepresentato AJAX e i concetti ad esso collegati. Viene subito chiarito che non sitratta ne di una nuova tecnologia ne di un’invenzione, ma bensı di un concettoutilizzato per sviluppare applicativi avanzati e particolari, quali ad esempio Gmail,Google Maps o Google Suggest. Il concetto e in parte espresso nell’acronimo scelto,cioe un utilizzo asincrono di JavaScript che attraverso l’interfacciamento con XML,puo permettere ad un client di richiamare informazioni lato server in modo veloce etrasparente, allargando cosı gli orizzonti delle Rich Internet Applications (RIA).

Queste applicazioni fino a poco tempo fa erano legate principalmente alle tecno-logie Adobe-Macromedia Flash o Java (con le applet). Entrambe, purtroppo, nonsempre interpretabili dai client degli utenti e troppo spesso usate a sproposito conil solo scopo di stupire, discorso che spesso e purtroppo vale anche oggi.

In alternativa a queste tecniche di interazione client-server, quando nel 1996 ven-ne introdotto l’elemento iframe in Internet Explorer 3, molti sviluppatori sfruttaronoquest’ultimo modificando l’attributo sorgente (src) della pagina racchiusa e simu-lando cosı un refresh trasparente di una parte di contenuti. Veniva cosı emulata, inmodo abbastanza grossolano, un’interazione asincrona.

Nel 1998 Microsoft comincio a sviluppare una tecnologia, chiamata Remote

27

4 – Le tecnologie AJAX

Scripting, con lo scopo di creare una tecnica piu elegante per richiamare conte-nuti differenti ed e in questo periodo, seppur con nome differente, che AJAX venneutilizzato per la prima volta, per poi evolversi in versioni piu mature fino a diventareun oggetto vero e proprio, noto ora come XMLHttpRequest.

Il motivo principale di tanto successo e che solo ultimamente il Remote Scriptingha suscitato lo stupore degli addetti ai lavori nel vedere cosa Google fosse riuscitaa fare all’interno dei suoi applicativi senza necessita di Flash Player o Java VirtualMachine, mantenendo comunque la compatibilita con molteplici browser di utentiche per diversi motivi non potevano usufruire di JavaScript.

Come spesso e accaduto negli ultimi anni, molti hanno preso spunto da Goo-gle ed il web, noto per la sua immediatezza propositiva, e stato in grado in pocopiu di un anno di mostrare numerosi esempi di applicativi basati su AJAX. Googlesta facendo un grande investimento nel sviluppare questo approccio. Tutti i mag-giori prodotti introdotti da Google nell’ultimo anno, quali Orkut, Gmail, l’ultimaversione beta di Google Groups, Google Suggest e Google Maps, sono applicazioniAJAX. Altri si ispirano: molte delle caratteristiche che le persone amano nel Flickr(http://www.flickr.com/) dipendono da AJAX ed il motore di ricerca di AmazonA9.com applica tecniche simili. Infine, e anche degno di nota il sito del progettoSIMILE (sviluppo di robusti tool open source basati sulle tecnologie semantiche,all’indirizzo http://simile.mit.edu/) sempre per l’utilizzo di questa tecnica.

Questi progetti dimostrano che AJAX non e solo avanzato dal punto di vistatecnico, ma anche pratico per le applicazioni “real-world”. Tutti gli esempi pre-cedenti sono una dimostrazione che questa non e un’altra tecnologia che funzionasolo in laboratorio. Inoltre, le applicazioni AJAX possono essere di qualsiasi dimen-sione, dalla molto semplice monofunzione di Google Suggest al molto complesso esofisticato Google Maps.

4.2 Descrizione tecnica e teorica

Come detto in precedenza, AJAX non e una tecnologia. Infatti, consiste in piutecnologie, ognuna delle quali si sviluppa per conto proprio, ma unendosi con lealtre crea nuovi e potenti sistemi. Proseguendo nella descrizione, AJAX incorpora:

• presentazione basata su standard usando XHTML e fogli di stile (CSS);

• visualizzazione dinamica ed interazione usando il Document Object Model (DOM);

• scambio di dati e manipolazione usando XML e XSLT;

• recupero di dati asincroni usando l’oggetto XMLHttpRequest;

• JavaScript che tiene insieme il tutto.

28

4.2 – Descrizione tecnica e teorica

Il modello classico dell’applicazione web ha il seguente principio di funziona-mento: la maggior parte delle azioni dell’utente nell’interfaccia attiva una richiestaHTTP al server. Il server esegue alcuni processi (recuperare dati, trattare numeri,parlare a diversi legacy system, etc.) e poi restituisce una pagina HTML al client.E un modello adattato dall’uso originale del web come un medio ipertesto, ma cioche rende il web adatto per l’ipertesto non lo rende necessariamente adatto alleapplicazioni software.

Figura 4.1. Confronto tra il modello di interazione tradizionale delle appli-cazioni web e il modello AJAX

Questo approccio ha un senso dal punto di vista tecnico, ma non da quello dell’e-sperienza di un utente, in quanto mentre il server sta eseguendo varie elaborazioni,l’utente e costretto ad aspettare.

Ovviamente, il progetto del web per le applicazioni prevede tra i vari obiettivi dinon fare aspettare l’utilizzatore. Una volta che l’interfaccia e caricata, l’interazionecon l’utente non si deve fermare e ricaricare ogni volta che l’applicazione ha biso-gno di informazioni e/o dati dal server. Di fatto, non sarebbe ne utile ne comodoall’utente vedere l’applicazione andare al server.

Invece, un’applicazione AJAX elimina la natura start-stop-start-stop dell’intera-zione sul web introducendo un intermediario, ovvero un motore AJAX, tra l’utente

29


ed il server (figura 4.1). Ad una prima analisi, puo sembrare che aggiungere un layerall’applicativo lo renderebbe meno reattivo, ma e vero esattamente il contrario.

Figura 4.2. Confronto tra l’interazione sincrona client-server equella asincrona (AJAX)

Invece di caricare una pagina web, all’inizio della sessione, il browser carica unmotore AJAX scritto in JavaScript e di solito messo al sicuro in un frame nascosto.Questo motore e responsabile sia per il rendering dell’interfaccia vista dall’utente,sia per la comunicazione con il server per conto dell’utente. Il motore AJAX permet-te che l’interazione dell’utente con l’applicazione avvenga in modo asincrono, cioeindipendentemente dalla comunicazione con il server. Cosı l’utente non si trova maidavanti una finestra browser vuota e un’icona a clessidra, aspettando che il serverfinisca l’elaborazione e restituisca tutta la pagina.

30

4.3 – Introduzione ai fondamenti di AJAX

Ogni azione dell’utente che normalmente genererebbe una richiesta HTTP pren-de la forma di una chiamata JavaScript al motore AJAX. Il motore gestisce da soloogni risposta all’azione dell’utente che non richieda un ritorno al server, per esempiocome la semplice validazione dei dati, l’editing dei dati nella memoria e persino lanavigazione. Se il motore ha bisogno di qualcosa dal server per rispondere, per esem-pio se sta sottoponendo dati per essere elaborati, caricando del codice aggiuntivodell’interfaccia o recuperando nuovi dati, il motore effettua quelle richieste in modoasincrono, di solito usando il formato XML, senza fermare l’interazione dell’utentecon l’applicazione. Tutto cio e illustrato in figura 4.2.

4.3 Introduzione ai fondamenti di AJAX

Il termine AJAX e stato coniato di recente per sottolineare due caratteristiche moltofunzionali possedute dai browser che sono stati in circolazione per anni, ma nonfurono considerati da molti sviluppatori web fino ai tempi attuali quando applicativicome Gmail, Google suggest e Google Maps hanno aperto la via.

Le due caratteristiche in questione permettono di:

• fare richieste al server senza ricaricare la pagina;

• analizzare e lavorare con documenti XML.

Per fare una richiesta HTTP al server usando JavaScript, e necessario creareun’istanza di classe che fornisca questa funzionalita. Tale classe fu originariamen-te introdotta in Internet Explorer come un oggetto ActiveX, chiamato XMLHTTP.Poi browser come Mozilla, Safari ed altri sono seguiti, implementando una clas-se XMLHttpRequest che supporta i metodi e le proprieta dell’oggetto originario diMicrosoft ActiveX.

Conseguentemente, per creare un’istanza cross-browser (oggetto indipendentedal browser utilizzato) della classe richiesta si puo seguire il seguente schema:

if (window.XMLHttpRequest) { // Mozilla, Safari, ...

http_request = new XMLHttpRequest();

} else if (window.ActiveXObject) { // IE

http_request = new ActiveXObject("Microsoft.XMLHTTP");

}

Certe versioni di alcuni browser di Mozilla non funzionano se la risposta dalserver non ha un header mime-type in XML. Per colmare questa lacuna, e necessarioeseguire una chiamata extra di metodo per fare l’override dell’header inviato dalserver nel caso non fosse text/xml, come descritto qui di seguito.

31


http_request = new XMLHttpRequest();

http_request.overrideMimeType(’text/xml’);

Il passo successivo e decidere cosa fare dopo aver ricevuto la risposta del serveralla richiesta effettuata. A tale scopo e necessario indicare all’oggetto di richiestaHTTP a quale funzione JavaScript sara demandato il lavoro di trattare la risposta.Cio e fatto fissando la proprieta onreadystatechange dell’oggetto al nome dellafunzione JavaScript progettata appositamente, come indicato di seguito:

onreadystatechange http_request.onreadystatechange = nomeDellaFunzione;

Si puo notare che non vi sono ne parentesi dopo il nome della funzione ne pa-rametri passati. Invece di dare un nome di funzione, si puo anche usare la tecnicaJavaScript di definizione di funzione precisando le azioni che tratteranno la risposta.

http_request.onreadystatechange = function(){

// azioni per trattare la risposta

};

In seguito, dopo aver esposto cio che succedera non appena ricevuta la risposta,si deve formulare la richiesta. E necessario chiamare i metodi open() e send() dellaclasse di richiesta HTTP, come:

http_request.open(’GET’, ’http://www.esempio.org/pagina.html’, true);

http_request.send(null);

dove:

• il primo parametro di chiamata a open() e il metodo di richiesta HTTP (GET,POST, HEAD o qualsiasi altro metodo che si voglia usare e che sia supportatodal server);

• il secondo parametro e l’URL della pagina che si sta richiedendo;

• il terzo parametro stabilisce se la richiesta e asincrona. Se true, l’esecuzionedella funzione JavaScript continuera, mentre la risposta del server non e ancoraarrivata. Questo e il fondamento di AJAX.

Da ricordare che prima di inviare la richiesta, e gia stato indicato il nome di unafunzione JavaScript che sara predisposta a gestire la risposta. Un’operazione chedovrebbe fare questa funzione e il controllo dello stato della richiesta. Se lo statoha valore 4, significa che e stata ricevuta la risposta completa del server e si puocontinuare ad elaborarla.

32

4.3 – Introduzione ai fondamenti di AJAX

if (http_request.readyState == 4) {

// e’ stata ricevuta la risposta, tutto OK! :-)

} else {

// non ancora pronto

}

La lista completa dei valori readyState comprende:

0 (non inizializzato)

1 (caricamento)

2 (caricamento completato)

3 (interattivo)

4 (completo)

Un’operazione successiva, che dovrebbe essere fatta, e il controllo del codice dellostatus della risposta del server HTTP. Tutti i codici possibili sono quelli elencati nelW3C site [7].

Per esempio, se non ci sono problemi con la richiesta viene restituito il codice200 (OK).

if (http_request.status == 200) {

// OK! :-)

} else {

// c’e’ stato qualche problema con la richiesta :-(

// per esempio la risposta potrebbe ritornare il codice 404 (Not Found)

// oppure 500 (Internal Server Error)

}

Dopo aver controllato lo stato della richiesta ed il codice di stato HTTP dellarisposta, le successive azioni della funzione JavaScript dipendono da cosa si vuolfare con i dati che il server ha inviato. Esistono due opzioni per accedere ai dati:

• http request.responseText: restituisce la risposta del server come una strin-ga di testo;

• http request.responseXML: restituisce la risposta di un oggetto chiamatoXMLDocument che si puo attraversare utilizzando le funzioni del DOM Java-Script.

Per completare questa breve introduzione tecnica e teorica, si sottolinea comeil tipo di risposta che l’oggetto si aspetta dopo una chiamata , non deve esserenecessariamente di tipo XML o letta come tale ma che puo essere semplicementetestuale, in contro tendenza con l’acronimo stesso, ma non per questo inusuale.

33


4.4 OpenAjax Alliance e framework AJAX

Nella sottosezione di pagina 21 e stata citata l’organizzazione “OpenAjax Alliance”,illustrandone gli obiettivi e i punti fondamentali del suo progetto. Come detto ,tale alleanza e costituita da decine di aziende importanti del settore informatico eche sono interessate allo sviluppo e alla promozione delle tecnologie web basate suAJAX.

Di fatto, AJAX offre un’ampia scelta a riguardo dell’architettura, come vienespiegato nelle sottosezioni 4.4.1 e 4.4.2. Questa diversita permette agli sviluppatoriAJAX di scegliere fra diversi prodotti commerciali e/o tecnologie open source pertrovare quella che soddisfa al meglio le esigenze relative alle applicazioni esistenti eall’infrastruttura di sviluppo, nonche le loro preferenze tecnologiche.

Per ogni linguaggio server-side, esistono varie librerie, in grado di sfruttare inmodo automatizzato o facilmente integrabile le possibilita offerte dallo scambio datiasincrono. Molte si basano proprio sulla creazione di funzioni apposite addette asvolgere determinati compiti, mentre altre si basano sulla gestione di classi o deiloro metodi attraverso automazioni generate dinamicamente e date in elaborazioneal codice JavaScript. La separazione fra client e server e dei rispettivi compitidiventa cosı ancor piu accentuata, ma allo stesso tempo si trasforma in una vera epropria simbiosi, dove il controllo dell’applicativo e dato dalla somma del linguaggioclient piu quello server e non piu solo da quest’ultimo. Nella scelta dell’eventualeframework o libreria si deve tener conto la compatibilita almeno con i browser piudiffusi e non solo con alcuni di questi.

Nel seguito vengono illustrate due delle principali tecniche usata per classificarei toolkit e i framework AJAX. Nel sito http://www.openajax.org/ viene riportatoil documento White Papers con tutte le informazioni dettagliate relative alla tecnicaAJAX (Cf. [13] per maggiori dettagli).

4.4.1 Architettura client-side e server side

Gran parte delle tecnologie AJAX trasformano una definizione dell’applicazione in-dipendente dalla piattaforma (che solitamente consiste in una combinazione di mar-kup e logica) nell’appropriato contenuto HTML e JavaScript che verra processatodal browser per fornire all’utente un’interfaccia ricca tipica di AJAX. Alcuni progettiAJAX eseguono la trasformazione sul client, mentre altri sul server.

Trasformazione AJAX lato utente

Il diagramma della figura 4.3 mostra l’approccio comune della tipologia client-side.Gli sviluppatori realizzano i componenti visualizzati in verde (blocchi contrasse-

gnati con il simbolo 1), il toolkit AJAX fornisce i componenti arancio (simbolo 2)

34

4.4 – OpenAjax Alliance e framework AJAX

e il motore AJAX genera i componenti in giallo (simbolo 3), quali HTML e DOM,come risultato della sua trasformazione.

Figura 4.3. Modello di trasformazione AJAX lato utente

Solitamente il server non necessita di software specifico per AJAX e tutte letrasformazioni derivano dalla libreria AJAX lato utente.

Un vantaggio di questa scelta e l’indipendenza dalle tecnologie lato server. Ilcodice in esecuzione sul server genera e invia le pagine e risponde alle richiesteasincrone del client. Questo approccio puo essere invertito specularmente.

Trasformazione lato server

La trasformazione lato server generalmente segue il modello della figura 4.4.Per cio che riguarda AJAX lato server, un componente AJAX sul server effettua

gran parte della trasformazione in codice appropriato per il client, cioe HTML eJavaScript. A volte, il toolkit lato server scarica la sua libreria AJAX lato client checomunica direttamente con il componente del toolkit lato server.

Il vantaggio principale di questo approccio e dato dal fatto che permette all’utentedi usare i linguaggi lato server per il debug, l’editing e i tool con cui gli sviluppatorisono gia famigliari, ma cio comporta la dipendenza da una determinata tecnologialato server. Come regola generale, i framework AJAX lato server necessitano di

35


codice scritto in un linguaggio lato server (es. Java). Questi framework tipicamentenascondono tutto il codice JavaScript che viene eseguito sul browser all’interno diwidget, compresi i loro eventi. Se le funzionalita built-in non sono sufficienti per leesigenze del programmatore, i nuovi componenti devono essere sviluppati in codiceJavaScript. Le strategie di implementazione di framework AJAX sono molteplici.Da un lato il server gestisce tutti gli eventi dell’applicazione, mentre dall’altro lato,molti eventi vengono gestiti dal client. Per alcuni framework, in fase di sviluppotutti gli eventi vengono gestiti dal server, ma in produzione molti eventi vengonogestiti dal client.

Figura 4.4. Modello di trasformazione AJAX lato server

4.4.2 Framework lato client procedurali e dichiarativi

Molti framework AJAX combinano l’approccio procedurale con quello dichiarativo.

Con l’approccio procedurale, gli sviluppatori gestiscono il toolkit quasi esclusi-vamente utilizzando le API JavaScript per gestire tutti gli eventi e manipolare iwidget.

Con l’approccio dichiarativo, gli sviluppatori gestiscono il toolkit quasi esclusiva-mente tramite HTML o XML per definire i componenti delle pagine e le relazioni cheintercorrono tra di loro. Tag XML personalizzati sono, spesso, definiti nella struttu-ra del framework. Il codice JavaScript puo essere necessario in alcune circostanze,ma uno degli obiettivi del framework e di minimizzare l’utilizzo di logica.

36

4.5 – Considerazioni lato utente

4.5 Considerazioni lato utente

4.5.1 Vantaggi

L’impressione di avere a che fare con pagine apparentemente piu interattive, di-namiche e professionali e praticamente immediata. L’effetto novita si aggiungeprepotentemente alla lista, stuzzicando la curiosita del navigatore.

Questi aspetti apparentemente futili hanno permesso a tecnologie come Flashdi affermarsi nel contesto web. Questo perche l’interesse collettivo e la ricerca diinformazioni, ma si preferisce navigare dove le informazioni sono presentante nelmodo piu semplice e veloce possibile.

Altro motivo che puo rendere vantaggioso l’utilizzo di AJAX e quello di otteneremodifiche dinamiche e leggere sulle pagine, come i suggerimenti sui campi di ricerca,in grado di suggerire parole presenti e velocizzare l’inserimento dei dati, controllosulla correttezza dei campi di un form man mano che viene compilato, senza aspet-tare il momento dell’invio dei dati, caricamento di mappe solo sul frame interessato,senza ricaricare tutta la pagina e cosı via.

4.5.2 Svantaggi

Due delle problematiche piu diffuse del web attuale, sia per la realizzazione deisiti web che per la realizzazione di applicativi web, riguardano l’accessibilita el’usabilita.

Per quanto concerne l’accessibilita, gli utenti che necessitano di tecnologie as-sistive e coloro che non dispongono di connessioni veloci sono i piu penalizzati. Iprimi perche non possono, attualmente, godere del cambio parziale di contenuti enon saranno, quindi, in grado di sfruttarne le potenzialita. Basti pensare ad unoscreenreader per i disabili visivi. Questo tipo di software legge sequenzialmentela pagina web dall’alto verso il basso e non sarebbe in grado di rilevare modificheapportate all’inizio della pagina dovute alla tecnica asincrona. I secondi devonocaricare, almeno al primo accesso, una mole di dati consistente rappresentata daivari file JavaScript e potrebbero non essere in grado di sfruttare niente di quantocaricato. Inoltre, si potrebbe non disporre di un browser aggiornato e quindi noncompatibile con la pagina web scaricata, oppure, in situazioni di JavaScript disabi-litato, si avrebbe l’assenza dell’oggetto XMLHttpRequest. In questi casi si scaricanocentinaia di byte che non verranno mai usati a causa del controllo a posteriori utiliz-zato per conoscere la reale compatibilita con AJAX. Troppo codice Javascript puorisultare oneroso, ovviamente a lato client, soprattutto se tale codice e stato scrittocon poco criterio. Questi aspetti puramente tecnici sono spesso raggirabili, graziead una stesura ottimizzata dell’applicativo da parte dello sviluppatore o grazie al

37


caricamento dinamico del JavaScript proposto dopo aver verificato la compatibilitadel browser.

Un’altra problematica e relativa all’uso dei tasti “avanti” e “indietro” presenti neibrowser. Una qualunque interazione asincrona potrebbe dare la sensazione di avercambiato stato alla pagina e l’abitudine a tornare indietro, qualora il risultato nondovesse essere quello voluto, e intrinseca nel navigatore, nonche lecita. Ma aprendodirettamente una pagina ricca di interazioni asincrone, ci si puo accorgere comenon e sempre possibile, cliccando sul tasto “indietro” del browser, tornare allo statoprecedente, in quanto si viene reindirizzati alla pagina precedente. Cio puo causaredisorientamento. In questi casi, la consapevolezza di aver usato AJAX, qualora ilnavigatore sia preparato, non puo certo aiutare, poiche anche l’aggiornamento dellapagina non serve a tornare allo stato precedente, ma solo allo stato iniziale.

Oltre ad essere un vincolo di navigazione, questo problema e anche un vincoloper l’indicizzazione o la possibilita di segnalare ad altri la pagina visualizzata. Que-sto accade perche il comando gestito da JavaScript non e portabile come un link.Quindi scrivere ad un’altro utente l’indirizzo attualmente visitato ed eventualmentemodificato tramite AJAX non e possibile se non dando delle indicazioni precise sulleoperazioni svolte una volta arrivati nella pagina in oggetto.

La soluzione a questi problemi non e semplice ed i motivi sono diversi. In primoluogo creare un gestore di eventi in grado di aggiungere cambiamenti alla cronologiadel browser puo risultare un’operazione complessa per via dei diversi standard ofunzioni presenti nei diversi browser. In secondo luogo l’indicizzazione di un sololink, per chi non ha JavaScript o non puo usufruire di tale tecnologia, diventerebbepressapoco impossibile.

La libreria di BackBase (http://www.backbase.com/) gestisce il caricamento ela visualizzazione asincrona delle varie sezioni di una pagina tramite una serie diinformazioni appese dopo il carattere #, il quale permette solitamente di indicizzaresotto contenuti di una pagina tramite l’uso di elementi con identificativo univoco,ma che puo essere gestito senza problemi dal JavaScript proposto. Ma viene risoltosolamente il problema dei tasti “avanti” e “indietro” del browser. Infatti, se un uten-te che naviga una sottosezione passa il link ad un altro utente, la pagina visualizzatapotrebbe non essere uguale. Questo avviene perche e solo il codice JavaScript (latoclient) che e in grado di verificare il link e gestirlo di conseguenza, mentre il servernon potra fare altro che mostrare la pagina richiesta, ignorando giustamente tuttocio che non fa parte del reale indirizzo richiesto, ovvero tutto il testo eventualmen-te presente dopo il carattere #. Inoltre rimangono i problemi di compatibilita trabrowser e quelli relativi alla disabilitazione del codice JavaScript.

38

4.6 – Considerazioni lato server

4.6 Considerazioni lato server

4.6.1 Vantaggi

E noto che usare fogli di stile (CSS) esterni piuttosto che in linea ha l’effetto di ridurrela banda utilizzata mensilmente dai navigatori. L’utilizzo di AJAX potrebbe farealtrimenti. Infatti con AJAX il server non ha necessita di trasferire tutta la paginaper ogni interazione, ma solo la porzione necessaria all’operazione richiesta. Questorende sensibilmente piu veloce l’interazione per l’utente e favorisce il risparmio dibanda.

Inoltre, c’e anche una ricaduta in termini di calcoli da effettuare. In un portalericco di informazioni, reperire tutti i dati per poter affrontare una interazione “tra-dizionale” puo richiedere una computazione maggiore per diversi decimi di secondo(database, web service, etc.). Invece, con AJAX le richieste sono puntuali, cioemirate solo a cio che serve effettivamente, ed il server puo rispondere in modo piuefficiente. Questo puo anche essere positivo per la gestione di un numero piu elevatodi utenti simultanei, non dovendo piu operare su tutto l’applicativo da parte delserver. Questa caratteristica prende il nome di scalabilita. Allo stesso tempo unaparte dei calcoli puo essere data in gestione al browser, cosı da sfruttare la potenzadel PC-client e distribuire il carico su tutti, piuttosto che sul solo host.

Figura 4.5. Carico del server con e senza AJAX

Non bisogna ovviamente esagerare, pena il rallentamento del client qualora i cal-coli dovessero essere troppi. Il tutto va progettato in maniera molto oculata e sen-sata e, soprattutto, non si dovrebbero creare applicativi cosı complessi da richiederediversi secondi di attesa prima di poter essere utilizzati.

39


4.6.2 Svantaggi

Come detto in precedenza, il principale inconveniente puo essere causato dall’abusodi AJAX. Infatti, uno sviluppatore poco accorto potrebbe mettere a disposizionetroppe interazioni su una sola pagina e se non si controllano le operazioni sul client, ilserver rischia di ritrovarsi sovraffollato di richieste probabilmente inutili. Di esempice ne possono essere vari, come per esempio gli aggiornamenti di dati statisticieseguiti in maniera troppo frequente. In questi casi, la soluzione e trovare il giustocompromesso tra necessita effettiva della frequenza di aggiornamento e calcoli pereffettuarla.

4.7 Problematiche relative al tempo di attesa

Un’inevitabile incomodo e l’attesa che trascorre tra una richiesta dell’utente e larisposta del server. Con l’aggiunta di AJAX si perde questa linearita e mentre l’u-tente e all’interno della stessa pagina le richieste sul server possono essere numerosee completamente indipendenti. Nulla vieta, teoricamente, di effettuare decine dirichieste simultanee al server per operazioni differenti con o senza controllo da partedel navigatore.

Figura 4.6. Rappresentazione di piu richieste ad un server con latenza e risposte

Cio che resta del vecchio flusso, il tempo di attesa, passa spesso in secondo pianoed in molti tipi di interazione e praticamente impercettibile. Ma bisgna prestareattenzione, poiche questo tempo e anche uno dei maggiori problemi dell’utilizzodi AJAX, sia per gli sviluppatori sia per i navigatori. I primi potrebbero trovarsiin difficolta qualora si dovesse aspettare una risposta che per svariate ragioni si epersa o ritarda ad arrivare, mentre i secondi potrebbero non avere idea di cosa stiaaccadendo alla pagina, chiudendola ignari di aver richiesto un’informazione.

4.7.1 Perdita di una richiesta

Esistono diverse motivazioni per le quali una richiesta asincrona possa apparente-mente svanire nel nulla. Tra le piu frequenti troviamo i rallentamenti sulla rete e ilsovraccarico del server, che potrebbe lasciare il navigatore in attesa di una risposta,ma non essere in grado di elaborarla, se non entro tempi eccessivi.

40

4.7 – Problematiche relative al tempo di attesa

Quando il server non puo rispondere ad una richiesta, risponde con uno statodiverso da 200 (OK). Ma in caso di latenze questo non accade. E opportuno, quindi,controllare il lasso di tempo intercorso tra l’azione richiesta da parte dell’utente e lareale possibilita di soddisfare il suo intento, specie qualora il server avesse frequentiproblemi di banda o di velocita.

La reazione tipica dell’utente che non riceve risposta da una pagina e quella ditentare di ricaricarla ripetutamente. Questo comportamento dovrebbe essere evita-to, in quanto aggiunge richieste ad un server gia saturo, che non riuscira a smaltireil suo carico, continuando a lasciare l’utente in attesa di una risposta. Inoltre, ri-caricare una pagina sviluppata con tecnica AJAX, significa ricaricare la pagina cosıcom’e inizialmente, senza ovviamente i vari passaggi intermedi di caricamento delleinformazioni dei vari frame costituenti la pagina da parte dell’utente.

Le situazioni descritte possono essere affrontate in diversi modi. In generale, sipossono adottare i seguenti due semplici approcci:

• gestione di un time-out: il meccanismo piu importante che si deve realizzaree una temporizzazione. E necessario decidere, ovviamente lato client, dopoquanto tempo di attesa senza risposta si puo considerare fallita la richiestadell’utente. Cio dipende dalla tipologia dell’applicazione e dal tipo di richiestaeffettuata (dimensione della risposta, tempo richiesto dal server per elaborarela risposta, etc.). In caso di fallimento e opportuno avvisare l’utente per nonlasciarlo in balia dell’attesa.

• Controllo sul link: e necessario disabilitare la sua funzionalita nel caso in cuil’utente abbia effettuato una richiesta che di solito puo richiedere del tempoprima di essere inviata e ricevuta. Questo semplice meccanismo e utile soprat-tutto in situazioni critiche e potrebbe non essere sempre indispensabile, macomunque puo essere la maggiore fonte di stabilita o velocita di una paginapotenzialmente ricca di accessi simultanei e con questo semplice accorgimen-to, non si corre il rischio di sovracaricare il server con richieste multiple edidentiche.

4.7.2 Gestione dell’attesa

Oltre al controllo sul tempo di risposta per evitare richieste stressanti, e importan-te tener conto del problema dell’attesa rivolto all’intrattenimento del navigatore,per non lasciarlo in balia delle azioni compiute ed inconsapevole di cio che stiasuccedendo.

E noto che un’azione non corrisposta immediatamente, in quanto richiede deltempo di elaborazione, puo portare l’utente a disorientarsi su cio che stia facendo.Gli atteggiamneti piu comuni sono quelli di ritentare l’operazione piu volte , porsi dei

41


dubbi sul fatto di aver sbagliato o che il sito sia bloccato e cosı via. Un messaggiotemporaneo puo rassicurare il navigatore sull’avvenuta richiesta e migliorare cosıl’usabilita del sito.

In Flash si aggira il problema usando i loader: elementi grafici leggeri che elimi-nano la sensazione di un’attesa statica rappresentando la percentuale di caricamentocon l’ausilio di una barra di progressione o con del testo esplicito.

Con AJAX si puo fare analogamente, in quanto esistono svariati siti, come peresempio http://www.napyfab.com/AJAX-indicators/, che mettono a disposizionealcune immagini gif animate da poter sfruttare durante l’attesa, come quelle indicatenella figura 4.7.

Figura 4.7. Indicatori di attesa

Un consiglio che viene dato sulla scelta della giusta animazione di intrattenimentoe quello di non mostrare un’immagine ne troppo grande ne troppo piccola, ed e,inoltre, importante evitare di mostrare un’animazione troppo frenetica al fine dirispettare anche gli utenti che al posto di una crisi epilettica avrebbero voluto soloraggiungere un’informazione.

42

Capitolo 5

Rich Internet Applicationmediante OpenLaszlo

5.1 Introduzione: che cos’e OpenLaszlo

OpenLaszlo e una tecnologia open per creare RIA (Rich Internet Application), ba-sate inizialmente su Flash partendo da un descrittore di interfaccia XML (il sito isti-tuito si trova all’indirizzo http://www.openlaszlo.org/). Questo progetto open enato dall’azienda americana Laszlo Systems (http://www.laszlosystems.com/) ede largamente sponsorizzato dall’azienda IBM, la quale ha donato anche un ambien-te IDE basato su Eclipse (http://www.eclipse.org/laszlo/). Entrambe questeaziende fanno parte dell’organizzazione “OpenAjax Alliance”, il cui obiettivo e quel-lo di agevolare la conoscenza e lo sviluppo della tecnologia AJAX, come spiegato nelcapitolo precedente. Lo sviluppo di questo progetto, attualmente, da la possibilitadi poter scegliere tra due modalita di presentazione: quella in Flash e, dalla fine del2006, anche in HTML/DHTML, ovviamente con funzioni AJAX. L’obiettivo dell’a-zienda Laszlo Systems, oltre a quello di creare un ambiente completo che agevola lacreazione di applicativi web avanzati e con funzionalita AJAX, e quello di mantene-re la portabilita del codice sorgente, anche su dispositivi, sistemi operativi e plugindifferenti.

5.2 Architettura client e server

Il server OpenLaszlo e un’applicazione Java che viene eseguita in un J2EE servletcontainer. Questo server permette la comunicazione con altri server per reperirevarie informazioni e dati, in quanto sono supportati vari protocolli (lato back end).Un’applicazione OpenLaszlo viene scritta con un particolare linguaggio chiamato

43

5 – Rich Internet Application mediante OpenLaszlo

LZX e che e stato ideato ad hoc per questo progetto open source. Il server Open-Laszlo compila tale codice sorgente e invia dei bytecode al web browser del client chene ha fatto richiesta (lato front end). Attualmente l’ambiente run-time supportatoe il plug-in Flash 7 o versione superiore, il quale e disponibile per svariati sistemioperativi e dispositivi, quali ad esempio Windows, Pocket PC, Mac OS, Linux eSolaris, e per svariate piattaforme mobili e set-top box. Il bytecode generato e nelformato SWF ed e quindi riconosciuto dal player Macromedia Flash. Bisogna te-nere conto, pero, che nulla dell’architettura di OpenLaszlo e strettamente vincolataalla tecnologia Flash. Infatti, questo ambiente di sviluppo prevede, in futuro, lapossibilita di supportare altri ambienti run-time per client. Di fatto, per la fine del2006 e stato reso disponibile l’ambiente run-time DHTML, inizialmente in versionesperimentale e con uso consigliato su browser FireFox 1.5.

La figura 5.1 mostra l’architettura client-server nel contesto di OpenLaszlo. Ilclient e costituito da un web browser con il plugin opportuno installato, il quale asua volta permette l’esecuzione dell’applicazione LZX richiesta; mentre il server e ingrado di comunicare con altri server presenti su Internet e gestisce le varie richiestedei client. La comunicazione fra il client e il server avviene mediante il tradizionaleprotocollo http: il server invia bytecode, mentre il client invia dati in formato XML.Inoltre, e anche supportato il protocollo HTTPS per poter cosı attivare e gestire uncollegamento sicuro.

Figura 5.1. Architettura client-server OpenLaszlo

44

5.3 – Architettura del server OpenLaszlo

5.3 Architettura del server OpenLaszlo

Come detto in precedenza, il server OpenLaszlo e un’applicazione Java che viene ese-guita in un J2EE servlet container in cui gira l’ambiente JRE 1.4 o superiore. Questoambiente di sviluppo e multipiattaforma (Windows, Solaris, Linux, Mac OS X, . . . ).

Come si puo anche notare dalla figura 5.2, il server OpenLaszlo e costituito da 5principali sottosistemi:

• il modulo Interface Compiler;

• il modulo Media Transcoder;

• il modulo Data Manager;

• il modulo Persistent Connection Manager;

• il modulo Cache.

Figura 5.2. Architettura del server OpenLaszlo

45


Il modulo Interface Compiler

Il linguaggio LZX consiste di tag XML specifici per creare oggetti JavaScript e dicodice JavaScript per poter manipolare tali oggetti (i dettagli di tale linguaggio ver-rano illustrati successivamente alla sezione 5.8). Per tale motivo, il modulo InterfaceCompiler e costituito da due parti:

1. LZX Tag Compiler;

2. LZX Script Compiler.

Inoltre, questo modulo invoca i moduli Media Transcoder ( o Compiler) e Da-ta Manager, rispettivamente per compilare informazioni multimediali e dati chesaranno poi integrati nell’applicazione.

I due compilatori convertono i tag XML e il codice JavaScript del file sorgenteLZX in bytecode eseguibile (formato SWF) che sara trasmesso all’ambiente clientOpenLaszlo. Questo codice viene prima memorizzato nella cache e poi inviato alclient. In base all’applicazione che viene invocata, puo essere trasmesso o un file conestensione SWF o un file HTML contenente all’interno un oggetto SWF.

Il Media Transcoder ha il compito di convertire una vasta gamma di formatimultimediali in un unico formato che sara poi visualizzato sul client mediante ilmotore di rendering. Questo meccanismo permette all’applicazione OpenLaszlo digestire i vari formati multimediali in maniera unificata senza dover utilizzare softwareaggiuntivo. I tipi multimediali supportati sono: JPEG, GIF, PNG, MP3, TrueType,e SWF.

Il modulo Data Manager

Questo modulo comprende:

1. un compilatore di dati che converte ogni tipo di dato in un formato binariocompresso, il quale e interpretabile dall’applicazione OpenLaszlo;

2. una serie di componenti (Data Connector) che consentono all’applicazioneOpenLaszlo di reperire dati via XML/HTTP. Grazie a questa caratteristicae possibile l’interfacciamento mediante la rete Internet con database, XMLWeb Service e altri Web Server.

Il modulo Persistent Connection Manager

E il modulo che gestisce connessioni persistenti, cioe autenticazioni o messaggi real-time verso un’applicazione OpenLaszlo che ne ha fatto richiesta. Questa caratteri-stica e, pero, al momento provvisoria.

46

5.4 – Architettura del client OpenLaszlo

Il modulo Cache

La cache contiene la versione piu recente compilata di ogni applicazione. La primavolta che un’applicazione OpenLaszlo viene richiesta, essa viene compilata e il ri-sultante file SWF viene inviato al client. Una copia viene anche memorizzata nellacache del server, in modo tale che altre richieste non richiedano tempi di attesadovuti alla compilazione iniziale.

5.4 Architettura del client OpenLaszlo

La figura 5.3 mostra i moduli che costituiscono l’architettura di un client Open-Laszlo.

Figura 5.3. Architettura del client OpenLaszlo

Sostanzialmente si possono notare 2 blocchi principali, ovvero:

1. OpenLaszlo Runtime Library (ORL): una libreria essenziale che viene compi-lata e inglobata in ogni applicazione e che fornisce i servizi run-time, quali adesempio funzioni timer e di attesa.

47


2. Presentation Renderer: fornisce il rendering della grafica 2D e la riproduzionedel suono. Nessuna di queste classi dipende dai servizi Flash o usa il modelload oggetti di Flash. Il player Flash e usato esclusivamente come motore direndering.

Si prenda in considerazione il seguente esempio di applicazione vuota:

<canvas/>

Quando questa banalissima applicazione e in esecuzione, sebbene non faccia nul-la, mantiene una connessione con il server e tutte le potenzialita necessarie per ilfunzionamento dell’applicazione LZX sono state effettivamente scaricate.

Ci sono 4 principali componenti che costituiscono la libreria runtime OpenLaszlo,indicata con la sigla ORL:

1. il modulo Event System;

2. il modulo Data Loader/Binder;

3. il modulo Layout e Animation System;

4. il modulo OpenLaszlo Services System.

Il modulo Event System

E responsabile della rilevazione e della gestione degli eventi a cui puo essere soggettal’applicazione LZX, come ad esempio la pressione del tasto del mouse o la ricezionedei dati inviati dal server a seguito di una richiesta asincrona del client. E dasottolineare il meccanismo asincrono tra client e server: il server invia solo i datirichiesti e il client effettua una visualizzazione dinamica e fluida solo della parteinteressata.

Il modulo Data Loader/Binder

Ha la funzione di gestire il flusso del traffico di dati, compreso quello provenientedalla rete, in quanto effettua l’associazione delle informazioni richieste con il corri-spondente componente dell’interfaccia utente, quale ad esempio un campo di testo,un form o gli elementi di un menu.

48

5.5 – Messa in linea di un’applicazione

Il modulo Layout e Animation System

Consente la gestione della grafica dell’applicazione LZX, ovvero la gestione del po-sizionamento degli oggetti in maniera relativa (ad esempio posizione centrata, di-sposizione degli elementi lungo l’asse orizzontale e cosı via) o assoluta (indicandole coordinate x e y in pixel). Grazie ad algoritmi di animazione, e possibile crea-re interfacce dinamiche, ovvero e possibile gestire sia il movimento degli oggetti chel’aggiornamento degli stessi in maniera fluida a seguito di cambiamenti del loro stato(come ad esempio lo spostamento di una finestra o il popolamento di un menu).

Il modulo OpenLaszlo Services System

La libreria runtime include anche supporto per timer, suono e finestre di dialogo.

5.5 Messa in linea di un’applicazione

Un’applicazione OpenLaszlo puo essere resa disponibile sul web (operazione di de-ploy) in due modalita:

1. modalita “Proxied”. Il server OpenLaszlo gira sulla macchina dello sviluppa-tore e:

• compila i programmi sorgenti, effettua l’operazione di link con le varielibrerie e invia il risultante codice binario per essere eseguito sul client;

• gestisce le interazioni fra il client e gli altri server su internet, in manieratrasparente allo sviluppatore.

2. Modalita SOLO (Standalon OpenLaszlo Output) o serverless. Viene sfruttatoil compilatore di OpenLaszlo per precompilare il sorgente e rendere disponi-bile il file binario sul server. Quando avviene l’esecuzione sul browser, l’ap-plicazione contatta direttamente gli altri server senza la mediazione del serverOpenLaszlo.

Quindi, un’applicazione LZX messa in linea in modalita “Proxied” puo fare solopoche operazione in piu di un’applicazione resa disponibile in modalita “SOLO”,come ad esempio la gestione delle chiamate remote (Java RPC, SOAP RPC e XMLRPC). Ma l’operazione di deploy della prima tipologia e piu complessa e di solitole prestazioni sono piu lente. Quindi, la seconda tipologia permette un’operazionedi deploy piu semplice e con migliori prestazioni. Nella maggior parte dei casi, ladecisione della modalita di deploy puo essere presa anche solo nel momento stessoin cui l’applicazione LZX debba essere resa disponibile in linea. Di solito, salvo

49


la necessita di utilizzare le funzionalita dette sopra, la scelta ricade sulla modalita“SOLO” e bisogna tenere conto, quindi, che non sono disponibili le funzionalita deimoduli Media Transcoding e Persistent Connection Manager.

5.6 Richiesta di un’applicazione LZX

Il diagramma di flusso della figura 5.4 illustra i vari passi effettuati lato client e latoserver quando un’utente richiede un’applicazione LZX messa in linea in modalitaproxied.

In un’applicazione OpenLaszlo, lo strato “presentation-related logic” e separa-to dallo strato “business logic” e viene eseguito localmente sul client. Il serverOpenLaszlo invia al client dati binari compressi piuttosto che testo, riducendo cosıla quantita di traffico in confronto ad altre applicazione web basate su HTML.Sia il server che il client sfruttano il meccanismo di caching, eliminando cosıtrasmissioni di dati ed esecuzione di codice non necessarie.

5.7 Caratteristiche supportate dalla piattaforma

5.7.1 Modello di Sicurezza

La piattaforma OpenLaszlo supporta il modello di sicurezza SSL. La trasmissionedati attraverso la rete Internet puo essere criptata utilizzando il meccanismo dicodifica SSL su canale HTTPS. Inoltre, le applicazioni vengono eseguite su un clientmediante uno strato intermedio costituito dal Player Flash, ritenuto sicuro, in quantonon permette l’accesso al file system. I web service e i database usati dal server sonoritenuti sicuri, in quanto viene utilizzato un modello di autenticazione per utente.Questo meccanismo previene l’utilizzo del server come proxy o gateway insicuro perfornire servizi o tramettere dati.

5.7.2 Supporto della piattaforma per dispositivi differenti

L’architettura OpenLaszlo e progettata per supportare tipi di dispositivi differen-ti. Viene sfruttato un meccanismo dinamico per la gestione del layout che abilitasemplici modifiche ad alcune proprieta, quali ad esempio un ridimensionamento in-telligente dell’applicazione per adattarsi in modo semplice alle differenti capacitadello schermo a disposizione dell’utente. Tale peculiarita viene anche definita come“interfaccia liquida”.

Il supporto verso dispositivi e sistemi operativi differenti e legato alla disponibi-lita dell’ambiente run-time utilizzato verso i medesimi.

50

5.7 – Caratteristiche supportate dalla piattaforma

Figura 5.4. Interazione fra client e server OpenLaszlo

51


La visualizzazione di un’applicativo su qualsiasi tipologia di schermo e legata adanimazioni basate sul tempo piuttosto che sui frame e percio risulta piu trasparenteadattarsi alle differenti velocita dei processori. Quindi, una determinata transizionedell’interfaccia che richiede 500 ms, impieghera 500 ms senza tenere conto del numerodi frame mostrati, ovvero processori piu veloci visualizzeranno piu frame al secondoe l’animazione risultera piu fluida, ma la durata sara sempre la stessa.

5.7.3 Accessibilita

OpenLaszlo fornisce parziale supporto per le specifiche Microsoft Active Accessibi-lity, ovvero usando tale tecnologia e seguendo le regole di accessibilita e possibileper gli sviluppatori progettare applicazioni per Windows che possono essere utiliz-zate anche da persone con disabilita visive, uditive e motorie. Questo supporto haancora delle limitazioni, in quanto richiede l’installazione di software di terze partisul computer client ed e solo disponibile per ambiente Flash Player per il browserInternet Explorer.

5.8 Il Linguaggio LZX

Il linguaggio LZX, basato su tag ed orientato agli oggetti, utilizza la sintassi delcodice XML e JavaScript per creare l’Interfaccia Utente Grafica (GUI) delle RichInternet Application (RIA).

Vengono illustrati, di seguito, gli aspetti piu significativi del linguaggio LZXrelativi allo svolgimento di questo lavoro di tesi.

Per una introduzione e per chiarimenti su questo linguaggio, che esulerebberodagli obiettivi di questa sezione, si rimanda ai manuali presenti su Internet agliindirizzi [18] e [19].

Costruzione di una tabella

Mediante gli elementi <grid> e <gridcolumn> e possibile gestire dati in tabella. Idati sono formatatti in XML e possono essere sia interni al codice, come in questoesempio, sia su file caricato in remoto o in locale.

<canvas title="tabella.lzx" width="500" height="400">

<dataset name="contatti">

<contatto email="[email protected]">Davide</contatto>

<contatto email="[email protected]">Andrea</contatto>

52

5.8 – Il Linguaggio LZX

<contatto email="[email protected]">Fabrizio</contatto>

<contatto email="[email protected]">Sara</contatto>

<contatto email="[email protected]">Ambra</contatto>

<contatto email="[email protected]">Daniele</contatto>

...

<contatto email="[email protected]">Alberto</contatto>

</dataset>

<view x="30" y="30">

<simplelayout spacing="10" />

<view>

<simplelayout axis="x" spacing="10" />

<button onclick="tabella.clearSort();"> clear Sort </button>

<button onclick="tabella.clearSelection();">

clear Selection </button>

</view>

<grid id="tabella" datapath="contatti:/">

<gridcolumn id="idNo"> No.

<text datapath="position()" />

</gridcolumn>

<gridcolumn id="idcontatto" width="120"> Nome contatto

<text datapath="text()" />

</gridcolumn>

<gridcolumn id="idemail" width="150"> e-mail

<text id="idemailTesto" datapath="@email" />

</gridcolumn>

<method name="contarighe">

num_righe.setText(tabella.getNumItems());

</method>

</grid>

<view>

<simplelayout axis="x" spacing="10" />

<text text="No. Rows Grid: " fontstyle="italic" />

<text id="num_righe" text="${tabella.getNumItems()}"

fontstyle="bold" onclick="tabella.contarighe()" />

</view>

</view>

</canvas>

53


Il popolamento della tabella avviene mediante notazione XPath (attributo datapath).Su un browser, i dati vengono visualizzati come mostrato in figura 5.5.

Figura 5.5. Tabella mediante codice LZX

Gestione dinamica delle finestre e tooltip

La creazione di finestre viene gestita in LZX mediante la creazione di una classe chedefinisce la struttura della finestra stessa e l’operatore new() che la alloca.

Non esiste invece il componente tooltip che viene creato artificialmente con l’ele-mento <view>.

...

<class name="PopupWindowIPC" extends="window" width="160" height="100">

<view name="viewPopup" x="10" y="10" width="${parent.width - 20}">

<simplelayout axis="y" spacing="10" />

<text name="sTit" width="${immediateparent.width - 20}"

multiline="true" fontstyle="bold" />

54


<text name="sSottoTit" width="${immediateparent.width - 20}"

multiline="true" />

<button x="${parent.width/2 - this.width/2}" style="bluecolors"

onclick="parent.parent.close()"> close </button>

</view>

<vscrollbar />

</class>

<view id="tooltipIPC" visible="false" bgcolor="yellow">

<simplelayout axis="y" />

<text name="codice" width="200" multiline="true" fgcolor="black" />

<text name="titolo" width="200" multiline="true" fgcolor="blue" />

</view>

...

<gridcolumn id="ipc" width="105" minwidth="75" sortable="false">IPC

<view width="${parent.width}" height="75" clip="true">

<view>

<simplelayout axis="y" spacing="5" />

<text name="testoID" datapath="ipc/id/text()"

width="100" fgcolor="blue">

<handler name="onclick">

// navigazione per cercare le info volute

var codice = this.getText();

var titolo = ’IPC Description: ’ + codice;

var pointer=patentData.getPointer();

var vettID =pointer.xpathQuery(’patentData:/

Intellisemantic/patent/ipc/id/text()’);

var vettTitolo = this.datapath(’patentData:/

Intellisemantic/patent/ipc/title/text()’);

var vettSottoTit = this.datapath(’patentData:/

Intellisemantic/patent/ipc/subtitle/text()’);

var finestraIPC = new PopupWindowIPC(resultWin,

{title:titolo, height:350, width:450,

style:bluecolors, resizable:true, closeable:true});

finestraIPC.viewPopup.sTit.setText(str);

finestraIPC.viewPopup.sSottoTit.addText(substr);

</handler>

55


<handler name="onmouseover">

tooltipIPC.setX(canvas.getMouse("x") - 250);

tooltipIPC.setY(canvas.getMouse("y") - 50 );

tooltipIPC.setVisible(true);

tooltipIPC.bringToFront();

tooltipIPC.codice.setText(titolo + ’\n’);

tooltipIPC.titolo.setText(str);

</handler>

<handler name="onmouseout">

tooltipIPC.setVisible(false);

</handler>

</view>

<vscrollbar/>

</view>

</gridcolumn>

Si ottiene un’applicativo come mostrato in figura 5.6.

Figura 5.6. Finestre e tooltip in OpenLaszlo

56

Web Service (SOAP)

La porzione di codice che segue, illustra come usare ed invocare un web service daparte di un’applicazione LZX.



<canvas debug="true" height="768" width="1024" bgcolor="0xeaeaea">

<debug x="10" y="200" width="600" height="200" />

<dataset name="risultatoRicerca" />

<soap name="google" wsdl="http://api.google.com/GoogleSearch.wsdl">

<handler name="onload">

Debug.write(’Servizio SOAP di Google: CARICATO! :-)’);

Debug.write(’"WSDL SOAP operations" e "proxy stubs"’);

Debug.write(’GoogleSearch WSDL @ ’ + this.wsdl);

Debug.write(’proxy:’);

Debug.inspect(this.proxy);

Debug.write(’google soap service loaded’);

Debug.write(’----------------’);

</handler>

<handler name="onerror" args="error">

Debug.write(’Errore/i rilevato/i:’, error);

</handler>



<remotecall name="ricerca" funcname="doSpellingSuggestion"

dataobject="risultatoRicerca">



<param value="’2TKUw4ZQFHJ84ByemZK0EXV0Lj+7xGOx’" />

<param value="${ stringa.text }" />

<handler name="ondata" args="value">

Debug.write(’Risultato della ricerca:\n’, value);

</handler>

</remotecall>

</soap>

<view x="10" y="10" layout="spacing: 15">

<view font="Times New Roman" fontsize="20">

57


<text> <b>Google Spelling Suggestion:

</b> <i>inserire la parola da compitare...</i> </text>

</view>

<view layout="axis: x; spacing: 5">

<edittext id="stringa" width="305" text="hapy birttday" />

<button text="suggerisci"

onclick="Debug.write(’Attendere: richiesta inoltrata...’);

google.ricerca.invoke()" />

</view>

<view width="400" height="50"

bgcolor="silver" layout="axis: y" >

<text width="375" fontsize="14" fgcolor="red"

datapath="risultatoRicerca:/text()" />

</view>

</view>

</canvas>

Cio che si visualizza su un browser, viene illustrato dalla figura 5.7.

Figura 5.7. Esempio di utilizzo di web service mediante codice LZX

58


Capacita di adattamento alle varie risoluzioni dello schermo(Interfaccia liquida)

Per questo scopo e necessario creare la propria applicazione come un file di li-breria (elemento <library>), anziche come normalmente viene fatto all’internodell’elemento <canvas>.

mainApplication.lzx:

<library>

<tabslider width="$once{canvas.width - 20}" x="10" y="10"

height="$once{canvas.height - 20}"

spacing="2" slideduration="300">

<tabelement name="one" text="Tabelement One"/>

<tabelement name="two" text="Tabelement Two"/>

<tabelement name="three" text="Tabelement Three"/>

</tabslider>

</library>

Successivamente e necessario creare file multipli, uno per ogni tipologia di riso-luzione che si intende supportare.

mainApplication640.lzx:

<canvas width="640" height="480">

<include href="mainApplication.lzx"/>

</canvas>




</canvas>




</canvas>




</canvas>

59

Per un utilizzo effettivo di tale applicativo, e richiesto aggiungere del codiceJavaScript per effettuare il controllo in maniera automatica della risoluzione delloschemo e scegliere cosı correttamente le dimensioni del <canvas> quando un utentevi accede.



<script type="text/javascript">

var screenW = screen.width;

var screenH =0;

switch (true) {

case (screenW >= 1280):

screenW = 1280;

screenH = 1024;

break;


screenW = 1024;

screenH = 768;

break;


screenW = 800;

screenH = 600;

break;

default:

screenW = 640;

screenH = 480;

break;

}

lzEmbed({url: ’mainApplication’+screenW+’.lzx?lzt=swf’,

bgcolor: ’#394660’, width: screenW, height: screenH});

</script>

60


A titolo di esempio, nella figura 5.8, si riportano due schermate con risoluzionidifferenti.

Figura 5.8. Risoluzione 1024 x 768 (sinistra) a confronto con 1280x1024 (destra)

In alternativa, in base alla tipologia di struttura che si vuole dare all’applicazione,e possibile gestire il layout di un applicativo LZX in maniera dinamica e flessibile,mediante riferimenti relativi e in percentuale, come mostrato nell’esempio seguente.

<canvas height="100%" width="100%">

<window x="20" y="20" width="80%" height="80%"

title="Una semplice finestra" resizable="true"

align="center" valign="middle">

<simplelayout axis="y" spacing="10"/>

<view bgcolor="#bdbdbd"

width="${parent.width}"

height="${this.buttons.refButton.height + 8}">

<view name="buttons" valign="middle">

<simplelayout axis="x" spacing="5"/>

<button name="refButton">Bottone 1</button>

<button>Bottone 2</button>

<button>Bottone 3</button>

</view>

</view>

<text>Prima linea di testo.</text>

<text>Altra linea di testo.</text>

61


<button x="${(immediateparent.width / 2) - (this.width / 2)}"

onclick="this.setAttribute(’width’,

this.getAttribute(’width’) + 10);">

Bottone

</button>

</window>

</canvas>

In base alla dimensione della finestra del browser, i risultati che si ottengonosono riportati nella figura 5.9.

Figura 5.9. Finestra del browser ridimensionata (sinistra) e successiva-mente allargata (destra)

62

Capitolo 6

Caso di studio: GUI diIntelliPatent 4.0

6.1 Requisiti

Dopo un’analisi delle caratteristiche richieste dagli applicativi web, in particolarequelli di ricerca brevettuale, e viste anche le problematiche del software Intelli-Patent 3.5, si richiede che la nuova versione dell’interfaccia utente grafica soddisfi irequisiti elencati di seguito.

Requisiti sull’usabilita

• Funzionalita RIA. Necessita di gestire le richieste dell’utente in manieraasincrona, evitando il caricamento di tutta la pagina ad ogni interazione eottenendo cosı un’interfaccia grafica che cambia stato con continuita visua-le. Oltre ad un effetto grafico gradevole, il non ricaricamento della paginaconsentirebbe all’utente di continuare il suo lavoro senza interruzioni.

• Velocita di ricerca. Una caratteristica fondamentale di un’interfaccia di ri-cerca e quella di poter fornire nel piu breve tempo possibile i risultati. Perridurre il tempo d’attesa, si rende necessario l’implementazione di un mecca-nismo di caricamento dei dati di una riga alla volta man mano che i dati stessivengono trovati.

• Interattivita. Consentire all’utente l’utilizzo dei dati man mano che vengonocaricati, come ad esempio il salvataggio delle informazioni in diversi formati oil confronto di esse mediante l’apertura di piu finestre contemporaneamente.

63

6 – Caso di studio: GUI di IntelliPatent 4.0

• Intuitivita. Offrire un’interfaccia molto simile a quelle usate per il desktop econ funzionalita semplici e intuitive, al fine di poter fare usufrire l’applicazionead un utenza poco esperta nel settore informatico.

• Facilita d’uso. Rendere usabile la visualizzazione dei dati su video, organiz-zandoli in tabelle e finestre che agevolano sia la consultazione sia il confrontodelle informazioni stesse.

• Interfaccia liquida. Adattare le dimensioni dell’interfaccia alle differenticapacita dello schermo a disposizione dell’utente per ottimizzare l’usabilitadell’applicativo stesso.

Requisiti sull’accessibilita

• Accessibilita hardware e software. Obiettivo del progetto e realizza-re un’applicativo che non sia vincolato dal sistema operativo o dal browserutilizzato al lato client.

• Accessibilita fisica. Non sono richieste particolari esigenze, ma il rispettodi determinate normative permetterebbe di rendere il contenuto navigabile efruibile a un maggior gruppo di utenti.

Requisiti sulle funzionalita

• Funzionalita dell’applicativo. Per una migliore fruizione del servizio, sirende necesssario implementare varie funzionalita, quali funzioni di filtro perrestringere i risultati della ricerca effettuata, funzione di ordinamento per variecolonne e salvataggio dei dati in vari formati.

• Facilita di manutenzione. Ottenere un programma organizzato in manieramodulare, con parti di codice riutilizzabili e soprattutto la cui interfaccia gra-fica sia disaccoppiata dalla logica di business. Qualora si rendesse necessarioritoccare la procedura, lo si potra fare agendo in un punto solo con evidentivantaggi in termini di tempo e di affidabilita.

6.2 Scelta delle tecnologie

E importante notare come AJAX non sia precisamente definito. Un frameworkAJAX e il motore che permette ad un sito o ad un applicativo web di sfruttare glieffetti della tecnologia asincrona AJAX ormai sempre piu presenti nei siti denomina-ti Web 2.0. Di framework AJAX ne esistono diversi e ne nasceranno sempre di piu,

64

6.2 – Scelta delle tecnologie

in quanto si tratta di un linguaggio libero e alla portata di molti programmatori.Tra i vari si puo nominare Dojo toolkit, Prototype, OpenRico e Scriptaculous, mal’elenco sarebbe davvero molto lungo. Ogni framework AJAX possiede la proprialibreria implementata con JavaScript asincrono. La differenza principale sta nel ri-sultato finale, cioe nel tipo di effetto grafico che si puo ottenere e nei componentimessi a disposizione. Ma l’aspetto piu importante consiste nella leggerezza di esecu-zione dello script. Infatti, benche si pensi che sia solo codice, alcuni di questi effettinon agevolano la velocita di un sito, ovvero non ne favoriscono il caricamento. Cioe dovuto al fatto che questi effetti sono caratterizzati da parecchie linee di codicee troppo codice JavaScript appesantisce il lavoro della CPU. La conseguenza ine-vitabile e che le pagine web possono soffrire ritardi di alcuni secondi. Piu un sitoo un applicativo web e complesso e piu tale problematica diventa rilevante. Dallato della programmazione, si puo osservare la mancanza di un ambiente di sviluppoparagonabile a quello di altri linguaggi di programmazione, ovvero un ambiente chefaciliti lo sviluppo e il debug delle Rich Internet Application.

La figura 6.1 mostra le differenze tra lo stack software di un applicativo scritto inDHTML con le funzionalita del linguaggio JavaScript asincrono e lo stack softwaredell’ambiente OpenLaszlo.

Figura 6.1. Confronto tra lo stack DHTML e quello di OpenLaszlo

L’ambiente di sviluppo del progetto OpenLaszlo, utilizzato per implementare lanuova interfaccia di IntelliPatent, comprende le seguenti caratteristiche:

65


• piattaforma open source nata principalmente per lo sviluppo di applicazioni,la cui installazione comprende un ambiente completo di server, librerie e stru-menti per rilevazione di errori di sintassi nel codice sorgente e per il debugdell’applicativo;

• vari ambienti di editing con funzionalita che facilitano la scrittura del codicesorgente;

• portabilita su ogni browser (a differenza del DHTML) e architettura pensataper adattarsi ad ambienti multipli di resa runtime;

• presenza di vari esempi di applicativi con codice sorgente disponibile;

• presenza di componenti e funzionalita richieste per la GUI di IntelliPatent.

6.3 Progettazione: implementazione mediante Open-

Laszlo

Di seguito vengono illustrati gli aspetti piu significativi riguardanti l’implementazio-ne di IntelliPatent 4.0, le principali problematiche affrontate e le relative soluzioniadottate per la realizzazione della GUI.

Struttura della GUI

Viste le varie funzionalita che l’interfaccia utente deve gestire, una soluzione usabilee quella di suddividere l’applicativo in 5 finestre differenti, le cui interazioni conl’utente sono mostrate in figura 6.2.

L’interfaccia e, quindi, implementata su 5 pagine LZX, le cui funzionalita sonodescritte nella tabella 6.1.

Le pagine LZX possono essere richiamate da pagine JSP (Java Server Pages).Questa soluzione permette di gestire le pagine da caricare in maniera piu efficiente,ovvero:

• e possibile disabilitare le funzionalita del browser, quali ad esempio i pulsanti“avanti” e “indietro” o il tasto di“ricaricamento pagina”. Come spiegato nel-la sottosezione 4.5.2 a pagina 37, l’utilizzo di tali funzioni in un applicativoasincrono potrebbe portare l’utente a disorientarsi, in quanto non otterrebbeil risultato desiderato. Inoltre, un’applicativo come IntelliPatent e dotato ditutte le funzioni di cui un utente necessita per lavorare e le funzioni del brow-ser porterebbero a compiere azioni non corrette o inutili per interagire con laGUI.

66

6.3 – Progettazione: implementazione mediante OpenLaszlo

Figura 6.2. Diagramma di interazione dell’utente con la GUI di IntelliPatent 4.0

Pagina DescrizioneLOGIN pagina per accedere all’applicativo mediante autentica-

zioneSEARCH pagina che gestisce il form di ricercaRESULT pagina che gestisce i risultati ricercati mediante tabelle

e finestreALERT pagina che permette la ricerca in tempo differito

mediante segnalazione con e-mailalertRESULT pagina che gestisce i risultati ricercati tramite ALERT

(simile alla pagina RESULT)

Tabella 6.1. Organizzazione delle pagine della GUI

67


• E possibile mediante l’attributo hidden nascondere i dati passati tra le variepagine dell’applicazione, ovvero tutte le variabili passate mediante il metodoHTTP GET non saranno visibili sulla barra degli indirizzi del browser, ottenendocosı una garanzia di sicurezza e riservatezza dei dati.

• E possibile inserire comandi che permettono di controllare la presenza delplugin Flash, agevolando cosı l’utente nella rilevazione e installazione delcomponente mancante.

Viene riportato di seguito il codice della pagina JSP che richiama il file login.lzx.Il codice JSP delle altre 4 pagine e analogo.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="it">

<%@ page language="java" contentType="text/html"%>

<%@page import="java.net.URLEncoder"%>

<html>

<head>

<meta http-equiv="content-type" content="text/html;

charset=windows-1250">

<meta name="generator" content="PSPad editor, www.pspad.com">

<title>

</title>

</head>

<body>

<%

String strData="login.lzx?lzt=swf&lzr=swf7&debug=false";

if (request.getParameter("Error") != null) {

strData += "&Error=" + request.getParameter("Error");

}

%>

<table align="center">

<tr valign="middle">

<td align="center">

<object type="application/x-shockwave-flash"

data="<%=strData%>" width="800" height="600">

<param name="movie" value="<%=strData%>" />

<param name="quality" value="high" />

68


<param name="scale" value="noscale" />

<param name="salign" value="LT" />

<param name="menu" value="false" />

<param name="pluginspage"

value="http://www.macromedia.com/go/getflashplayer" />

</object>

</td>

</tr>

</table>

</body>

</html>

Interazione con il Web Service (SOAP)

Alcune funzionalita dell’interfaccia utente sono rese disponibili grazie all’invocazionedelle funzioni di un web service mediante il protocollo SOAP. Tale web service e statorealizzato dall’azienda IntelliSemantic e costituisce la logica di business.

A titolo di esempio, si riporta il codice delle operazioni di login e di logout. Questeinterazioni della GUI con il web service sono necessarie per gestire correttamente lasessione di un utente.

Il codice dell’operazione di login garantisce l’autenticazione dell’utente.


<remotecall name="getIDutente" funcname="login" dataobject="userData">

<handler name="ondata">

// navigazione per cercare le info volute

pointer=userData.getPointer();

idSession = pointer.xpathQuery(’userData:/

Intellisemantic/login/text()’);

// qui sotto viene gestito errore login

<![CDATA[

if (idSession == - 1 )

loginMsg.setText(’Username or password not correct!’);

else{

if (idSession == -2)

loginMsg.setText(’Too much concurrent access

for this login!’);

69


else{

if (idSession == -3)

loginMsg.setText(’Login expired - called

Intellisemantic s.r.l.’);

else{

LzBrowser.loadURL(’search.jsp?idSession=’ + idSession);

}

}

]]>

</handler>

</remotecall>

Invece, l’operazione di logout garantisce la corretta deallocazione dello spazio dimemoria riservato all’utente connesso, liberando cosı spazio sul server.


<remotecall name="logout" funcname="logout" dataobject="Logout">

<handler name="ontimeout" args="errorTimeOut">

patent.logout.invoke([idSession]);

</handler>


var perror = Logout.getPointer();

var errore = perror.xpathQuery(’Logout:/

Intellisemantic/error[1]/text()’);

if(errore!=null){

alertError.setAttribute(’text’,"Logout:"+errore);

alertError.open();

}else{

LzBrowser.loadURL(’index.jsp’);

}

</handler>

</remotecall>

Il diagramma di interazione tra client e server per gestire le operazioni di login edi logout viene riportato nella figura 6.3.

70


Figura 6.3. Gestione del login e del logout

Gestione dell’autenticazione delle sessioni

Una delle funzionalita richieste e quella di gestire l’autenticazione dell’utente nellevarie pagine dell’interfaccia, evitando cosı tentativi di accesso alle varie finestre diIntelliPatent, forzandone il caricamento senza aver effettuato l’operazione di login.Questo problema e stato risolto utilizzando un identificativo di sessione (idSession),il quale e un numero di 20 cifre generato casualmente dal server in fase di login,come illustrato nella sottosezione precedente. Cio rende molto complicato l’accessonon autorizzato alle varie pagine dell’applicativo da parte di utenti non registrati,i quali vengono riportati alla pagina di login. Inoltre, tale identificativo permettedi riconoscere l’utente nelle varie pagine dell’interfaccia, tenendo traccia delle suescelte e dei suoi dati.

71


Il meccanismo di gestione degli accessi non autenticati e illustrato nella figura 6.4.

Figura 6.4. Diagramma di gestione degli accessi non autenticati

Il codice LZX relativo all’implementazione di questa funzionalita e riportato diseguito.

...

<handler name="oninit">

...

idSession = LzBrowser.getInitArg(’idSession’);

if (idSession == undefined ){

LzBrowser.loadURL(’index.jsp?Error=-1’);

...

</handler>

...

<soap name="patent" wsdl="file://IntelliPatentWSMod.wsdl">

<handler name="onload">

Debug.write(’Servizio SOAP di OpenPatentServices: CARICATO! :-)’);

isAlive.invoke([idSession]);

</handler>

...

72



<remotecall name="isAlive" funcname="isAlive" dataobject="dsIsAlive">


Debug.write(’isAlive - Errore:’, error);

</handler>


Debug.write(’isAlive - Timeout:’, errorTimeOut);

patent.isAlive.invoke([idSession]); // re-invio segnale

</handler>


var perror = dsIsAlive.getPointer();

var errore = perror.xpathQuery(’dsIsAlive:/

Intellisemantic/error[1]/text()’);

if(errore!=null){

if(errore=="Invalid session"){

LzBrowser.loadURL(’login.lzx?Error=-1’);

}

}

else{

patent.isAlive.invoke([idSession]);

}

</handler>

</remotecall>

...

</soap>

...

Il diagramma della figura 6.5 chiarisce il meccanismo implementato mediante ilcodice LZX.

Si puo notare come il problema dell’autenticazione viene risolto mediante l’invo-cazione della funzione isAlive(idS) del web service. Tale funzione e utilizzata an-che per gestire la chiusura automatica delle sessione, come spiegato nella sottosezionesuccessiva.

73


Figura 6.5. Meccanismo di gestione degli accessi non autenticati

Gestione della chiusura automatica delle sessioni

Puo accadere che il browser venga chiuso senza aver effettuato l’operazione di logout.Cio comporterebbe un sovraccarico inutile al server, in quanto non si effettuereb-be la deallocazione dello spazio di memoria riservato alla gestione della sessionedell’utente.

Si rende necessario la realizzazione di un meccanismo lato client che periodi-camente invii un segnale al server per indicare che la sessione e ancora attiva. Illinguaggio LZX non permette attualmente di gestire temporizzazioni, pertanto ta-li funzioni devono essere implementate lato server. Il meccanismo di interazionefra client e server e mostrato nella figura 6.6, mentre la parte di codice LZX rela-tiva e stata gia indicata nella sottosezione precedente riguardante la gestione nonautenticata degli accessi.

74


Figura 6.6. Meccanismo per gestire la chiusura automatica della sessione

75


Nelle figure 6.7 e 6.8 vengono analizzati i casi di perdita di segnale da partedel client e del server, dando cosı una valutazione della robustezza dell’algoritmoproposto.

Figura 6.7. Meccanismo per gestire la chiusura automatica della sessione: caso diperdita del segnale lato client

La scelta di un valore maggiore per il secondo timer permette di tollerare laperdita consecutiva di piu segnali isAlive(idS).

76


Figura 6.8. Meccanismo per gestire la chiusura automatica della sessione: caso diperdita del segnale lato server

Invece, la perdita di uno o piu segnali consecutivi lato server non comportaproblemi, in quanto allo scadere del timeout il client invia un nuovo segnale e ilmeccanismo riparte correttamente.

Caricamento dei brevetti

Il caricamento di una riga alla volta delle informazioni in tabella non e una fun-zione nativamente supportata dall’ambiente OpenLaszlo, ma non per questo proi-bita. Questa funzionalita si ottiene grazie alla gestione asincrona delle chiamateremote al web service da parte del linguaggio LZX, che consente di non effettuare ilcaricamento di tutta la pagina, ma bensı l’aggiornamento della sola parte interessata.

77

La parte di codice che realizza tale meccanismo implementato ad hoc e riportatodi seguito.



<dataset name="nextPatent" />

...


<remotecall name="getNextPatent" funcname="getNextPatent"

dataobject="nextPatent">


patent.getNextPatent.invoke([idSession]);

</handler>



</handler>


// Si prende correttamente il tag da appendere

al dataset globale patentData, il cui puntatore

di riferimento {\‘e} pD_elem creato in precedenza

var pNP = nextPatent.getPointer();

// scende di un livello

var elem_interno = nextPatent.getFirstChild(pNP);

// prende il tag voluto

var patent_elem = elem_interno.getFirstChild(pNP);

// converto in stringa il contenuto del file XML ottenuto

per capire la successiva operazione da fare

var comando = elem_interno.serialize();

// chiamata al next patent se esiste

<![CDATA[

if (!stopSearchFlag){

if( comando.indexOf(erroreTrasm)<0){ // NO errore

if ( comando == wait)

patent.getNextPatent.invoke([idSession]); // richiama

else {

if ( comando != fine) { // {\‘e} un patent

// appende patent al DOM 1

pD_elem.appendChild(patent_elem1);

// appende patent al DOM 2

pD_elem2.appendChild(patent_elem2);

78


contatoreRighe++;

canvas.barraApprox();

// chiamata successiva


}

else { // else STOP

canvas.metCopiaDS();

canvas.populateCombo();

canvas.completaBarraApprox();

flagFine=true;

}

}else{

//Errore di trasmissione dati

var perror = nextPatent.getPointer();

var errore = perror.xpathQuery(’nextPatent:/

Intellisemantic/error/text()’);

alertError2.setAttribute(’text’,errore);

alertError2.setVisible(true);

stopSearch();

stopSearchFlag=true;

}

}

}

]]>

</handler>

</remotecall>

...

L’algoritmo utilizzato si basa su chiamate iterative alla funzione getNextPatentdel web service che ritorna un brevetto alla volta e viene schematizzato dal diagram-ma di flusso della figura 6.9.

79


Figura 6.9. Flow-chart per il caricamento dei brevetti

80


Il risultato che si ottiene sulla GUI di IntelliPatent 4.0 e mostrato nella schermatadella figura 6.10.

Figura 6.10. Caricamento dei brevetti riga per riga

Si puo osservare come sia possibile aprire piu finestre contemporaneamente anchesi fase di caricamento per poter gia lavorare con l’applicativo.

Visualizzazione del file XML

Nel linguaggio LZX non sono supportati comandi per visualizzare il contenuto di unfile XML in maniera formattata. La soluzione piu semplice e quella di demandaretale funzione ad una pagina JSP richiamata dal codice LZX seguente.

<button isdefault="true">View


finestraSave.close();

81


<![CDATA[

var strurl = "viewXML.jsp?idSession="+idSession+"&

type=DOC&fname=getDescription&seed="+seed;

LzBrowser.loadJS("window.open(’" + strurl +"’, ’_blank’," +

"’height=700,width=900,scrollbars=yes’)");

]]>

</handler>

</button>

Si puo osservare come il passaggio dei parametri tra la pagina LZX e JSP avvienemediante il metodo HTTP GET.

Di seguito si riporta il codice relativo alla pagina JSP che svolge tale funzionalita.

<%@page import="org.apache.axis.client.Call"%>

<%@page import="org.apache.axis.client.Service"%>

...

<%

String idSession = request.getParameter("idSession");

String risultato="";

...

if (idSession!=null){

try{

String nameWS = Location+"/IntelliPatent-Laszlo/

services/IntelliPatentWS";

URL endPointWS = new URL(nameWS);

//inizializzazione WS

Service service = new Service();

Call call = (Call)service.createCall();

call.removeAllParameters();

//configurazione parametri WS

call.setTargetEndpointAddress(endPointWS);

if(fname.equals("getResultXML") ||

fname.equals("getResultHTML") ||

fname.equals("getResultSchedulerHTML") ||

fname.equals("getResultSchedulerXML")){

call.addParameter("idSession",

XMLType.XSD_STRING, ParameterMode.IN);

call.setOperationName(fname);

82


call.setReturnType(XMLType.XSD_STRING);

//invocazione WS

risultato = (String)call.invoke(new Object[]{idSession});

}

...

out.write(risultato);

}catch(Exception ex){

out.write("A server error occours!Try again...");

}

}else{

out.write("Invalid Session!");

}

%>

Lo schema di figura 6.11 riporta il principio di funzionamento e il risultatoottenuto.

Figura 6.11. Meccanismo per la visualizzazione di un file XML

83


Salvataggio dei file

Un’altra problematica riscontrata e l’assenza nel linguaggio LZX di comandi per lagestione del file system e, quindi, per il salvataggio dei file. Anche in questo caso lasoluzione e quella di ricorrere all’utilizzo di una pagina JSP richiamata dal seguentecodice LZX.

<button>Save


finestraSave.close();

<![CDATA[

var strurl = "saveas.jsp?idSession="+idSession+"&type=DOC&

fname=getDescription&seed="+seed;

LzBrowser.loadJS("window.open(’" + strurl +"’, ’_blank’," +

"’height=2,width=8’)");

]]>

</handler>

</button>

Di seguito si riporta il codice JSP che effettua il salvataggio dei risultati indivi-duati lavorando con IntelliPatent.

<%@page import="org.apache.axis.client.Call"%>

<%@page import="org.apache.axis.client.Service"%>

...

<script>

function save(str,filename,ext){

if(!document.all){

...

outputStream.init( fp.file, 0x20 | 0x02 |0x08, 0664, 0);

outputStream.write(str, str.length);

outputStream.close();

}else{

if(ext==’.xml’)

str=str.split(’encoding="ISO-8859-1"’).join(" ");

SaveFrame.document.open("text/html","replace");

SaveFrame.document.write(str);

SaveFrame.document.close();

84


SaveFrame.focus();

var file="";

if ( msieversion() > 6 )

file = filename;

else

file = filename + ext;

SaveFrame.document.execCommand(’SaveAs’,false,file);

}

}

</script>

<%

// chiamata al Web Service come nel codice precedente

%>

<html>

<body>

<i>Request in Progress...</i>

<%

String filename="result";

String ext ="";

if (flag){

%>

<%

if (type.equals("XML"))

ext = ".xml";

else{

if (type.equals("DOC"))

ext = ".doc";

else{

ext = ".xls";

}

}

%>

<iframe id="SaveFrame" style="display:none"></iframe>

<script type="text/javascript">

save(’<%=risultato%>’,’<%=filename%>’,’<%=ext%>’);

window.close();

</script>

<%}%>

</body>

</html>

85


Lo schema di figura 6.12 riporta il principio di funzionamento e il risultatoottenuto.

Figura 6.12. Meccanismo per il salvataggio dei file

6.4 Valutazione dei risultati raggiunti

Di seguito vengono riportate delle schermate di come si presenta l’interfaccia utentegrafica realizzata per IntelliPatent 4.0, illustrando i requisiti della sezione 6.1 chesono stati soddisfatti e i punti critici incontrati.

Dopo una schermata di login (figura 6.13), che permette l’autenticazione dell’u-tente, si accede al modulo di ricerca (6.14).

86

6.4 – Valutazione dei risultati raggiunti

Figura 6.13. IntelliPatent 4.0: finestra di LOGIN

Figura 6.14. IntelliPatent 4.0: finestra di SEARCH

Il form di ricerca prevede la presenza di codice JavaScript per il controllo dellacorrettezza della compilazione dei vari campi con eventuale segnalazione dei campimancanti o inesatti. Inoltre, e presente la funzione di cronologia (history) delle variericerche effettuate.

87


Dal menu e possibile selezionare il caricamento della finestra di alert (figura 6.15),per gestire la ricerca in tempo differito tramite segnalazione dell’avvenuta ricercamediante indirizzo e-mail.

Figura 6.15. IntelliPatent 4.0: finestra per la gestione degli ALERT

88


Le schermate con le tabelle dei risultati ottenuti, sia in tempo reale sia in tempodifferito, sono simili e mostrate nelle figure 6.16 e 6.17.

Figura 6.16. IntelliPatent 4.0: prima tabella con i risultati

Per una maggiore comodita di visualizzazione dei dati, le numerose colonne con-tenenti le informazioni brevettuali sono state raggruppate e suddivise in due tabel-le, a loro volta gestite mediante l’uso di schede (tab), eliminando cosı la barra discorrimento orizzontale ritenuta una soluzione poco usabile.

Inoltre, le colonne delle tabelle possono essere ordinate. Questa funzionalita estata sviluppata lato client grazie alle funzioni della libreria fornita da OpenLaszlo.Anche in presenza di molte informazioni ricercate, l’ordinamento delle righe delletabelle risulta veloce.

89


Un’osservazione importante va fatta sulle due tabelle. Esse risultano sincroniz-zate sia nell’ordinamento che nella selezione di una riga, in modo tale da avere levarie righe delle due tabelle sempre correlate fra di loro.

Figura 6.17. IntelliPatent 4.0: seconda tabella con i risultati aggiuntivi

Infine, si puo osservare come sia possibile aprire piu finestre contemporanea-mente per una migliore consultazione e per un facile confronto delle informazionibrevettuali.

90


Le tabelle 6.2, 6.3 e 6.4 riassumono i risultati ottenuti facendo riferimento airequisiti esposti nella sezione 6.1 a pagina 63.

Requisito Risultati ottenutiFunzionalita RIA Questa funzionalita e stata ottenuta grazie al sup-

porto della tecnica AJAX da parte dell’ambienteOpenLaszlo.

Velocita di ricerca L’implementazione del meccanismo di caricamento diuna riga alla volta permette di avere tempi visibil-mente piu brevi per poter accedere alle informazioni,rispetto ad IntelliPatent 3.5.

Interattivita Questa caratteristica e stata notevolmente miglioratanella versione 4.0 di IntelliPatent, grazie all’utilizzodella tecnica AJAX e al meccanismo di caricamentodi una riga alla volta.

Intuitivita Si e realizzata un’interfaccia con aspetto e funziona-lita molto simili a quelli delle applicazioni desktop,per le quali l’utente ha una maggiore esperienza.

Facilita d’uso Sono state prese in considerazione le varie guidelinee best-practice, come indicato dal consorzio W3C.

Interfaccia liquida Data la complessita dell’applicativo realizzato e lamancanza di tempo a disposizione per svolgere que-sta tesi, non e stato possibile implementare questafunzionalita per la GUI di IntelliPatent 4.0. Tutta-via tale funzionalita, supportata dalle librerie Open-Laszlo, e stata inizialmente sperimentata realizzandoun semplice programma di esempio, come illustratoalla sezione 5.8.

Tabella 6.2. Requisiti di usabilita e risultati ottenuti

91


Requisito Risultati ottenutiAccessibilita hardwaree software

Requisito largamente soddisfatto mediante l’uso delplugin Flash. Invece, le funzionalita ottenute median-te codice JSP, cioe la visualizzazione del file XML eil salvataggio dei file, non sono cross-browser. Si de-ve, pertanto, tenere conto dei vari browser utilizzatie inserire le linee di codice opportune. Inizialmentesi sono sviluppate le funzionalita per i browser In-ternet Explorer e Mozilla FireFox, che sono i mag-giormente utilizzati. Per il browser Mozilla FireFoxe stato anche necessario realizzare un plugin che neestende le funzionalita.

Accessibilita fisica Data la mancanza di particolari esigenze non e sta-to al momento raggiunto questo requisito. Tuttavia,alla sottosezione 5.7.3 a pagina 52, e stato indica-to come OpenLaszlo fornisce supporto parziale a talerequisito.

Tabella 6.3. Requisiti di accessibilita e risultati ottenuti

Requisito Risultati ottenutiFunzionalitadell’applicativo

Si sono utilizzate le librerie OpenLaszlo, integrandoil codice LZX con il codice JSP per aggiungere lefunzionalita mancanti, ottenendo una Rich InternetApplication.

Facilita di manuten-zione

L’utilizzo di un web service permette il disacoppia-mento della GUI dal resto del sistema.

Tabella 6.4. Requisiti di funzionalita e risultati ottenuti

92


Altre problematiche incontrate nello sviluppo dell’interfaccia mediante l’ambien-te OpenLaszlo sono elencate nella tabella 6.5.

Problematica DescrizioneLimite del timeout Il server OpenLaszlo presenta un timeout interno di

30000 ms per la gestione delle richieste asincrone fat-te verso altri server. Tale limite e fisso e non puo,pertanto, essere modificato dal programmatore. Ciorende ingestibili richieste che necessitano di lunghitempi di elaborazione a fronte di grandi quantita didati che devono essere restituiti al server OpenLaszlo.Il meccanismo di caricamento di una riga alla voltapermette di aggirare tale limite, in quanto riduce laquantita di informazioni da inviare e, di conseguenza,il tempo per rispondere.

Limiti del file WSDL OpenLaszlo supporta solo documenti WSDL 1.1 enon quelli 2.0. Pertanto, si sono rese necessarie del-le modifiche al file WSDL per poter interagire con ilweb service.

Limite del protocolloSOAP

Il pacchetto SOAP che riceve il client ha una dimen-sione massima limitata a 64 KB, con conseguente per-dita di informazioni nel caso di pacchetti che dovreb-bero essere piu lunghi. Pertanto, per poter riceverequantita maggiori di dati e stato necessario imple-mentare il meccanismo di caricamento di una riga allavolta anche nel caso della ricerca in tempo differito.

Tabella 6.5. Problematiche riscontrate con OpenLaszlo

93

Capitolo 7

Conclusioni

Lo scopo di questo lavoro di tesi e stato quello di affrontare lo studio delle interfacceutente grafiche per il web, sia sotto l’aspetto tecnologico, sia sotto l’aspetto dell’usa-bilita e dell’accessibilita. Successivamente, le conoscenze acquisite e maturate sonostate applicate per la revisione e lo sviluppo della nuova GUI di IntelliPatent.

Come si e discusso fin dai primi capitoli della tesi, la rete Internet non puo piuessere considerata una semplice “rete di reti” o un insieme di siti web isolati e indi-pendenti tra loro, ma bensı la somma delle capacita tecnologiche raggiunte dall’uomonell’ambito della diffusione dell’informazione e della condivisione del sapere. Questesono le considerazioni alla base del cosiddetto “Web 2.0” o “Internet 2.0” che, lungidal rappresentare il culmine dell’evoluzione del mondo Internet negli ultimi diecianni, sono un punto di partenza per nuove metodologie e applicazioni software, al-l’insegna della condivisione e della collaborazione tra esseri umani. Il Web 2.0 non e,quindi, un’evoluzione della tecnologia TCP/IP alla base della Rete, ma rappresen-ta un’insieme di mezzi e strumenti che utilizzano l’infrastruttura tecnologica sullaquale poggia Internet. E un nuovo modo di intendere la Rete, che pone al centro icontenuti, le informazioni e l’interazione. Nascono nuove possibilita di fruizione delsapere e delle informazioni offerte da Internet, dal momento che, oltre ai computer,fanno parte della rete globale altre periferiche, quali il cellulare, la televisione e laradio, che possono interagire tra loro utilizzando le nuove tecnologie di condivisionedell’informazione digitale. Inoltre, il concetto di Web 2.0 pone l’accento sulle capa-cita di condivisione dei dati tra le diverse piattaforme tecnologiche, sia hardware chesoftware. Si e potuto osservare come dietro a queste evoluzioni si trovano tecnologiequali:

• web service;

• API (Application Programming Interface);

• XML;

94

• RSS (RDF Site Summary o Really Simple Syndication);

• e, soprattutto, le tecnologie AJAX.

Il filo conduttore e una nuova filosofia all’insegna della collaborazione, ovverointerazione sociale realizzata grazie alla tecnologia. I servizi e gli strumenti delWeb 2.0 trasformano ogni utente da consumatore a partecipante, da utilizzatorepassivo ad autore attivo di contenuti, messi a disposizione da chiunque si affaccisu Internet, indipendentemente dal dispositivo che utilizza e dalle competenze delsettore informatico.

Le interfacce utente grafiche per il web sono sempre state piu scarne rispetto aquelle per il desktop, con meno funzionalita e interattivita. Grazie a queste inno-vazioni tecnologiche, e possibile conservare le conoscenze acquisite dagli utenti nelcorso delle loro esperienze informatiche, mettendo a disposizione dei veri e propri ap-plicativi fruibili direttamente da Internet, senza inoltre la necessita di installazionee pertanto rivolti ad un’utenza anche poco esperta.

In particolare, AJAX rappresenta la parola chiave che permette di concretizzaregli aspetti sociali del Web 2.0. Inizialmente, si e assistito alla nascita di parecchielibrerie AJAX in maniera molto caotica, con problemi di interoperabilita fra lelibrerie di prima generazione. Grazie al sostegno di importanti aziende e alla nascitadell’organizzazione OpenAjax Alliance, viene garantita l’evoluzione nel tempo diAJAX , man mano che le sue tecnologie miglioreranno e man mano che verrannorilasciati nuovi browser in grado di rispondere alle esigenze degli sviluppatori. OggiAJAX offre una ricca interfaccia utente, simile all’ambiente desktop, con grandicapacita di programmazione di rete e realizzata su standard aperti. Per il futuro,l’alleanza OpenAjax sostiene che i fornitori delle tecnologie alla base di AJAX e iproduttori di browser effettueranno miglioramenti in continuazione e cio aumenterala potenza e le prestazioni a disposizione degli sviluppatori.

OpenLaszlo rappresenta una fra le varie soluzioni open source per lo sviluppodi applicazioni per il web portabili su ogni browser. La piattaforma OpenLaszlo sie rivelata adatta per l’implementazione della GUI di IntelliPatent 4.0, in quanto sibasa su nozioni note per altri linguaggi di programmazione (paradigma orientato aglioggetti, architettura orientata ai servizi e cosı via) e tecnologie standard (JavaScripte XML). Inoltre, la completezza dell’ambiente, come spiegato alla sezione 6.2, ha resoagevole lo sviluppo e il collaudo dell’applicativo. Tuttavia, l’ambiente e ancora in viadi sviluppo e presenta difetti nelle librerie, oltre che limitazioni nelle funzionalitada superare con successivi miglioramenti. Inoltre, il manuale del linguaggio LZXnon si presenta sempre completo e dettagliato in ogni sua parte, soprattutto inalcune spiegazioni sull’utilizzo delle funzioni delle librerie. Comunque, l’ambienteha presentato caratteristiche di interoperabilita, permettendo di integrare il codiceLZX con il codice JSP per implementare le funzioni mancanti e per risolvere in

95

7 – Conclusioni

maniera piu efficiente alcune problematiche riscontrate durante lo sviluppo dellaGUI. Pertanto, si e potuto cosı sviluppare l’applicazione IntelliPatent in tutte le sueparti richieste, aggiungendo, inoltre, delle funzionalita in piu rispetto alla versioneprecedente.

Attualmente l’applicativo IntelliPatent 4.0 viene reso disponibile on-line all’indi-rizzo http://www.intellipatent.eu/ e rappresenta la nuova versione del softwaregestito dall’azienda IntelliSemantic.

Bisogna tenere conto che il progetto OpenLaszlo e ancora oggetto di studio daparte dell’azienda Laszlo Systems e subisce miglioraramenti con l’avanzamento deilavori. Infatti, l’architettura della piattaforma OpenLaszlo e pensata per adattarsiad ambienti multipli di resa runtime (attualmente Flash e ben presto e stato an-nunciato il DHTML). Pertanto, futuri sviluppi del software IntelliPatent possonoconsistere nella compilazione del codice sorgente, che rimane inalterato, per l’am-biente runtime DHTML, oltre che nell’implementazione della caratteristica detta“interfaccia liquida”, requisito che non e stato possibile conseguire per mancanza ditempo.

96

Bibliografia

[1] Robin Good, Cos’e Il Web 2.0: Definizione E Mini-Guida Di Robin Good,7 ottobre 2005, disponibile da:http://www.masternewmedia.org/it/Web 2.0/scopri tutti

gli usi e le occasioni di business del Web 2.0 20050710.htm,[consultato il 12 giugno 2006, presente nel CD allegato].

[2] Tim O’Reilly, What Is Web 2.0, 30 settembre 2005, disponibile da:http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/

what-is-web-20.html,[consultato il 12 giugno 2006, presente nel CD allegato].

[3] Steve Krug, Don’t make me think!, New Riders.

[4] Jakob Nielsen, Designing Web Usability, New Riders.

[5] Homepage Usabile.it, disponibile da:http://www.usabile.it/, [consultato il 26 giugno 2006].

[6] Homepage Web Style Guide, disponibile da:http://www.webstyleguide.com/, [consultato il 26 giugno 2006].

[7] Homepage consorzio W3C, disponibile da:http://www.w3.org/, [consultato il 26 giugno 2006].

[8] Homepage PubbliAccesso.gov.it, disponibile da:http://www.pubbliaccesso.it/, [consultato il 26 giugno 2006].

[9] Jesse James Garrett, Ajax: A New Approach to Web Applications,18 febbraio 2005, disponibile da:http://www.adaptivepath.com/publications/essays/archives/000385.php,[consultato il 17 maggio 2006, presente nel CD allegato].

97

Bibliografia

[10] Linda Dailey Paulson, Building Rich Web Applications with Ajax,IEEE Computer Society, ottobre 2005, disponibile da:http://ieeexplore.ieee.org/,[consultato il 17 maggio 2006, presente nel CD allegato].

[11] Homepage OpenAjax.it, disponibile da:http://www.openajax.it/, [consultato il 17 maggio 2006].

[12] Homepage OpenAjax Alliance, disponibile da:http://www.openajax.org/, [consultato il 1 dicembre 2006].

[13] OpenAjax Alliance, Introducing Ajax and OpenAjax - An OpenAjax AllianceWhite Paper, 7 febbraio 2007, disponibile da:http://www.openajax.org/whitepapers/

Introducing%20Ajax%20and%20OpenAjax.html,[consultato il 19 febbraio 2007, presente nel CD allegato].

[14] OpenAjax Alliance, OpenAjax Hub, disponibile da:http://www.openajax.org/OpenAjax%20Hub.html,[consultato il 19 febbraio 2007, presente nel CD allegato].

[15] Guide JavaScript HTML.IT, disponibili da:http://javascript.html.it/guide/, [consultato il 17 maggio 2006].

[16] Homepage Laszlo Systems, disponibile da:http://www.laszlosystems.com/, [consultato il 19 luglio 2006].

[17] Homepage OpenLaszlo, disponibile da:http://www.openlaszlo.org/, [consultato il 1 agosto 2006].

[18] Laszlo Team, Developer’s Guide (version 3.3.3), Laszlo Systems Inc.,febbraio 2006, disponibile da:http://www.openlaszlo.org/lps/docs/guide/,[consultato il 19 febbraio 2007, presente nel CD allegato].

[19] Laszlo Team, Reference Manual (version 3.3.3), Laszlo Systems Inc.,febbraio 2006, disponibile da:http://www.openlaszlo.org/lps/docs/reference/,[consultato il 19 febbraio 2007, presente nel CD allegato].

98

Progettazione e sviluppo di interfacce web 2 -...

Documents

Transcript of Progettazione e sviluppo di interfacce web 2 -...