Progettazione e sviluppo di interfacce web 2.0

Transcript

1 POLITECNICO DI TORINO Facoltà di Ingegneria dell Informazione Corso di Laurea in Ingegneria Informatica Tesi di Laurea Magistrale Progettazione e sviluppo di interfacce web 2.0 Un caso di studio: ricerca brevettuale Relatore: prof. Fulvio Corno Candidato: Davide Manganaro Aprile 2007

2 Ringraziamenti Alla fine di questo percorso di studi, desidero ringraziare tutti coloro che hanno contribuito, con i loro consigli, allo svolgimento di questo lavoro di tesi, rendendo possibile la realizzazione del progetto trattato nella tesi e permettendomi il raggiungimento di un traguardo importante quale la laurea. La speranza è che questo lavoro di tesi possa essere utile non soltanto a me stesso. Il ringraziamento più speciale va ai miei genitori e a mio fratello, i quali mi hanno sostenuto e incoraggiato in ogni modo durante il faticoso cammino universitario, avendo sempre fiducia nelle mie scelte. 1

3 Indice Ringraziamenti I 1 Introduzione Obiettivi della tesi Motivazioni della revisione della GUI di IntelliPatent Requisiti generali Risultati ottenuti Struttura della tesi Introduzione al Web Che cos è il Web Analisi storica Differenze e confronti con il Web Applicazioni di nuova generazione Interfacce utente grafiche per il web Introduzione Cenni sulle tecnologie usate per le GUI Caratteristiche delle GUI nelle applicazioni web Eterogeneità delle esperienze degli utenti Garanzia di funzionalità Nuovi strumenti offerti per il web Effetti delle GUI sullo sviluppo di un applicazione Bilanciamento delle operazioni Universalità dell interfaccia Universalità degli script I requisiti emergenti dell usabilità del web Le tecnologie AJAX Introduzione: che cos è AJAX e come si colloca nel web Descrizione tecnica e teorica

4 4.3 Introduzione ai fondamenti di AJAX OpenAjax Alliance e framework AJAX Architettura client-side e server side Framework lato client procedurali e dichiarativi Considerazioni lato utente Vantaggi Svantaggi Considerazioni lato server Vantaggi Svantaggi Problematiche relative al tempo di attesa Perdita di una richiesta Gestione dell attesa Rich Internet Application mediante OpenLaszlo Introduzione: che cos è OpenLaszlo Architettura client e server Architettura del server OpenLaszlo Architettura del client OpenLaszlo Messa in linea di un applicazione Richiesta di un applicazione LZX Caratteristiche supportate dalla piattaforma Modello di Sicurezza Supporto della piattaforma per dispositivi differenti Accessibilità Il Linguaggio LZX Caso di studio: GUI di IntelliPatent Requisiti Scelta delle tecnologie Progettazione: implementazione mediante OpenLaszlo Valutazione dei risultati raggiunti Conclusioni 94 Bibliografia 97 3

5 Elenco delle tabelle 1.1 Funzionalità principali dell applicativo IntelliPatent Esempi di applicativi del Web Alcuni toolkit e framework di sviluppo che integrano il supporto del progetto OpenAjax Hub Organizzazione delle pagine della GUI Requisiti di usabilità e risultati ottenuti Requisiti di accessibilità e risultati ottenuti Requisiti di funzionalità e risultati ottenuti Problematiche riscontrate con OpenLaszlo

6 Elenco delle figure 1.1 Finestra di ricerca di IntelliPatent Finestra con la tabella dei risultati di IntelliPatent Caricamento delle informazioni brevettuali con IntelliPatent Confronto dei brevetti con IntelliPatent Immagine rappresentante le caratteristiche del Web Evoluzione tecnologica e sociale del Web L elaboratore di testi IucundeWeb (in secondo piano) e il foglio elettronico NumSum (in primo piano) L applicativo Gliffy, strumento per disegnare vari tipi di flow-chart Schermate di Blogger Architettura three-tier o 3-tier ( a tre strati ) Confronto tra l architettura web a 3 strati (a) e quella a 4 strati (b) Confronto tra il modello di interazione tradizionale delle applicazioni web e il modello AJAX Confronto tra l interazione sincrona client-server e quella asincrona (AJAX) Modello di trasformazione AJAX lato utente Modello di trasformazione AJAX lato server Carico del server con e senza AJAX Rappresentazione di più richieste ad un server con latenza e risposte Indicatori di attesa Architettura client-server OpenLaszlo Architettura del server OpenLaszlo Architettura del client OpenLaszlo Interazione fra client e server OpenLaszlo Tabella mediante codice LZX Finestre e tooltip in OpenLaszlo Esempio di utilizzo di web service mediante codice LZX Risoluzione 1024 x 768 (sinistra) a confronto con 1280x1024 (destra) Finestra del browser ridimensionata (sinistra) e successivamente allargata (destra)

7 6.1 Confronto tra lo stack DHTML e quello di OpenLaszlo Diagramma di interazione dell utente con la GUI di IntelliPatent Gestione del login e del logout Diagramma di gestione degli accessi non autenticati Meccanismo di gestione degli accessi non autenticati Meccanismo per gestire la chiusura automatica della sessione Meccanismo per gestire la chiusura automatica della sessione: caso di perdita del segnale lato client Meccanismo per gestire la chiusura automatica della sessione: caso di perdita del segnale lato server Flow-chart per il caricamento dei brevetti Caricamento dei brevetti riga per riga Meccanismo per la visualizzazione di un file XML Meccanismo per il salvataggio dei file IntelliPatent 4.0: finestra di LOGIN IntelliPatent 4.0: finestra di SEARCH IntelliPatent 4.0: finestra per la gestione degli ALERT IntelliPatent 4.0: prima tabella con i risultati IntelliPatent 4.0: seconda tabella con i risultati aggiuntivi

8 Capitolo 1 Introduzione 1.1 Obiettivi della tesi L attuale sviluppo delle applicazioni B2B 1 distribuite richiede che esse risultino facili da progettare, da mantenere e da usare. I primi due obiettivi possono essere colti disaccoppiando opportunamente l interfaccia utente grafica (GUI) dal resto del sistema e utilizzando soluzioni architetturali quali AJAX e OpenLaszlo. L ultimo obiettivo, invece, implica di seguire ben specifiche guideline e best-practice, come indicato dal consorzio W3C, per ottimizzare l usabilità e per adattarsi in modo semplice alle differenti capacità dello schermo a disposizione dell utente. Quest ultimo requisito viene anche definito con il termine di interfaccia liquida. Nella prima fase dello svolgimento della tesi, pertanto, ho effettuato lo studio dello stato dell arte ed ho effettuato sperimentazioni e valutazioni relative a tutti i punti precedentemente enunciati. In particolare, ho preso in esame lo studio delle tecnologie emergenti AJAX e OpenLaszlo caratterizzanti la nascita del Web 2.0 e che permettono lo sviluppo delle cosiddette Rich Internet Application (RIA), ovvero applicazioni web che hanno le caratteristiche e le funzionalità delle tradizionali applicazioni desktop. Nella seconda fase della tesi, ho proceduto applicando il know-how maturato alla revisione dell architettura e dell implementazione dell interfaccia utente grafica di IntelliPatent 3.5 presso l azienda IntelliSemantic. IntelliSemantic è una società dell incubatore I3P che opera nelle applicazioni di accesso ad informazioni tecnologiche e di mercato utilizzanti la tecnologia semantica 1 Business to Business, spesso abbreviato in B2B, indica le relazioni che un impresa detiene con i propri fornitori per attività di approvvigionamento, di pianificazione e monitoraggio della produzione o di sussidio nelle attività di sviluppo prodotto oppure le relazioni che l impresa detiene con clienti professionali, cioè altre imprese collocate in punti diversi della filiera produttiva. 1

9 1 Introduzione e che ha stabilito una collaborazione con il gruppo di ricerca e-lite del Politecnico di Torino. IntelliPatent è un applicazione web che facilita l accesso e la manipolazione delle informazioni fornite dalla base dati dell European Patent Office (EPO) relative ai brevetti ed è stata sviluppata da IntelliSemantic come servizio ASP Motivazioni della revisione della GUI di Intelli- Patent Un interfaccia utente grafica, come quella di IntelliPatent 3.5, assume un ruolo fondamentale in un sistema software, in quanto mediante essa un utente si relaziona col sistema stesso per reperire informazioni e servizi. Le funzionalità principali, presenti nell applicativo IntelliPatent 3.5, sono riepilogate nella tabella 1.1. Item Funzionalità 1 Modalità di ricerca interattiva e in tempo differito 2 Segnalazione automatica per di nuovi brevetti 3 Ricerca completa di tutte le informazioni riguardanti i brevetti 4 Memorizzazione del profilo di interesse e del profilo d uso dell utente 5 Funzioni di filtro e ordinamento sulla tabella dei risultati individuati 6 Visualizzazione e salvataggio delle informazioni ricercate nel formato XML Tabella 1.1. Funzionalità principali dell applicativo IntelliPatent 3.5 In base alla tipologia di servizio offerto e all utenza che si rivolge, un interfaccia deve, quindi, soddisfare determinati requisiti di usabilità, di accessibilità e di funzionalità. Analisi sull usabilità 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 Application Service Provider (ASP) è un operatore che fornisce ai propri utenti servizi applicativi tramite Internet su linea privata virtuale o su linea pubblica. 2

10 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 pagina HTML sincrona, cioè ad ogni azione l utente si trova davanti una finestra browser vuota e un icona a clessidra, aspettando che il server finisca l elaborazione e restituisca tutta la pagina per intero. È un modello adattato dall uso originale del web come un medio ipertesto, ma ciò che rende il web adatto per l ipertesto non lo rende necessariamente adatto alle applicazioni software. Il secondo ed inevitabile incomodo legato a questo meccanismo tradizionale è l attesa che trascorre tra una richiesta dell utente e la risposta del server. Data la natura sincrona, la tabella con i brevetti ricercati può essere restituita solo quando il server ha completato tutta la ricerca. Così, l utente è costretto ad aspettare parecchi minuti prima di poter consultare ed elaborare le informazioni brevettuali. 3

11 1 Introduzione La figura 1.2 mostra il risultato di una ricerca brevettuale e come le varie informazioni sono organizzate in tabella. Figura 1.2. Finestra con la tabella dei risultati di IntelliPatent 3.5 Si può notare come tali informazioni siano parecchie e la tabella risulti enorme con svariate colonne. Inoltre, la consultazione mediante l uso della barra di scrolling orizzontale non risulta molto agevole come soluzione. Analisi sull accessibilità L utenza, per la quale è rivolto IntelliPatent, è costituita da studi brevettuali e da aziende di vari settori che intendano valutare le evoluzioni tecnologiche del loro settore. Assume molta importanza che l applicativo web sia supportato da vari sistemi operativi e browser. Questa caratteristica viene, in molti casi, supportata da IntelliPatent 3.5, ma l utilizzo di codice cross-browser agevolerebbe lo sviluppo del software da parte del programmatore che non si troverebbe a dover differenziare parti di codice in base ai vari ambienti in cui l applicativo verrebbe utilizzato. Ciò consentirebbe una riduzione dei tempi di sviluppo, di testing e di manutenzione. Per il momento non esistono altre particolari esigenze di accessibilità, caratteristica che in ogni caso rappresenterebbe un valore aggiunto. 4

12 1.3 Requisiti generali Analisi sulle funzionalità Una tipica applicazione web viene di solito realizzata disaccoppiando la parte relativa all interfaccia grafica dalla parte riguardante l elaborazione dei dati che di solito risiede sul server. In tale maniera diviene semplice effettuare cambiamenti alle varie parti del sistema software, in quanto indipendenti fra di loro. L implementazione della versione 3.5 di IntelliPatent non presenta una suddivisione netta dei vari moduli del sistema. Il disaccoppiamento dell interfaccia dal resto del sistema permette anche di alleggerire il server da alcune funzionalità che vengono date in gestione al browser, consentendo così di migliorare la scalabiltà del sistema, ovvero la gestione di un numero più 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 informazioni relative ai brevetti. Questa caratteristica agevolerebbe il lavoro dell utente che altrimenti sarebbe costretto a reperire le varie informazioni relative ad un brevetto da più fonti diverse, dovendo effettuare così più ricerche. Velocità e interattività. La ricerca di brevetti con determinate caratteristiche spesso porta a trovare una grossa quantità di informazioni con conseguenti tempi di attesa lunghi. Un programma che consente di visualizzare le informazioni man mano che vengono trovate, rende tali tempi accettabili e migliora così l interazione con l utente. Usabilità. Caratteristiche fondamentali di un interfaccia sono la semplicità d uso e la chiarezza delle varie funzionalità che si possono adoperare. Oltre all intuitività dell applicativo, data la grossa quantità di dati che spesso si deve trattare, si rende necessaria una presentazione su schermo in una forma comoda per la visualizzazione, la consultazione e il confronto delle informazioni ricercate. Accessibilità Web. Possibilità di fruire delle informazioni presenti nelle pagine da parte del maggior numero possibile di persone, indipendentemente dalle disabilità psico-fisiche e dalle dotazioni hardware e software disponibili. 5

13 1.4 Risultati ottenuti 1 Introduzione Si è sviluppata la versione 4.0 della GUI di IntelliPatent mediante la tecnologia OpenLaszlo su ambiente runtime Flash. L applicativo web realizzato è mostrato in figura 1.3 e presenta tutte le funzionalità della versione precedente, oltre ad ulteriori requisiti raggiunti. Figura 1.3. Caricamento delle informazioni brevettuali con IntelliPatent 4.0 Le peculiarità della nuova interfaccia sono le seguenti: miglioramenti degli aspetti di portabilità e accessibilità, dovuti alla disponibilità del plugin Flash per dispositivi, sistemi operativi e browser differenti; passaggio immediato dal modulo di ricerca alla tabella dei risultati e popolamento di una riga alla volta della tabella man mano che vengono trovati i vari brevetti; consultazione e soprattutto interazione immediata con le informazioni brevettuali ricercate grazie al meccanismo asincrono di interazione tra client e server; tabella compatta e organizzata in maniera tale da rendere più agevole la consultazione; 6

14 1.5 Struttura della tesi la presenza della barra di scrolling verticale sulla tabella anziché solo sulla pagina, permette all utente di avere sempre sotto controllo tutte le funzionalità dell interfaccia; possibilità di confrontare brevetti aprendo più finestre contemporaneamente come mostra la figura 1.4. Figura 1.4. Confronto dei brevetti con IntelliPatent Struttura della tesi Capitolo 2 - Introduzione al Web 2.0. Viene presentata un analisi storica sull evoluzione che ha subito il web dal punto di vista degli aspetti sociali, ma soprattutto dal punto di vista tecnologico. Capitolo 3 - Interfacce utente grafiche per il web. Si effettua il punto dello stato dell arte e si analizza l architettura della GUI sia sotto l aspetto tecnologico, sia sotto l aspetto dell accessibilità e dell usabilità. Capitolo 4 - Le tecnologie AJAX. Viene affrontato lo studio della tecnica AJAX per la realizzazione di siti e applicativi web, fornendo un analisi sugli aspetti positivi e negativi introdotti dal suo utilizzo. 7

15 1 Introduzione Capitolo 5 - Rich Internet Application mediante OpenLaszlo. Si analizza questa tecnologia open per creare RIA (Rich Internet Application). Capitolo 6 - Caso di studio: GUI di IntelliPatent 4.0. Viene applicato il know-how maturato alla revisione dell architettura e dell implementazione dell interfaccia utente grafica di IntelliPatent. Capitolo 7 - Conclusioni. Si effettuano delle valutazioni sui vari argomenti trattati e si traggono delle conclusioni sul lavoro sviluppato. 8

16 Capitolo 2 Introduzione al Web Che cos è il Web 2.0 Con il nome Web 2.0 o Internet 2.0 si intende un generico stato di evoluzione di Internet 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 interfaccia, facilità e velocità d uso tali da renderli simili alle applicazioni tradizionali che 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 questa tecnica per essere semplice e veloce. I propositori del termine Web 2.0 affermano che questo differisce dal concetto iniziale di web, retroattivamente etichettato Web 1.0, perché si discosta dai classici 9

17 2 Introduzione al Web 2.0 siti web statici, dall , dall uso dei motori di ricerca, dalla navigazione lineare e propone un World Wide Web più 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 ciò che i propositori decidono che debba significare per cercare di convincere i media e gli investitori che stanno creando qualcosa di nuovo e migliore, invece di continuare a sviluppare le tecnologie esistenti. 2.2 Analisi storica Originariamente il web è stato concepito come modo per visualizzare documenti ipertestuali statici (creati con l uso del linguaggio HTML). Questo approccio può essere definito come Web 1.0. In seguito, grazie all integrazione con database e all utilizzo di sistemi di gestione dei contenuti (CMS), Internet si è evoluta con siti dinamici (come ad esempio i forum o i blog). Questo web dinamico è 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 elementi dinamici e dei fogli di stile (CSS) per gli aspetti grafici, si possono creare delle vere e proprie applicazioni web che si discostano dal vecchio concetto di semplice ipertesto e che puntano a somigliare ad applicazioni tradizionali per computer. Da un punto di vista strettamente tecnologico, il Web 2.0 è del tutto equivalente al Web 1.0, in quanto l infrastruttura di rete continua ad essere costituita da TCP/IP e HTTP e il meccanismo ipertestuale è ancora il concetto base delle relazioni tra i contenuti. La differenza, più che altro, sta nell approccio con il quale gli utenti si rivolgono al web, che passa fondamentalmente dalla semplice consultazione (seppure supportata da efficienti strumenti di ricerca, selezione e aggregazione) alla possibilità di contribuire popolando e alimentando il web con propri contenuti. 10

18 2.3 Differenze e confronti con il Web Differenze e confronti con il Web 1.0 Spesso appare comodo, nel descrivere le caratteristiche del Web 2.0, procedere per confronto con il Web 1.0, indicando come nel passaggio di versione gli elementi fondamentali 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, ma risulta abbastanza efficace per riconoscere su Internet le tracce dell una o dell altra versione. Dai siti web personali ai blog Se prima la costruzione di un sito web personale richiedeva la padronanza di elementi di HTML e programmazione, oggi con i blog chiunque è in grado di esporre i propri contenuti dinamici dotati anche di veste grafica accattivante senza nessuna conoscenza tecnica particolare. Se prima le community web erano in stragrande maggioranza costituite da esperti di informatici, oggi la situazione è completamente ribaltata. 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 è la più celebre applicazione) è il punto di arrivo del content management, in quanto ne implementa tutti i paradigmi. Se prima erano necessarie più applicazioni informatiche per la gestione del ciclo di vita dell informazione (dall intuizione alla fruizione), oggi una stessa tecnologia supporta al meglio tutto il processo. Si fruisce dell informazione nell ambiente stesso in cui essa è nata. Dalla stickiness al syndication Le tecniche utilizzate fino a ieri per tenere più tempo possibile i visitatori su un sito web (stickiness, letteralmente l appiccicosità di un sito, cioè la capacità di tenere incollati gli utenti ad esso) stanno lasciando il posto ad altre concezioni di contatto con il fruitore. Attraverso le tecnologie di syndication (RSS, Atom, Tagging) chi realizza contenuti fa in modo che questi possano essere fruiti non solo sul sito, ma anche attraverso canali diversi. Un esempio di questi nuovi canali sono i feed, cioè delle liste di elementi con un titolo (e.g. notizie di un giornale e thread di un newsgroup), che permettono il successivo collegamento ai contenuti informativi. Questi ultimi possono essere aggiornati e consultati di frequente con programmi appositi o anche attraverso i browser e, quindi, consentono di essere sempre a conoscenza dei nuovi contenuti inseriti su un sito senza doverlo visitare direttamente. 11

19 2 Introduzione al Web 2.0 Strumenti per la creazione di contenuti Tale possibilità di creazione e condivisione di contenuti su web, tipica del Web 2.0, è data da una serie di strumenti (tool in inglese) on-line che permettono di utilizzare il web come se si trattasse di una normale applicazione. In pratica il web di seconda generazione è un web dove poter trovare quei servizi che finora erano offerti da pacchetti da installare sui singoli computer. Esempi di applicativi del Web 2.0 sono rappresentati nella tabella 2.1, mentre le figure 2.3 e 2.4 mostrano alcune schermate. Nome Descrizione Indirizzo IucundeWeb elaboratore di testi FCKEditor elaboratore di testi Writely elaboratore di testi docs.google.com/ NumSum sorta di foglio elettronico Gliffy strumento per disegnare flow-chart e vari schemi Tabella 2.1. Esempi di applicativi del Web 2.0 Oltre alla creazione condivisa di contenuto on-line, il Web 2.0 è caratterizzato dalla pubblicazione immediata del contenuto e alla sua classificazione e indicizzazione nei motori di ricerca, in modo che l informazione sia subito disponibile a beneficio dalla comunità, realizzando in maniera veloce il ciclo di vita del content management. Per la pubblicazione dei contenuti fanno da padrone sul web di oggi i provider di blog come Blogger ( il quale viene mostrato nella figura 2.5, Wordpress ( e Splinder ( ma anche piattaforme commerciali come Microsoft Sharepoint Portal che nella prossima versione (3.0) accentuerà le sue caratteristiche di collaborazione diventando la parte server di Office

20 2.3 Differenze e confronti con il Web 1.0 Figura 2.3. L elaboratore di testi IucundeWeb (in secondo piano) e il foglio elettronico NumSum (in primo piano) 13

21 2 Introduzione al Web 2.0 Figura 2.4. L applicativo Gliffy, strumento per disegnare vari tipi di flow-chart Figura 2.5. Schermate di Blogger 14

22 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 solo dal punto di vista sociale, ma anche sotto quello tecnologico, permettendo la creazione di applicazioni e servizi di nuova generazione. Il capitolo 4 approfondisce l argomento relativo alle tecnologie AJAX. Rich Internet Application (RIA) Le Rich Internet Application (RIA) sono applicazioni web che hanno le caratteristiche e le funzionalità delle tradizionali applicazioni desktop (cioè residenti sul computer). Nelle RIA tipicamente è trasferita a livello client la parte dell applicazione che processa i dati e fornisce una pronta risposta all interfaccia utente, mentre la gran parte dei dati e dell applicazione rimane sul server. Tipicamente le RIA girano in un comune web browser e non richiedono alcuna installazione. In un certo senso le RIA rappresentano una generazione di applicazioni che permette una user experience totalmente rinnovata, fondata sul meglio delle caratteristiche funzionali e progettuali che finora erano prerogativa alternata del web o delle applicazioni desktop. Adobe Flex si sta recentemente (2006) affermando quale principale piattaforma tecnologica per la realizzazione di RIA. Mashup, dashboard ed altre applicazioni composite La tecnica AJAX permette di miscelare ed associare componenti multiple in una sola applicazione. Ciò permette agli sviluppatori AJAX di creare vari tipi di applicazioni composite sfruttando le tecnologie fornite da vari provider. Mashup - Un mashup è un sito o un applicazione web che utilizza contenuti provenenti da più di una fonte per creare un servizio completamente nuovo. Un esempio concreto è un applicazione che fornisce mappe geografiche, che comunica (mediante XML) con il server di un azienda richiedendo l indirizzo e, quindi, il servizio di mappe (e.g. Google o Yahoo!) fornisce in risposta una mappa da visualizzare all interno degli altri contenuti dell applicazione. Spesso, i mashup rendono possibile uno sviluppo rapido di applicazioni integrando componenti di terze parti pronti all uso. Portali e dashboard - Sono composti da vari pannelli che, spesso, possono essere configurati dall utente. Inoltre, ogni pannello può essere un applicazione separata. Le tecnologie AJAX possono essere utilizzate per gestire sia l intera applicazione sia le singole sotto-applicazioni in essa integrate. 15

23 2 Introduzione al Web 2.0 Composizione di servizi - In ambiente SOA (architetture service-oriented), applicazioni commerciali composte assemblano molteplici servizi per creare nuove funzionalità che supportano un innovativo processo commerciale. In alcuni casi, i servizi dai quali la nuova applicazione viene realizzata non hanno interfacce utente, quindi l applicazione composta è la sola interfaccia utente disponibile. In altri casi, i servizi che vengono aggregati hanno già una loro interfaccia grafica, quindi l applicazione composita non deve soltanto aggregare i servizi offerti, ma anche le varie interfacce utente. Collaborazione AJAX rende disponibili applicazioni collaborative quali: Instant messaging (IM) e chat di nuova generazione - AJAX rende disponibile lo scambio di messaggi attraverso applicazioni web che vengono eseguite in un comune browser. Web meeting e whiteboarding - Le ricche funzionalità delle interfacce utente AJAX, la programmazione di rete e la grafica vettoriale forniscono l infrastruttura per applicazioni browser per net-meeting e lavagne condivise (whiteboards). Creazione collaborativa di contenuto - Le applicazioni web collaborative come i wiki possono evolvere dall attuale condizione in cui gli utenti devono imparare un linguaggio di markup tipico dei wiki a un interfaccia utente grafica WYSIWYG (What You See Is What You Get), simile all utilizzo delle applicazioni desktop per la creazione di contenuti. Pianificazione - Un gruppo di persone può utilizzare un applicazione sviluppata con AJAX per lavorare insieme e pianificare le proprie attività. Condivisione di foto - AJAX permette una nuova forma di condivisione, che permette di aggiungere commenti, tag o contrassegnare una foto. 16

24 Capitolo 3 Interfacce utente grafiche per il web 3.1 Introduzione L interfaccia utente ha subito, nel corso degli anni, modifiche profonde che hanno cambiato anche il modo di concepire lo sviluppo stesso delle applicazioni su qualunque piattaforma. La crescita delle applicazioni per Internet fanno pensare che l evoluzione delle GUI sia lungi dall essere terminata. In particolare, l affermazione di nuove concezioni e tecniche per il web comportano la nascita di nuovi tipi d interfaccia per soddisfare le esigenze degli utenti, come discusso nel capitolo precedente. Negli ultimi anni, l interfaccia utente ha assunto un ruolo sempre più incisivo nello sviluppo di applicazioni, e si riscontra sempre più spesso, anche nelle piccole realtà produttive, una maggiore attenzione e importanza al disegno della GUI e all impatto che l utente può avere con essa. L evoluzione delle applicazioni accessibili attraverso Internet mostra che, verso la metà degli anni 90, esse erano di tipo Information retrieval, con un interfaccia molto 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 applicazioni per siti web. In seguito, grazie anche allo sviluppo del concetto di Internet, comparvero due tecnologie parallele, ovvero ActiveX ed Applet Java, volte ad arricchire le interfacce visibili all interno dei browser. Nonostante le potenzialità da esse offerte, non hanno mai avuto il successo sperato, tanto che sono state di fatto sostituite da altre due nuove tecnologie, ovvero Dynamic HTML ed XML, più vicine allo spirito originale del linguaggio HTML. Queste ultime, unite allo sviluppo di applicazioni server sempre più potenti e raffinate, hanno radicalmente modificato il modo di progettare le applicazioni web. 17

25 3 Interfacce utente grafiche per il web Ciò che ci si aspetta dal web di oggi è di vedere delle GUI efficienti, funzionali e pratiche 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 tecnologie usate per creare GUI all interno di un browser. HTML HTML è tuttora il linguaggio per eccellenza del mondo Internet. Il suo pregio principale consiste nella standardizzazione che, se rigorosamente seguita dagli sviluppatori, ne permette la lettura da parte di tutti i browser attualmente disponibili. D altra parte, il linguaggio HTML è statico e offre un basso numero di oggetti per la manipolazione dei dati. A causa di ciò, l utente non ha a disposizione alcuni strumenti ai quali è abituato, come le barre degli strumenti (toolbar), i menu standard o con effetto pop-up, eccetera. Inoltre, la mancanza di componenti legati ai campi del database implica che le tecniche di programmazione abituali degli ambienti RAD (Rapid Application Development) devono essere modificate, per fornire alle pagine basate sul linguaggio HTML la possibilità di mostrare i dati richiesti. Applet Java Java è il linguaggio che maggiormente si è imposto all attenzione del mondo Internet. Grazie alla possibilità di creare applet, esso è uno strumento privilegiato per superare le limitazioni, accennate in precedenza, del linguaggio HTML. Il linguaggio Java dispone di una grande quantità di oggetti ed essendo standardizzato avrebbe le caratteristiche per poter diventare un linguaggio veramente universale. A questo livello, tuttavia, è difficile realizzare una connessione ad un database in maniera efficiente ed indipendente dal browser e la velocità di esecuzione degli applet è un altro punto negativo tuttora insuperato. ActiveX La tecnologia ActiveX, proposta da Microsoft, è un tentativo in parte riuscito di avvicinare l interfaccia del mondo Internet a quella dei programmi per Windows, allo scopo di rendere uniformi gli ambienti applicativi e di sfruttare il massimo possibile delle conoscenze acquisite dagli utenti. Inoltre, può sfruttare una libreria di componenti già esistenti o di facile implementazione. Tale libreria ha il vantaggio di essere praticamente illimitata. Si tratta, però, di una tecnologia di proprietà 18

26 3.2 Cenni sulle tecnologie usate per le GUI privata, che dipende fortemente dal sistema operativo e dal browser. Non esiste una standardizzazione, per cui gli utenti sono vincolati alle decisioni del produttore. DHTML e XML L esperienza ha mostrato che nessuna delle tecnologie sopra descritte soddisfa pienamente le esigenze emerse con lo sviluppo di Internet. Il linguaggio HTML, tuttavia, ha rappresentato una solida base su cui sviluppare nuove soluzioni. Le strade seguite sono state due: da un lato si è cercato di rendere dinamico il linguaggio HTML (DHTML), associandolo a potenti linguaggi di scripting, permettendo la modifica dei contenuti e della posizione dei componenti anche dopo la visualizzazione della pagina; dall altro, si è proposto un nuovo linguaggio (XML) per la separazione del contenuto dalla formattazione. Purtroppo, il linguaggio DHTML è nato al di fuori degli standard ed è difficile conciliare le versioni proposte dai due maggiori produttori di browser. Questo fatto ne ha impedito fino ad oggi la diffusione auspicata. Adobe Flash Adobe Flash, in precedenza chiamato Macromedia Flash e ancora prima FutureSplash, è un software per uso prevalentemente grafico che consente di creare animazioni vettoriali principalmente per il web. Viene utilizzato, inoltre, per creare giochi o interi siti web e grazie all evoluzione delle ultime versioni è divenuto un potente strumento per la creazione di Rich Internet Application e piattaforme di streaming audio/video. Quando le tecnologie Java applet e DHTML hanno avuto un periodo stagnante, la tecnologia Flash ha guadagnato molta notorietà. Ormai, nel mondo Internet il formato Flash (estensione.swf), degli oggetti creati con l omonimo programma, rappresenta uno standard per la creazione di contenuti animati ed interattivi. Di fatto, la quasi totalità dei browser supportano nativamente questo formato che consente la visione appunto di animazioni grafiche, così come la visione in streaming o in progressive downloading di filmati video. Questa tecnologia client rimane ancora oggi usata principalmente per giochi e banner pubblicitari. La principale ragione di questa limitazione è dovuta all adozione di una tecnologia che non è open e che muta in continuazione. Inoltre, un ecceso di funzionalità, magari unite ad un implementazione non ottimizzata, può comportare un rallentamento del client. 19

27 3 Interfacce utente grafiche per il web 3.3 Caratteristiche delle GUI nelle applicazioni web L interfaccia utente di un applicazione Internet possiede alcune caratteristiche che la differenziano fortemente da quelle dei programmi per desktop. Tali caratteristiche ed i loro effetti nella progettazione della GUI vengono elencati di seguito Eterogeneità delle esperienze degli utenti Uno dei più importanti principi della progettazione delle GUI afferma che si devono conservare le conoscenze acquisite dagli utenti nel corso delle loro esperienze informatiche. Ciò ha portato alla creazione, per ciascuno dei principali sistemi operativi presenti sul mercato, di modelli per interfacce utente che, adottati dalle più diverse applicazioni, garantiscono una certa uniformità d impiego. Tuttavia, le applicazioni web spesso si rivolgono ad utenti dei quali non sono note né le competenze informatiche, né i sistemi operativi e browser che usano. In questo caso, è dunque impossibile sapere quali competenze conservare. L introduzione delle tecnologie applet Java ed ActiveX ha cercato, come detto, di risolvere questo problema trasferendo nel mondo Internet gli stessi oggetti che gli utenti trovano quotidianamente sui propri computer, senza peraltro soddisfare pienamente il pubblico. È, quindi, necessario cercare l esperienza minima comune a tutti gli utenti potenziali ed è facile rendersi conto che essa consiste nell uso del browser e della conoscenza dell ipertestualità. Una GUI per applicazioni Internet dovrebbe, quindi, sfruttare le possibilità offerte, per esempio, dal linguaggio HTML per fornire all utente le funzionalità di base, lasciando alle altre tecnologie il compito di svolgere attività specifiche all interno dell interfaccia, potenziandola Garanzia di funzionalità È spontaneo chiedersi se con gli oggetti messi a disposizione dal linguaggio HTML sia possibile riprodurre tutte le sofisticate funzionalità offerte dalle GUI per applicazioni desktop. La risposta è negativa, come spiegato in precedenza. Però, le funzionalità 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 ipertestualità e si fornisce all utente un ambiente di lavoro facile, intuitivo e simile a quello sperimentato quotidianamente con la navigazione in Internet. Inoltre, aggiungendo la dinamicità del linguaggio DHTML e unendo le funzioni di varie librerie che sono state sviluppate per tale linguaggio, si riescono a creare interfacce utente che riproducono quelle per desktop, sia nella grafica (ovvero con tutti gli elementi tradizionali, quali barre degli strumenti, icone, finestre a comparsa, eccetera), sia nelle funzionalità. Tutto ciò, 20

28 3.3 Caratteristiche delle GUI nelle applicazioni web se usato in modo chiaro e coerente, è in grado di soddisfare pienamente le esigenze degli utenti, indipendentemente dal contesto in cui l interfaccia viene inserita Nuovi strumenti offerti per il web Con lo scopo di garantire funzionalità, appena discusse, è sorta un alleanza, Open- Ajax Alliance, che ha lanciato un progetto che renderà disponibili librerie AJAX standard da utilizzare nelle applicazioni Web 2.0. L obiettivo principale è di illustrare e diffondere la tecnica AJAX (Asynchronous JavaScript and XML), spiegata al capitolo 4 di questa tesi, accelerando così l avvento del cosiddetto Web 2.0. A tale scopo, OpenAjax Alliance ha inaugurato un progetto con il quale spera di risolvere i problemi di interoperabilità del mondo delle applicazioni Internet. Il progetto, sostenuto da decine di grossi nomi del settore software come IBM, Oracle, Sun, Adobe e Google, si chiama OpenAjax Hub ed è costituito da un insieme di funzionalità JavaScript standard progettate per essere snelle e veloci. L Alleanza sostiene che l uso di queste funzionalità risolve i molti problemi di interoperabilità che oggi sorgono quando si utilizzano più librerie AJAX all interno della stessa pagina web. Il problema consiste nel fatto che gli oggetti JavaScript e i toolkit che gestiscono il codice HTML entrano in conflitto, impedendo la possibilità di integrare funzioni come gli eventi drag and drop. OpenAjax Alliance prevede di completare la prima versione del proprio insieme di librerie runtime per l inizio del Il supporto del progetto OpenAjax Hub viene integrato in diversi toolkit e framework di sviluppo, i cui aspetti tecnici vengono affrontati alla sezione 4.4 a pagina 34. La tabella 3.1 riporta alcuni ambienti legati al progetto. 21

29 3 Interfacce utente grafiche per il web Nome Dojo Foundation Tibco Backbase JackBe Nexaweb Indirizzo Tabella 3.1. Alcuni toolkit e framework di sviluppo che integrano il supporto del progetto OpenAjax Hub Il sito (Cf. [12]) riporta sia la lista completa di tutte le compagnie facenti parte dell organizzazione, sia i riferimenti alle informazioni dettagliate dei rispettivi progetti (tra cui è presente l azienda Laszlo Systems con il progetto OpenLaszlo che viene ampiamente trattato nel capitolo 5). Inoltre, viene riportato il documento dettagliato del progetto OpenAjax Hub (Cf. [14] per maggiori dettagli). 3.4 Effetti delle GUI sullo sviluppo di un applicazione Un interfaccia influenza fortemente tutta l architettura del sistema ed un errore nella sua analisi può condurre all uso di tecnologie inadatte a raggiungere gli obiettivi prefissati, costringendo alla riscrittura dell intera applicazione. Di seguito, sono esposti alcuni punti critici individuati nella progettazione delle GUI Bilanciamento delle operazioni Nel corso degli anni si è assistito ad una continua variazione del bilanciamento delle responsabilità funzionali tra client e server, arrivando oggi, con il modello multitier, ad avere una distribuzione uniforme delle operazioni. Con l adozione di questo modello, un applicazione è divisa in moduli distinti, implementando separatamente l interfaccia utente grafica (Presentation tier), la logica di gestione (Buisness logic o Logic tier) e la logica del database (Data tier). Questo modello può essere conservato anche per le applicazioni Internet. In questo contesto specifico il client è un browser all interno del quale è mostrata l interfaccia dell applicazione e il modello 3-tier spinge ad una separazione quasi totale del livello del client dagli altri due, come illustrato nella figura

30 3.4 Effetti delle GUI sullo sviluppo di un applicazione La logica di gestione, normalmente, è implementata all interno di un applicazione residente sul server, come ad esempio un programma CGI (Common Gateway Interface) 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 client alcune operazioni, come i principali controlli di validità dei dati immessi, usando linguaggi di script. Pertanto, lo strato intermedio viene suddiviso tra client e server (figura 3.2), come introdotto dalla recente tecnica AJAX (capitolo 4). 23

31 3 Interfacce utente grafiche per il web Figura 3.2. Confronto tra l architettura web a 3 strati (a) e quella a 4 strati (b) Da un lato, quante più operazioni si delegano al client, tanto più si rischia di essere vincolati al tipo di browser e di rallentare l elaborazione. Dall altro lato, si allegerisce il carico del server in presenza di più utenti connessi contemporaneamente. Pertanto, con un equilibrato bilanciamento delle operazioni, l interfaccia viene sollevata da molte responsabilità e questo ne favorisce la funzionalità. Inoltre, delegando al client le funzioni che riesce a svolgere senza perdita di efficienza, si potrebbe migliorare la scalabilità del sistema, ovvero avere la capacità di gestire un numero crescente di utenti senza peggioramento delle prestazioni del servizio Universalità dell interfaccia Il fatto di operare all interno di un browser obbliga l interfaccia a rispettare alcuni vincoli, che talvolta sono invece trascurati. Il principale, senza dubbio, è quello di essere universale, intendendo con questo il fatto di essere visibile nello stesso modo in tutti i browser. Un interfaccia universale permette una manutenzione semplice, allunga in modo significativo la durata di vita dell applicazione ed è realmente cross-platform, risolvendo problematiche relative all accessibilità software. 24

32 3.5 I requisiti emergenti dell usabilità del web Universalità degli script Come detto nella sottosezione 3.3.2, spesso è utile aggiungere codice lato client, attraverso linguaggi di scripting. Questo codice deve poter operare su piattaforme differenti, all interno di prodotti diversi dei quali non è nota a priori la versione. È molto importante, quindi, prepararsi ad operare in ciascuno di questi ambienti. Il linguaggio più usato è JavaScript, perché attualmente è l unico ad essere letto da tutti i browser. Le tecniche per operare su tutti i browser disponibili, molto sviluppate, si basano su due strategie principali: 1. la moltiplicazione del codice, con riconoscimento del browser, che permette di eseguire solo il codice specifico per ogni browser; 2. la scrittura del codice per un browser specifico e, quindi, per una determinata gerarchia di oggetti, accompagnata da procedure che riproducono la suddetta gerarchia nel caso in cui il codice stia girando nel browser non previsto. Rendere universale gli script collegati all interfaccia significa rendere più robuste le proprie applicazioni, ovvero maggiormente accessibili. 3.5 I requisiti emergenti dell usabilità del web Secondo una vecchia definizione data dalla norma ISO 9241 del 1993 riferita ai prodotti informatici, l usabilità è il grado in cui un prodotto può essere usato da particolari utenti per raggiungere certi obiettivi con efficacia, efficienza e soddisfazione in uno specifico contesto d uso. Gli aspetti fondamentali da rispettare per permettere un efficace fruizione delle informazioni sono elencati di seguito: navigabilità: esistenza di un sistema di navigazione e di orientamento nel sito. Si deve evitare il senso di smarrimento, permettendo all utente di sapere dove si trova e come può ritornare facilmente ad un punto precedente. Anche i link devono dare anticipazioni corrette su dove porteranno. Utilità attesa: disponibilità di informazioni e/o servizi che corrispondono alle aspettative degli utenti. L utente web ha delle aspettative di ritorno per il tempo che dedica alla visita del sito. Bisogna evitare che le promesse del sito siano disattese o addirittura false. Completezza dei contenuti: presenza di contenuti informativi a livello di dettaglio desiderabile per gli utenti. È molto difficile che un sito soddisfi il 25

33 3 Interfacce utente grafiche per il web bisogno informativo di ogni tipologia di utenti. Per un portale è importante che l ampiezza di contenuti e il loro livello di dettaglio si adattino ad ogni tipologia, mentre per un sito specialistico è importante che sia subito definita l audience a cui si rivolge. Comprensibilità delle informazioni: la forma e la qualità con cui l informazione e i contenuti vengono presentati nel sito. Molto importante il linguaggio usato, soprattutto per operazioni interattive. Deve esistere un sistema di classificazione delle informazioni comprensibile da tutti, anche se il contenuto finale può essere specialistico. Efficacia comunicativa: la strategia comunicativa del sito. L efficacia comunicativa è una misura della credibilità del sito e si basa sia sul marchio dell istituzione/struttura che rappresenta, sia sulla capacità di essere persuasivi e seducenti per portare ad una relazione di fiducia con gli utenti. Attrattività grafica: la qualità della grafica e la piacevolezza visiva del sito. La grafica deve portare ad un giusto equilibrio tra emozioni e comfort che induce sull utente ed un utilizzo consapevole dei contenuti. Non deve nascondere il vero scopo del sito. 26

34 Capitolo 4 Le tecnologie AJAX 4.1 Introduzione: che cos è AJAX e come si colloca nel web L acronimo AJAX, che significa esattamente Asynchronous JavaScript And XML, ovvero JavaScript Asincrono ed XML, è stato enunciato per la prima volta da Jesse James Garrett, nel 18 Febbraio 2005, come titolo di un post all interno del suo blog [9]. Jesse James Garrett è il fondatore e presidente di Adaptive Path, un azienda di San Francisco (California, US) che ha molti anni di esperienza in ambito di applicazioni interattive per il web. Nell articolo, dal titolo AJAX: A New Approach to Web Applications, viene presentato AJAX e i concetti ad esso collegati. Viene subito chiarito che non si tratta né di una nuova tecnologia né di un invenzione, ma bensì di un concetto utilizzato per sviluppare applicativi avanzati e particolari, quali ad esempio Gmail, Google Maps o Google Suggest. Il concetto è in parte espresso nell acronimo scelto, cioè un utilizzo asincrono di JavaScript che attraverso l interfacciamento con XML, può permettere ad un client di richiamare informazioni lato server in modo veloce e trasparente, allargando così gli orizzonti delle Rich Internet Applications (RIA). Queste applicazioni fino a poco tempo fa erano legate principalmente alle tecnologie Adobe-Macromedia Flash o Java (con le applet). Entrambe, purtroppo, non sempre interpretabili dai client degli utenti e troppo spesso usate a sproposito con il solo scopo di stupire, discorso che spesso e purtroppo vale anche oggi. In alternativa a queste tecniche di interazione client-server, quando nel 1996 venne introdotto l elemento iframe in Internet Explorer 3, molti sviluppatori sfruttarono quest ultimo modificando l attributo sorgente (src) della pagina racchiusa e simulando così un refresh trasparente di una parte di contenuti. Veniva così emulata, in modo abbastanza grossolano, un interazione asincrona. Nel 1998 Microsoft cominciò a sviluppare una tecnologia, chiamata Remote 27

35 4 Le tecnologie AJAX Scripting, con lo scopo di creare una tecnica più elegante per richiamare contenuti differenti ed è in questo periodo, seppur con nome differente, che AJAX venne utilizzato per la prima volta, per poi evolversi in versioni più mature fino a diventare un oggetto vero e proprio, noto ora come XMLHttpRequest. Il motivo principale di tanto successo è che solo ultimamente il Remote Scripting ha suscitato lo stupore degli addetti ai lavori nel vedere cosa Google fosse riuscita a fare all interno dei suoi applicativi senza necessità di Flash Player o Java Virtual Machine, mantenendo comunque la compatibilità con molteplici browser di utenti che per diversi motivi non potevano usufruire di JavaScript. Come spesso è accaduto negli ultimi anni, molti hanno preso spunto da Google ed il web, noto per la sua immediatezza propositiva, è stato in grado in poco più di un anno di mostrare numerosi esempi di applicativi basati su AJAX. Google sta facendo un grande investimento nel sviluppare questo approccio. Tutti i maggiori prodotti introdotti da Google nell ultimo anno, quali Orkut, Gmail, l ultima versione beta di Google Groups, Google Suggest e Google Maps, sono applicazioni AJAX. Altri si ispirano: molte delle caratteristiche che le persone amano nel Flickr ( dipendono da AJAX ed il motore di ricerca di Amazon A9.com applica tecniche simili. Infine, è anche degno di nota il sito del progetto SIMILE (sviluppo di robusti tool open source basati sulle tecnologie semantiche, all indirizzo sempre per l utilizzo di questa tecnica. Questi progetti dimostrano che AJAX non è solo avanzato dal punto di vista tecnico, ma anche pratico per le applicazioni real-world. Tutti gli esempi precedenti sono una dimostrazione che questa non è un altra tecnologia che funziona solo in laboratorio. Inoltre, le applicazioni AJAX possono essere di qualsiasi dimensione, dalla molto semplice monofunzione di Google Suggest al molto complesso e sofisticato Google Maps. 4.2 Descrizione tecnica e teorica Come detto in precedenza, AJAX non è una tecnologia. Infatti, consiste in più tecnologie, ognuna delle quali si sviluppa per conto proprio, ma unendosi con le altre 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

36 4.2 Descrizione tecnica e teorica Il modello classico dell applicazione web ha il seguente principio di funzionamento: la maggior parte delle azioni dell utente nell interfaccia attiva una richiesta HTTP 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. È un modello adattato dall uso originale del web come un medio ipertesto, ma ciò che rende il web adatto per l ipertesto non lo rende necessariamente adatto alle applicazioni software. Figura 4.1. Confronto tra il modello di interazione tradizionale delle applicazioni web e il modello AJAX Questo approccio ha un senso dal punto di vista tecnico, ma non da quello dell esperienza di un utente, in quanto mentre il server sta eseguendo varie elaborazioni, l utente è costretto ad aspettare. Ovviamente, il progetto del web per le applicazioni prevede tra i vari obiettivi di non fare aspettare l utilizzatore. Una volta che l interfaccia è caricata, l interazione con l utente non si deve fermare e ricaricare ogni volta che l applicazione ha bisogno di informazioni e/o dati dal server. Di fatto, non sarebbe né utile né comodo all utente vedere l applicazione andare al server. Invece, un applicazione AJAX elimina la natura start-stop-start-stop dell interazione sul web introducendo un intermediario, ovvero un motore AJAX, tra l utente 29

37 4 Le tecnologie AJAX ed il server (figura 4.1). Ad una prima analisi, può sembrare che aggiungere un layer all applicativo lo renderebbe meno reattivo, ma è vero esattamente il contrario. Figura 4.2. Confronto tra l interazione sincrona client-server e quella asincrona (AJAX) Invece di caricare una pagina web, all inizio della sessione, il browser carica un motore AJAX scritto in JavaScript e di solito messo al sicuro in un frame nascosto. Questo motore è responsabile sia per il rendering dell interfaccia vista dall utente, sia per la comunicazione con il server per conto dell utente. Il motore AJAX permette che l interazione dell utente con l applicazione avvenga in modo asincrono, cioè indipendentemente dalla comunicazione con il server. Così l utente non si trova mai davanti una finestra browser vuota e un icona a clessidra, aspettando che il server finisca l elaborazione e restituisca tutta la pagina. 30

38 4.3 Introduzione ai fondamenti di AJAX Ogni azione dell utente che normalmente genererebbe una richiesta HTTP prende la forma di una chiamata JavaScript al motore AJAX. Il motore gestisce da solo ogni risposta all azione dell utente che non richieda un ritorno al server, per esempio come la semplice validazione dei dati, l editing dei dati nella memoria e persino la navigazione. Se il motore ha bisogno di qualcosa dal server per rispondere, per esempio se sta sottoponendo dati per essere elaborati, caricando del codice aggiuntivo dell interfaccia o recuperando nuovi dati, il motore effettua quelle richieste in modo asincrono, di solito usando il formato XML, senza fermare l interazione dell utente con l applicazione. Tutto ciò è illustrato in figura Introduzione ai fondamenti di AJAX Il termine AJAX è stato coniato di recente per sottolineare due caratteristiche molto funzionali possedute dai browser che sono stati in circolazione per anni, ma non furono considerati da molti sviluppatori web fino ai tempi attuali quando applicativi come 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, è necessario creare un istanza di classe che fornisca questa funzionalità. Tale classe fu originariamente introdotta in Internet Explorer come un oggetto ActiveX, chiamato XMLHTTP. Poi browser come Mozilla, Safari ed altri sono seguiti, implementando una classe XMLHttpRequest che supporta i metodi e le proprietà dell oggetto originario di Microsoft ActiveX. Conseguentemente, per creare un istanza cross-browser (oggetto indipendente dal browser utilizzato) della classe richiesta si può 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 dal server non ha un header mime-type in XML. Per colmare questa lacuna, è necessario eseguire una chiamata extra di metodo per fare l override dell header inviato dal server nel caso non fosse text/xml, come descritto qui di seguito. 31

39 4 Le tecnologie AJAX http_request = new XMLHttpRequest(); http_request.overridemimetype( text/xml ); Il passo successivo è decidere cosa fare dopo aver ricevuto la risposta del server alla richiesta effettuata. A tale scopo è necessario indicare all oggetto di richiesta HTTP a quale funzione JavaScript sarà demandato il lavoro di trattare la risposta. Ciò è fatto fissando la proprietà onreadystatechange dell oggetto al nome della funzione JavaScript progettata appositamente, come indicato di seguito: onreadystatechange http_request.onreadystatechange = nomedellafunzione; Si può notare che non vi sono nè parentesi dopo il nome della funzione nè parametri passati. Invece di dare un nome di funzione, si può anche usare la tecnica JavaScript 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 ciò che succederà non appena ricevuta la risposta, si deve formulare la richiesta. È necessario chiamare i metodi open() e send() della classe di richiesta HTTP, come: http_request.open( GET, true); http_request.send(null); dove: il primo parametro di chiamata a open() è il metodo di richiesta HTTP (GET, POST, HEAD o qualsiasi altro metodo che si voglia usare e che sia supportato dal server); il secondo parametro è l URL della pagina che si sta richiedendo; il terzo parametro stabilisce se la richiesta è asincrona. Se true, l esecuzione della funzione JavaScript continuerà, mentre la risposta del server non è ancora arrivata. Questo è il fondamento di AJAX. Da ricordare che prima di inviare la richiesta, è già stato indicato il nome di una funzione JavaScript che sarà predisposta a gestire la risposta. Un operazione che dovrebbe fare questa funzione è il controllo dello stato della richiesta. Se lo stato ha valore 4, significa che è stata ricevuta la risposta completa del server e si può continuare ad elaborarla. 32

40 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, è il controllo del codice dello status della risposta del server HTTP. Tutti i codici possibili sono quelli elencati nel W3C site [7]. Per esempio, se non ci sono problemi con la richiesta viene restituito il codice 200 (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 della risposta, le successive azioni della funzione JavaScript dipendono da cosa si vuol fare 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 stringa di testo; http request.responsexml: restituisce la risposta di un oggetto chiamato XMLDocument che si può attraversare utilizzando le funzioni del DOM Java- Script. Per completare questa breve introduzione tecnica e teorica, si sottolinea come il tipo di risposta che l oggetto si aspetta dopo una chiamata, non deve essere necessariamente di tipo XML o letta come tale ma che può essere semplicemente testuale, in contro tendenza con l acronimo stesso, ma non per questo inusuale. 33

41 4 Le tecnologie AJAX 4.4 OpenAjax Alliance e framework AJAX Nella sottosezione di pagina 21 è stata citata l organizzazione OpenAjax Alliance, illustrandone gli obiettivi e i punti fondamentali del suo progetto. Come detto, tale alleanza è costituita da decine di aziende importanti del settore informatico e che sono interessate allo sviluppo e alla promozione delle tecnologie web basate su AJAX. Di fatto, AJAX offre un ampia scelta a riguardo dell architettura, come viene spiegato nelle sottosezioni e Questa diversità permette agli sviluppatori AJAX di scegliere fra diversi prodotti commerciali e/o tecnologie open source per trovare quella che soddisfa al meglio le esigenze relative alle applicazioni esistenti e all infrastruttura di sviluppo, nonché le loro preferenze tecnologiche. Per ogni linguaggio server-side, esistono varie librerie, in grado di sfruttare in modo automatizzato o facilmente integrabile le possibilità offerte dallo scambio dati asincrono. Molte si basano proprio sulla creazione di funzioni apposite addette a svolgere determinati compiti, mentre altre si basano sulla gestione di classi o dei loro metodi attraverso automazioni generate dinamicamente e date in elaborazione al codice JavaScript. La separazione fra client e server e dei rispettivi compiti diventa così ancor più accentuata, ma allo stesso tempo si trasforma in una vera e propria simbiosi, dove il controllo dell applicativo è dato dalla somma del linguaggio client più quello server e non più solo da quest ultimo. Nella scelta dell eventuale framework o libreria si deve tener conto la compatibilità almeno con i browser più diffusi e non solo con alcuni di questi. Nel seguito vengono illustrate due delle principali tecniche usata per classificare i toolkit e i framework AJAX. Nel sito viene riportato il documento White Papers con tutte le informazioni dettagliate relative alla tecnica AJAX (Cf. [13] per maggiori dettagli) Architettura client-side e server side Gran parte delle tecnologie AJAX trasformano una definizione dell applicazione indipendente dalla piattaforma (che solitamente consiste in una combinazione di markup e logica) nell appropriato contenuto HTML e JavaScript che verrà processato dal browser per fornire all utente un interfaccia ricca tipica di AJAX. Alcuni progetti AJAX 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 contrassegnati con il simbolo 1), il toolkit AJAX fornisce i componenti arancio (simbolo 2) 34

42 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 le trasformazioni derivano dalla libreria AJAX lato utente. Un vantaggio di questa scelta è l indipendenza dalle tecnologie lato server. Il codice in esecuzione sul server genera e invia le pagine e risponde alle richieste asincrone del client. Questo approccio può essere invertito specularmente. Trasformazione lato server La trasformazione lato server generalmente segue il modello della figura 4.4. Per ciò che riguarda AJAX lato server, un componente AJAX sul server effettua gran parte della trasformazione in codice appropriato per il client, cioè HTML e JavaScript. A volte, il toolkit lato server scarica la sua libreria AJAX lato client che comunica direttamente con il componente del toolkit lato server. Il vantaggio principale di questo approccio è dato dal fatto che permette all utente di usare i linguaggi lato server per il debug, l editing e i tool con cui gli sviluppatori sono già famigliari, ma ciò comporta la dipendenza da una determinata tecnologia lato server. Come regola generale, i framework AJAX lato server necessitano di 35

43 4 Le tecnologie AJAX codice scritto in un linguaggio lato server (es. Java). Questi framework tipicamente nascondono tutto il codice JavaScript che viene eseguito sul browser all interno di widget, compresi i loro eventi. Se le funzionalità built-in non sono sufficienti per le esigenze del programmatore, i nuovi componenti devono essere sviluppati in codice JavaScript. 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 sviluppo tutti gli eventi vengono gestiti dal server, ma in produzione molti eventi vengono gestiti dal client. Figura 4.4. Modello di trasformazione AJAX lato server 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 esclusivamente utilizzando le API JavaScript per gestire tutti gli eventi e manipolare i widget. Con l approccio dichiarativo, gli sviluppatori gestiscono il toolkit quasi esclusivamente tramite HTML o XML per definire i componenti delle pagine e le relazioni che intercorrono tra di loro. Tag XML personalizzati sono, spesso, definiti nella struttura del framework. Il codice JavaScript può essere necessario in alcune circostanze, ma uno degli obiettivi del framework è di minimizzare l utilizzo di logica. 36

44 4.5 Considerazioni lato utente 4.5 Considerazioni lato utente Vantaggi L impressione di avere a che fare con pagine apparentemente più interattive, dinamiche e professionali è praticamente immediata. L effetto novità si aggiunge prepotentemente alla lista, stuzzicando la curiosità del navigatore. Questi aspetti apparentemente futili hanno permesso a tecnologie come Flash di affermarsi nel contesto web. Questo perché l interesse collettivo è la ricerca di informazioni, ma si preferisce navigare dove le informazioni sono presentante nel modo più semplice e veloce possibile. Altro motivo che può rendere vantaggioso l utilizzo di AJAX è quello di ottenere modifiche dinamiche e leggere sulle pagine, come i suggerimenti sui campi di ricerca, in grado di suggerire parole presenti e velocizzare l inserimento dei dati, controllo sulla correttezza dei campi di un form man mano che viene compilato, senza aspettare il momento dell invio dei dati, caricamento di mappe solo sul frame interessato, senza ricaricare tutta la pagina e così via Svantaggi Due delle problematiche più diffuse del web attuale, sia per la realizzazione dei siti web che per la realizzazione di applicativi web, riguardano l accessibilità e l usabilità. Per quanto concerne l accessibilità, gli utenti che necessitano di tecnologie assistive e coloro che non dispongono di connessioni veloci sono i più penalizzati. I primi perchè non possono, attualmente, godere del cambio parziale di contenuti e non saranno, quindi, in grado di sfruttarne le potenzialità. Basti pensare ad uno screenreader per i disabili visivi. Questo tipo di software legge sequenzialmente la pagina web dall alto verso il basso e non sarebbe in grado di rilevare modifiche apportate all inizio della pagina dovute alla tecnica asincrona. I secondi devono caricare, almeno al primo accesso, una mole di dati consistente rappresentata dai vari file JavaScript e potrebbero non essere in grado di sfruttare niente di quanto caricato. Inoltre, si potrebbe non disporre di un browser aggiornato e quindi non compatibile con la pagina web scaricata, oppure, in situazioni di JavaScript disabilitato, si avrebbe l assenza dell oggetto XMLHttpRequest. In questi casi si scaricano centinaia di byte che non verranno mai usati a causa del controllo a posteriori utilizzato per conoscere la reale compatibilità con AJAX. Troppo codice Javascript può risultare oneroso, ovviamente a lato client, soprattutto se tale codice è stato scritto con poco criterio. Questi aspetti puramente tecnici sono spesso raggirabili, grazie ad una stesura ottimizzata dell applicativo da parte dello sviluppatore o grazie al 37

45 4 Le tecnologie AJAX caricamento dinamico del JavaScript proposto dopo aver verificato la compatibilità del browser. Un altra problematica è relativa all uso dei tasti avanti e indietro presenti nei browser. Una qualunque interazione asincrona potrebbe dare la sensazione di aver cambiato stato alla pagina e l abitudine a tornare indietro, qualora il risultato non dovesse essere quello voluto, è intrinseca nel navigatore, nonché lecita. Ma aprendo direttamente una pagina ricca di interazioni asincrone, ci si può accorgere come non è sempre possibile, cliccando sul tasto indietro del browser, tornare allo stato precedente, in quanto si viene reindirizzati alla pagina precedente. Ciò può causare disorientamento. In questi casi, la consapevolezza di aver usato AJAX, qualora il navigatore sia preparato, non può certo aiutare, poichè anche l aggiornamento della pagina non serve a tornare allo stato precedente, ma solo allo stato iniziale. Oltre ad essere un vincolo di navigazione, questo problema è anche un vincolo per l indicizzazione o la possibilità di segnalare ad altri la pagina visualizzata. Questo accade perchè il comando gestito da JavaScript non è portabile come un link. Quindi scrivere ad un altro utente l indirizzo attualmente visitato ed eventualmente modificato tramite AJAX non è possibile se non dando delle indicazioni precise sulle operazioni svolte una volta arrivati nella pagina in oggetto. La soluzione a questi problemi non è semplice ed i motivi sono diversi. In primo luogo creare un gestore di eventi in grado di aggiungere cambiamenti alla cronologia del browser può risultare un operazione complessa per via dei diversi standard o funzioni presenti nei diversi browser. In secondo luogo l indicizzazione di un solo link, per chi non ha JavaScript o non può usufruire di tale tecnologia, diventerebbe pressapoco impossibile. La libreria di BackBase ( gestisce il caricamento e la visualizzazione asincrona delle varie sezioni di una pagina tramite una serie di informazioni appese dopo il carattere #, il quale permette solitamente di indicizzare sotto contenuti di una pagina tramite l uso di elementi con identificativo univoco, ma che può essere gestito senza problemi dal JavaScript proposto. Ma viene risolto solamente il problema dei tasti avanti e indietro del browser. Infatti, se un utente che naviga una sottosezione passa il link ad un altro utente, la pagina visualizzata potrebbe non essere uguale. Questo avviene perché è solo il codice JavaScript (lato client) che è in grado di verificare il link e gestirlo di conseguenza, mentre il server non potrà fare altro che mostrare la pagina richiesta, ignorando giustamente tutto ciò che non fa parte del reale indirizzo richiesto, ovvero tutto il testo eventualmente presente dopo il carattere #. Inoltre rimangono i problemi di compatibilità tra browser e quelli relativi alla disabilitazione del codice JavaScript. 38

46 4.6 Considerazioni lato server 4.6 Considerazioni lato server Vantaggi È noto che usare fogli di stile (CSS) esterni piuttosto che in linea ha l effetto di ridurre la banda utilizzata mensilmente dai navigatori. L utilizzo di AJAX potrebbe fare altrimenti. Infatti con AJAX il server non ha necessità di trasferire tutta la pagina per ogni interazione, ma solo la porzione necessaria all operazione richiesta. Questo rende sensibilmente più veloce l interazione per l utente e favorisce il risparmio di banda. Inoltre, c è anche una ricaduta in termini di calcoli da effettuare. In un portale ricco di informazioni, reperire tutti i dati per poter affrontare una interazione tradizionale può richiedere una computazione maggiore per diversi decimi di secondo (database, web service, etc.). Invece, con AJAX le richieste sono puntuali, cioè mirate solo a ciò che serve effettivamente, ed il server può rispondere in modo più efficiente. Questo può anche essere positivo per la gestione di un numero più elevato di utenti simultanei, non dovendo più operare su tutto l applicativo da parte del server. Questa caratteristica prende il nome di scalabilità. Allo stesso tempo una parte dei calcoli può essere data in gestione al browser, così da sfruttare la potenza del 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 calcoli dovessero essere troppi. Il tutto va progettato in maniera molto oculata e sensata e, soprattutto, non si dovrebbero creare applicativi così complessi da richiedere diversi secondi di attesa prima di poter essere utilizzati. 39

47 4 Le tecnologie AJAX Svantaggi Come detto in precedenza, il principale inconveniente può essere causato dall abuso di AJAX. Infatti, uno sviluppatore poco accorto potrebbe mettere a disposizione troppe interazioni su una sola pagina e se non si controllano le operazioni sul client, il server rischia di ritrovarsi sovraffollato di richieste probabilmente inutili. Di esempi ce ne possono essere vari, come per esempio gli aggiornamenti di dati statistici eseguiti in maniera troppo frequente. In questi casi, la soluzione è trovare il giusto compromesso tra necessità effettiva della frequenza di aggiornamento e calcoli per effettuarla. 4.7 Problematiche relative al tempo di attesa Un inevitabile incomodo è l attesa che trascorre tra una richiesta dell utente e la risposta del server. Con l aggiunta di AJAX si perde questa linearità e mentre l utente è all interno della stessa pagina le richieste sul server possono essere numerose e completamente indipendenti. Nulla vieta, teoricamente, di effettuare decine di richieste simultanee al server per operazioni differenti con o senza controllo da parte del navigatore. Figura 4.6. Rappresentazione di più richieste ad un server con latenza e risposte Ciò che resta del vecchio flusso, il tempo di attesa, passa spesso in secondo piano ed in molti tipi di interazione è praticamente impercettibile. Ma bisgna prestare attenzione, poichè questo tempo è anche uno dei maggiori problemi dell utilizzo di AJAX, sia per gli sviluppatori sia per i navigatori. I primi potrebbero trovarsi in difficoltà qualora si dovesse aspettare una risposta che per svariate ragioni si è persa o ritarda ad arrivare, mentre i secondi potrebbero non avere idea di cosa stia accadendo alla pagina, chiudendola ignari di aver richiesto un informazione Perdita di una richiesta Esistono diverse motivazioni per le quali una richiesta asincrona possa apparentemente svanire nel nulla. Tra le più frequenti troviamo i rallentamenti sulla rete e il sovraccarico 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

48 4.7 Problematiche relative al tempo di attesa Quando il server non può rispondere ad una richiesta, risponde con uno stato diverso da 200 (OK). Ma in caso di latenze questo non accade. È opportuno, quindi, controllare il lasso di tempo intercorso tra l azione richiesta da parte dell utente e la reale possibilità di soddisfare il suo intento, specie qualora il server avesse frequenti problemi di banda o di velocità. La reazione tipica dell utente che non riceve risposta da una pagina è quella di tentare di ricaricarla ripetutamente. Questo comportamento dovrebbe essere evitato, in quanto aggiunge richieste ad un server già saturo, che non riuscirà a smaltire il suo carico, continuando a lasciare l utente in attesa di una risposta. Inoltre, ricaricare una pagina sviluppata con tecnica AJAX, significa ricaricare la pagina così com è inizialmente, senza ovviamente i vari passaggi intermedi di caricamento delle informazioni dei vari frame costituenti la pagina da parte dell utente. Le situazioni descritte possono essere affrontate in diversi modi. In generale, si possono adottare i seguenti due semplici approcci: gestione di un time-out: il meccanismo più importante che si deve realizzare è una temporizzazione. È necessario decidere, ovviamente lato client, dopo quanto tempo di attesa senza risposta si può considerare fallita la richiesta dell utente. Ciò dipende dalla tipologia dell applicazione e dal tipo di richiesta effettuata (dimensione della risposta, tempo richiesto dal server per elaborare la risposta, etc.). In caso di fallimento è opportuno avvisare l utente per non lasciarlo in balia dell attesa. Controllo sul link: è necessario disabilitare la sua funzionalità nel caso in cui l utente abbia effettuato una richiesta che di solito può richiedere del tempo prima di essere inviata e ricevuta. Questo semplice meccanismo è utile soprattutto in situazioni critiche e potrebbe non essere sempre indispensabile, ma comunque può essere la maggiore fonte di stabilità o velocità di una pagina potenzialmente ricca di accessi simultanei e con questo semplice accorgimento, non si corre il rischio di sovracaricare il server con richieste multiple ed identiche Gestione dell attesa Oltre al controllo sul tempo di risposta per evitare richieste stressanti, è importante tener conto del problema dell attesa rivolto all intrattenimento del navigatore, per non lasciarlo in balia delle azioni compiute ed inconsapevole di ciò che stia succedendo. È noto che un azione non corrisposta immediatamente, in quanto richiede del tempo di elaborazione, può portare l utente a disorientarsi su ciò che stia facendo. Gli atteggiamneti più comuni sono quelli di ritentare l operazione più volte, porsi dei 41

49 4 Le tecnologie AJAX dubbi sul fatto di aver sbagliato o che il sito sia bloccato e così via. Un messaggio temporaneo può rassicurare il navigatore sull avvenuta richiesta e migliorare così l usabilità del sito. In Flash si aggira il problema usando i loader: elementi grafici leggeri che eliminano la sensazione di un attesa statica rappresentando la percentuale di caricamento con l ausilio di una barra di progressione o con del testo esplicito. Con AJAX si può fare analogamente, in quanto esistono svariati siti, come per esempio che mettono a disposizione alcune immagini gif animate da poter sfruttare durante l attesa, come quelle indicate nella figura 4.7. Figura 4.7. Indicatori di attesa Un consiglio che viene dato sulla scelta della giusta animazione di intrattenimento è quello di non mostrare un immagine né troppo grande né troppo piccola, ed è, inoltre, importante evitare di mostrare un animazione troppo frenetica al fine di rispettare anche gli utenti che al posto di una crisi epilettica avrebbero voluto solo raggiungere un informazione. 42

50 Capitolo 5 Rich Internet Application mediante OpenLaszlo 5.1 Introduzione: che cos è OpenLaszlo OpenLaszlo è una tecnologia open per creare RIA (Rich Internet Application), basate inizialmente su Flash partendo da un descrittore di interfaccia XML (il sito istituito si trova all indirizzo Questo progetto open è nato dall azienda americana Laszlo Systems ( ed è largamente sponsorizzato dall azienda IBM, la quale ha donato anche un ambiente IDE basato su Eclipse ( Entrambe queste aziende fanno parte dell organizzazione OpenAjax Alliance, il cui obiettivo è quello di agevolare la conoscenza e lo sviluppo della tecnologia AJAX, come spiegato nel capitolo precedente. Lo sviluppo di questo progetto, attualmente, dà la possibilità di poter scegliere tra due modalità di presentazione: quella in Flash e, dalla fine del 2006, anche in HTML/DHTML, ovviamente con funzioni AJAX. L obiettivo dell azienda Laszlo Systems, oltre a quello di creare un ambiente completo che agevola la creazione di applicativi web avanzati e con funzionalità AJAX, è quello di mantenere la portabilità del codice sorgente, anche su dispositivi, sistemi operativi e plugin differenti. 5.2 Architettura client e server Il server OpenLaszlo è un applicazione Java che viene eseguita in un J2EE servlet container. Questo server permette la comunicazione con altri server per reperire varie informazioni e dati, in quanto sono supportati vari protocolli (lato back end). Un applicazione OpenLaszlo viene scritta con un particolare linguaggio chiamato 43

51 5 Rich Internet Application mediante OpenLaszlo LZX e che è 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 che ne ha fatto richiesta (lato front end). Attualmente l ambiente run-time supportato è il plug-in Flash 7 o versione superiore, il quale è disponibile per svariati sistemi operativi e dispositivi, quali ad esempio Windows, Pocket PC, Mac OS, Linux e Solaris, e per svariate piattaforme mobili e set-top box. Il bytecode generato è nel formato SWF ed è quindi riconosciuto dal player Macromedia Flash. Bisogna tenere conto, però, che nulla dell architettura di OpenLaszlo è strettamente vincolata alla tecnologia Flash. Infatti, questo ambiente di sviluppo prevede, in futuro, la possibilità di supportare altri ambienti run-time per client. Di fatto, per la fine del 2006 è stato reso disponibile l ambiente run-time DHTML, inizialmente in versione sperimentale e con uso consigliato su browser FireFox 1.5. La figura 5.1 mostra l architettura client-server nel contesto di OpenLaszlo. Il client è costituito da un web browser con il plugin opportuno installato, il quale a sua volta permette l esecuzione dell applicazione LZX richiesta; mentre il server è in grado di comunicare con altri server presenti su Internet e gestisce le varie richieste dei client. La comunicazione fra il client e il server avviene mediante il tradizionale protocollo http: il server invia bytecode, mentre il client invia dati in formato XML. Inoltre, è anche supportato il protocollo HTTPS per poter così attivare e gestire un collegamento sicuro. Figura 5.1. Architettura client-server OpenLaszlo 44

52 5.3 Architettura del server OpenLaszlo 5.3 Architettura del server OpenLaszlo Come detto in precedenza, il server OpenLaszlo è un applicazione Java che viene eseguita in un J2EE servlet container in cui gira l ambiente JRE 1.4 o superiore. Questo ambiente di sviluppo è multipiattaforma (Windows, Solaris, Linux, Mac OS X,... ). Come si può anche notare dalla figura 5.2, il server OpenLaszlo è costituito da 5 principali 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

53 5 Rich Internet Application mediante OpenLaszlo Il modulo Interface Compiler Il linguaggio LZX consiste di tag XML specifici per creare oggetti JavaScript e di codice JavaScript per poter manipolare tali oggetti (i dettagli di tale linguaggio verrano illustrati successivamente alla sezione 5.8). Per tale motivo, il modulo Interface Compiler è costituito da due parti: 1. LZX Tag Compiler; 2. LZX Script Compiler. Inoltre, questo modulo invoca i moduli Media Transcoder ( o Compiler) e Data Manager, rispettivamente per compilare informazioni multimediali e dati che saranno poi integrati nell applicazione. I due compilatori convertono i tag XML e il codice JavaScript del file sorgente LZX in bytecode eseguibile (formato SWF) che sarà trasmesso all ambiente client OpenLaszlo. Questo codice viene prima memorizzato nella cache e poi inviato al client. In base all applicazione che viene invocata, può essere trasmesso o un file con estensione SWF o un file HTML contenente all interno un oggetto SWF. Il Media Transcoder ha il compito di convertire una vasta gamma di formati multimediali in un unico formato che sarà poi visualizzato sul client mediante il motore di rendering. Questo meccanismo permette all applicazione OpenLaszlo di gestire i vari formati multimediali in maniera unificata senza dover utilizzare software aggiuntivo. 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 binario compresso, il quale è interpretabile dall applicazione OpenLaszlo; 2. una serie di componenti (Data Connector) che consentono all applicazione OpenLaszlo di reperire dati via XML/HTTP. Grazie a questa caratteristica è possibile l interfacciamento mediante la rete Internet con database, XML Web Service e altri Web Server. Il modulo Persistent Connection Manager È il modulo che gestisce connessioni persistenti, cioè autenticazioni o messaggi realtime verso un applicazione OpenLaszlo che ne ha fatto richiesta. Questa caratteristica è, però, al momento provvisoria. 46

54 5.4 Architettura del client OpenLaszlo Il modulo Cache La cache contiene la versione più recente compilata di ogni applicazione. La prima volta che un applicazione OpenLaszlo viene richiesta, essa viene compilata e il risultante file SWF viene inviato al client. Una copia viene anche memorizzata nella cache del server, in modo tale che altre richieste non richiedano tempi di attesa dovuti 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 compilata e inglobata in ogni applicazione e che fornisce i servizi run-time, quali ad esempio funzioni timer e di attesa. 47

55 5 Rich Internet Application mediante OpenLaszlo 2. Presentation Renderer: fornisce il rendering della grafica 2D e la riproduzione del suono. Nessuna di queste classi dipende dai servizi Flash o usa il modello ad oggetti di Flash. Il player Flash è usato esclusivamente come motore di rendering. Si prenda in considerazione il seguente esempio di applicazione vuota: <canvas/> Quando questa banalissima applicazione è in esecuzione, sebbene non faccia nulla, mantiene una connessione con il server e tutte le potenzialità necessarie per il funzionamento 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 È responsabile della rilevazione e della gestione degli eventi a cui può essere soggetta l applicazione LZX, come ad esempio la pressione del tasto del mouse o la ricezione dei dati inviati dal server a seguito di una richiesta asincrona del client. È da sottolineare il meccanismo asincrono tra client e server: il server invia solo i dati richiesti e il client effettua una visualizzazione dinamica e fluida solo della parte interessata. Il modulo Data Loader/Binder Ha la funzione di gestire il flusso del traffico di dati, compreso quello proveniente dalla rete, in quanto effettua l associazione delle informazioni richieste con il corrispondente componente dell interfaccia utente, quale ad esempio un campo di testo, un form o gli elementi di un menu. 48

56 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 posizionamento degli oggetti in maniera relativa (ad esempio posizione centrata, disposizione degli elementi lungo l asse orizzontale e così via) o assoluta (indicando le coordinate x e y in pixel). Grazie ad algoritmi di animazione, è possibile creare interfacce dinamiche, ovvero è possibile gestire sia il movimento degli oggetti che l 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 può essere resa disponibile sul web (operazione di deploy) in due modalità: 1. modalità Proxied. Il server OpenLaszlo gira sulla macchina dello sviluppatore e: compila i programmi sorgenti, effettua l operazione di link con le varie librerie e invia il risultante codice binario per essere eseguito sul client; gestisce le interazioni fra il client e gli altri server su internet, in maniera trasparente allo sviluppatore. 2. Modalità SOLO (Standalon OpenLaszlo Output) o serverless. Viene sfruttato il compilatore di OpenLaszlo per precompilare il sorgente e rendere disponibile il file binario sul server. Quando avviene l esecuzione sul browser, l applicazione contatta direttamente gli altri server senza la mediazione del server OpenLaszlo. Quindi, un applicazione LZX messa in linea in modalità Proxied può fare solo poche operazione in più di un applicazione resa disponibile in modalità SOLO, come ad esempio la gestione delle chiamate remote (Java RPC, SOAP RPC e XML RPC). Ma l operazione di deploy della prima tipologia è più complessa e di solito le prestazioni sono più lente. Quindi, la seconda tipologia permette un operazione di deploy più semplice e con migliori prestazioni. Nella maggior parte dei casi, la decisione della modalità di deploy può essere presa anche solo nel momento stesso in cui l applicazione LZX debba essere resa disponibile in linea. Di solito, salvo 49

57 5 Rich Internet Application mediante OpenLaszlo la necessità di utilizzare le funzionalità dette sopra, la scelta ricade sulla modalità SOLO e bisogna tenere conto, quindi, che non sono disponibili le funzionalità dei moduli 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 lato server quando un utente richiede un applicazione LZX messa in linea in modalità proxied. In un applicazione OpenLaszlo, lo strato presentation-related logic è separato dallo strato business logic e viene eseguito localmente sul client. Il server OpenLaszlo invia al client dati binari compressi piuttosto che testo, riducendo così la quantità 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 Modello di Sicurezza La piattaforma OpenLaszlo supporta il modello di sicurezza SSL. La trasmissione dati attraverso la rete Internet può essere criptata utilizzando il meccanismo di codifica SSL su canale HTTPS. Inoltre, le applicazioni vengono eseguite su un client mediante uno strato intermedio costituito dal Player Flash, ritenuto sicuro, in quanto non permette l accesso al file system. I web service e i database usati dal server sono ritenuti sicuri, in quanto viene utilizzato un modello di autenticazione per utente. Questo meccanismo previene l utilizzo del server come proxy o gateway insicuro per fornire servizi o tramettere dati Supporto della piattaforma per dispositivi differenti L architettura OpenLaszlo è progettata per supportare tipi di dispositivi differenti. Viene sfruttato un meccanismo dinamico per la gestione del layout che abilita semplici modifiche ad alcune proprietà, quali ad esempio un ridimensionamento intelligente dell applicazione per adattarsi in modo semplice alle differenti capacità dello schermo a disposizione dell utente. Tale peculiarità viene anche definita come interfaccia liquida. Il supporto verso dispositivi e sistemi operativi differenti è legato alla disponibilità dell ambiente run-time utilizzato verso i medesimi. 50

58 5.7 Caratteristiche supportate dalla piattaforma Figura 5.4. Interazione fra client e server OpenLaszlo 51

59 5 Rich Internet Application mediante OpenLaszlo La visualizzazione di un applicativo su qualsiasi tipologia di schermo è legata ad animazioni basate sul tempo piuttosto che sui frame e perciò risulta più trasparente adattarsi alle differenti velocità dei processori. Quindi, una determinata transizione dell interfaccia che richiede 500 ms, impiegherà 500 ms senza tenere conto del numero di frame mostrati, ovvero processori più veloci visualizzeranno più frame al secondo e l animazione risulterà più fluida, ma la durata sarà sempre la stessa Accessibilità OpenLaszlo fornisce parziale supporto per le specifiche Microsoft Active Accessibility, ovvero usando tale tecnologia e seguendo le regole di accessibilità è possibile per gli sviluppatori progettare applicazioni per Windows che possono essere utilizzate anche da persone con disabilità visive, uditive e motorie. Questo supporto ha ancora delle limitazioni, in quanto richiede l installazione di software di terze parti sul computer client ed è solo disponibile per ambiente Flash Player per il browser Internet Explorer. 5.8 Il Linguaggio LZX Il linguaggio LZX, basato su tag ed orientato agli oggetti, utilizza la sintassi del codice XML e JavaScript per creare l Interfaccia Utente Grafica (GUI) delle Rich Internet Application (RIA). Vengono illustrati, di seguito, gli aspetti più significativi del linguaggio LZX relativi allo svolgimento di questo lavoro di tesi. Per una introduzione e per chiarimenti su questo linguaggio, che esulerebbero dagli obiettivi di questa sezione, si rimanda ai manuali presenti su Internet agli indirizzi [18] e [19]. Costruzione di una tabella Mediante gli elementi <grid> e <gridcolumn> è possibile gestire dati in tabella. I dati sono formatatti in XML e possono essere sia interni al codice, come in questo esempio, sia su file caricato in remoto o in locale. <canvas title="tabella.lzx" width="500" height="400"> <dataset name="contatti"> <contatto ="davide@libero.it">davide</contatto> <contatto ="andrea@tiscali.it">andrea</contatto> 52

60 5.8 Il Linguaggio LZX <contatto <contatto <contatto <contatto <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="id " width="150"> <text id="id testo" /> </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

61 5 Rich Internet Application mediante OpenLaszlo 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 che definisce la struttura della finestra stessa e l operatore new() che la alloca. Non esiste invece il componente tooltip che viene creato artificialmente con l elemento <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

62 5.8 Il Linguaggio LZX <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

63 5 Rich Internet Application mediante OpenLaszlo <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

64 5.8 Il Linguaggio LZX Web Service (SOAP) La porzione di codice che segue, illustra come usare ed invocare un web service da parte di un applicazione LZX. <!-- * SpellingSuggestion.lzx *************************************** * SOAP Web Service Google Spelling Suggestion * * ************************************************************ --> <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=" <handler name="onload"> Debug.write( Servizio SOAP di Google: CARICATO! :-) ); Debug.write( "WSDL SOAP operations" e "proxy stubs" ); Debug.write( GoogleSearch + 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> <!-- Operazione RPC (Remote Procedure Calls) --> <remotecall name="ricerca" funcname="dospellingsuggestion" dataobject="risultatoricerca"> <!-- codice dell account. limite: < 100 ricerche --> <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

65 5 Rich Internet Application mediante OpenLaszlo <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> Ciò 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

66 5.8 Il Linguaggio LZX Capacità di adattamento alle varie risoluzioni dello schermo (Interfaccia liquida) Per questo scopo è necessario creare la propria applicazione come un file di libreria (elemento <library>), anziché come normalmente viene fatto all interno dell 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 è necessario creare file multipli, uno per ogni tipologia di risoluzione che si intende supportare. mainapplication640.lzx: <canvas width="640" height="480"> <include href="mainapplication.lzx"/> </canvas> mainapplication800.lzx: <canvas width="800" height="600"> <include href="mainapplication.lzx"/> </canvas> mainapplication1024.lzx: <canvas width="1024" height="768"> <include href="mainapplication.lzx"/> </canvas> mainapplication1280.lzx: <canvas width="1280" height="1024"> <include href="mainapplication.lzx"/> </canvas> 59

67 5 Rich Internet Application mediante OpenLaszlo Per un utilizzo effettivo di tale applicativo, è richiesto aggiungere del codice JavaScript per effettuare il controllo in maniera automatica della risoluzione dello schemo e scegliere così correttamente le dimensioni del <canvas> quando un utente vi accede. <!-- Utilizzando il comando è possibile selezionare le dimensioni del <canvas> più adatte alle proprie esigenze. --> <script type="text/javascript"> var screenw = screen.width; var screenh =0; switch (true) { case (screenw >= 1280): screenw = 1280; screenh = 1024; break; case (screenw >= 1024): screenw = 1024; screenh = 768; break; case (screenw >= 800): 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

68 5.8 Il Linguaggio LZX A titolo di esempio, nella figura 5.8, si riportano due schermate con risoluzioni differenti. 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, è 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

69 5 Rich Internet Application mediante OpenLaszlo <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 ottengono sono riportati nella figura 5.9. Figura 5.9. Finestra del browser ridimensionata (sinistra) e successivamente allargata (destra) 62

70 Capitolo 6 Caso di studio: GUI di IntelliPatent Requisiti Dopo un analisi delle caratteristiche richieste dagli applicativi web, in particolare quelli 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 i requisiti elencati di seguito. Requisiti sull usabilità Funzionalità RIA. Necessità di gestire le richieste dell utente in maniera asincrona, evitando il caricamento di tutta la pagina ad ogni interazione e ottenendo così un interfaccia grafica che cambia stato con continuità visuale. Oltre ad un effetto grafico gradevole, il non ricaricamento della pagina consentirebbe all utente di continuare il suo lavoro senza interruzioni. Velocità di ricerca. Una caratteristica fondamentale di un interfaccia di ricerca è quella di poter fornire nel più breve tempo possibile i risultati. Per ridurre il tempo d attesa, si rende necessario l implementazione di un meccanismo di caricamento dei dati di una riga alla volta man mano che i dati stessi vengono trovati. Interattività. Consentire all utente l utilizzo dei dati man mano che vengono caricati, come ad esempio il salvataggio delle informazioni in diversi formati o il confronto di esse mediante l apertura di più finestre contemporaneamente. 63

71 6 Caso di studio: GUI di IntelliPatent 4.0 Intuitività. Offrire un interfaccia molto simile a quelle usate per il desktop e con funzionalità semplici e intuitive, al fine di poter fare usufrire l applicazione ad un utenza poco esperta nel settore informatico. Facilità d uso. Rendere usabile la visualizzazione dei dati su video, organizzandoli in tabelle e finestre che agevolano sia la consultazione sia il confronto delle informazioni stesse. Interfaccia liquida. Adattare le dimensioni dell interfaccia alle differenti capacità dello schermo a disposizione dell utente per ottimizzare l usabilità dell applicativo stesso. Requisiti sull accessibilità Accessibilità hardware e software. Obiettivo del progetto è realizzare un applicativo che non sia vincolato dal sistema operativo o dal browser utilizzato al lato client. Accessibilità fisica. Non sono richieste particolari esigenze, ma il rispetto di determinate normative permetterebbe di rendere il contenuto navigabile e fruibile a un maggior gruppo di utenti. Requisiti sulle funzionalità Funzionalità dell applicativo. Per una migliore fruizione del servizio, si rende necesssario implementare varie funzionalità, quali funzioni di filtro per restringere i risultati della ricerca effettuata, funzione di ordinamento per varie colonne e salvataggio dei dati in vari formati. Facilità di manutenzione. Ottenere un programma organizzato in maniera modulare, con parti di codice riutilizzabili e soprattutto la cui interfaccia grafica sia disaccoppiata dalla logica di business. Qualora si rendesse necessario ritoccare la procedura, lo si potrà fare agendo in un punto solo con evidenti vantaggi in termini di tempo e di affidabilità. 6.2 Scelta delle tecnologie È importante notare come AJAX non sia precisamente definito. Un framework AJAX è il motore che permette ad un sito o ad un applicativo web di sfruttare gli effetti della tecnologia asincrona AJAX ormai sempre più presenti nei siti denominati Web 2.0. Di framework AJAX ne esistono diversi e ne nasceranno sempre di più, 64

72 6.2 Scelta delle tecnologie in quanto si tratta di un linguaggio libero e alla portata di molti programmatori. Tra i vari si può nominare Dojo toolkit, Prototype, OpenRico e Scriptaculous, ma l elenco sarebbe davvero molto lungo. Ogni framework AJAX possiede la propria libreria implementata con JavaScript asincrono. La differenza principale sta nel risultato finale, cioè nel tipo di effetto grafico che si può ottenere e nei componenti messi a disposizione. Ma l aspetto più importante consiste nella leggerezza di esecuzione dello script. Infatti, benché si pensi che sia solo codice, alcuni di questi effetti non agevolano la velocità di un sito, ovvero non ne favoriscono il caricamento. Ciò è dovuto al fatto che questi effetti sono caratterizzati da parecchie linee di codice e troppo codice JavaScript appesantisce il lavoro della CPU. La conseguenza inevitabile è che le pagine web possono soffrire ritardi di alcuni secondi. Più un sito o un applicativo web è complesso e più tale problematica diventa rilevante. Dal lato della programmazione, si può osservare la mancanza di un ambiente di sviluppo paragonabile a quello di altri linguaggi di programmazione, ovvero un ambiente che faciliti lo sviluppo e il debug delle Rich Internet Application. La figura 6.1 mostra le differenze tra lo stack software di un applicativo scritto in DHTML con le funzionalità del linguaggio JavaScript asincrono e lo stack software dell ambiente OpenLaszlo. Figura 6.1. Confronto tra lo stack DHTML e quello di OpenLaszlo L ambiente di sviluppo del progetto OpenLaszlo, utilizzato per implementare la nuova interfaccia di IntelliPatent, comprende le seguenti caratteristiche: 65

73 6 Caso di studio: GUI di IntelliPatent 4.0 piattaforma open source nata principalmente per lo sviluppo di applicazioni, la cui installazione comprende un ambiente completo di server, librerie e strumenti per rilevazione di errori di sintassi nel codice sorgente e per il debug dell applicativo; vari ambienti di editing con funzionalità che facilitano la scrittura del codice sorgente; portabilità su ogni browser (a differenza del DHTML) e architettura pensata per adattarsi ad ambienti multipli di resa runtime; presenza di vari esempi di applicativi con codice sorgente disponibile; presenza di componenti e funzionalità richieste per la GUI di IntelliPatent. 6.3 Progettazione: implementazione mediante Open- Laszlo Di seguito vengono illustrati gli aspetti più significativi riguardanti l implementazione di IntelliPatent 4.0, le principali problematiche affrontate e le relative soluzioni adottate per la realizzazione della GUI. Struttura della GUI Viste le varie funzionalità che l interfaccia utente deve gestire, una soluzione usabile è quella di suddividere l applicativo in 5 finestre differenti, le cui interazioni con l utente sono mostrate in figura 6.2. L interfaccia è, quindi, implementata su 5 pagine LZX, le cui funzionalità sono descritte 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 più efficiente, ovvero: è possibile disabilitare le funzionalità del browser, quali ad esempio i pulsanti avanti e indietro o il tasto di ricaricamento pagina. Come spiegato nella sottosezione a pagina 37, l utilizzo di tali funzioni in un applicativo asincrono potrebbe portare l utente a disorientarsi, in quanto non otterrebbe il risultato desiderato. Inoltre, un applicativo come IntelliPatent è dotato di tutte le funzioni di cui un utente necessita per lavorare e le funzioni del browser porterebbero a compiere azioni non corrette o inutili per interagire con la GUI. 66

74 6.3 Progettazione: implementazione mediante OpenLaszlo Figura 6.2. Diagramma di interazione dell utente con la GUI di IntelliPatent 4.0 Pagina LOGIN SEARCH RESULT ALERT alertresult Descrizione pagina per accedere all applicativo mediante autenticazione pagina che gestisce il form di ricerca pagina che gestisce i risultati ricercati mediante tabelle e finestre pagina che permette la ricerca in tempo differito mediante segnalazione con pagina che gestisce i risultati ricercati tramite ALERT (simile alla pagina RESULT) Tabella 6.1. Organizzazione delle pagine della GUI 67

75 6 Caso di studio: GUI di IntelliPatent 4.0 È possibile mediante l attributo hidden nascondere i dati passati tra le varie pagine dell applicazione, ovvero tutte le variabili passate mediante il metodo HTTP GET non saranno visibili sulla barra degli indirizzi del browser, ottenendo così una garanzia di sicurezza e riservatezza dei dati. È possibile inserire comandi che permettono di controllare la presenza del plugin Flash, agevolando così l utente nella rilevazione e installazione del componente mancante. Viene riportato di seguito il codice della pagina JSP che richiama il file login.lzx. Il codice JSP delle altre 4 pagine è analogo. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " <html xmlns=" 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, <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

76 6.3 Progettazione: implementazione mediante OpenLaszlo <param name="scale" value="noscale" /> <param name="salign" value="lt" /> <param name="menu" value="false" /> <param name="pluginspage" value=" /> </object> </td> </tr> </table> </body> </html> Interazione con il Web Service (SOAP) Alcune funzionalità dell interfaccia utente sono rese disponibili grazie all invocazione delle funzioni di un web service mediante il protocollo SOAP. Tale web service è stato realizzato dall azienda IntelliSemantic e costituisce la logica di business. A titolo di esempio, si riporta il codice delle operazioni di login e di logout. Queste interazioni della GUI con il web service sono necessarie per gestire correttamente la sessione di un utente. Il codice dell operazione di login garantisce l autenticazione dell utente. <!-- Operazione RPC (Remote Procedure Calls) --> <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

77 6 Caso di studio: GUI di IntelliPatent 4.0 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 di memoria riservato all utente connesso, liberando così spazio sul server. <!-- Operazione RPC (Remote Procedure Calls) --> <remotecall name="logout" funcname="logout" dataobject="logout"> <handler name="ontimeout" args="errortimeout"> patent.logout.invoke([idsession]); </handler> <handler name="ondata" args="value"> 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 e di logout viene riportato nella figura

78 6.3 Progettazione: implementazione mediante OpenLaszlo Figura 6.3. Gestione del login e del logout Gestione dell autenticazione delle sessioni Una delle funzionalità richieste è quella di gestire l autenticazione dell utente nelle varie pagine dell interfaccia, evitando così tentativi di accesso alle varie finestre di IntelliPatent, forzandone il caricamento senza aver effettuato l operazione di login. Questo problema è stato risolto utilizzando un identificativo di sessione (idsession), il quale è un numero di 20 cifre generato casualmente dal server in fase di login, come illustrato nella sottosezione precedente. Ciò rende molto complicato l accesso non autorizzato alle varie pagine dell applicativo da parte di utenti non registrati, i quali vengono riportati alla pagina di login. Inoltre, tale identificativo permette di riconoscere l utente nelle varie pagine dell interfaccia, tenendo traccia delle sue scelte e dei suoi dati. 71

79 6 Caso di studio: GUI di IntelliPatent 4.0 Il meccanismo di gestione degli accessi non autenticati è illustrato nella figura 6.4. Figura 6.4. Diagramma di gestione degli accessi non autenticati Il codice LZX relativo all implementazione di questa funzionalità è riportato di seguito.... <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

80 6.3 Progettazione: implementazione mediante OpenLaszlo <!-- Operazione RPC (Remote Procedure Calls) --> <remotecall name="isalive" funcname="isalive" dataobject="dsisalive"> <handler name="onerror" args="error"> Debug.write( isalive - Errore:, error); </handler> <handler name="ontimeout" args="errortimeout"> Debug.write( isalive - Timeout:, errortimeout); patent.isalive.invoke([idsession]); // re-invio segnale </handler> <handler name="ondata" args="value"> 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 il codice LZX. Si può notare come il problema dell autenticazione viene risolto mediante l invocazione della funzione isalive(ids) del web service. Tale funzione è utilizzata anche per gestire la chiusura automatica delle sessione, come spiegato nella sottosezione successiva. 73

81 6 Caso di studio: GUI di IntelliPatent 4.0 Figura 6.5. Meccanismo di gestione degli accessi non autenticati Gestione della chiusura automatica delle sessioni Può accadere che il browser venga chiuso senza aver effettuato l operazione di logout. Ciò comporterebbe un sovraccarico inutile al server, in quanto non si effettuerebbe la deallocazione dello spazio di memoria riservato alla gestione della sessione dell utente. Si rende necessario la realizzazione di un meccanismo lato client che periodicamente invii un segnale al server per indicare che la sessione è ancora attiva. Il linguaggio LZX non permette attualmente di gestire temporizzazioni, pertanto tali funzioni devono essere implementate lato server. Il meccanismo di interazione fra client e server è mostrato nella figura 6.6, mentre la parte di codice LZX relativa è stata già indicata nella sottosezione precedente riguardante la gestione non autenticata degli accessi. 74

82 6.3 Progettazione: implementazione mediante OpenLaszlo Figura 6.6. Meccanismo per gestire la chiusura automatica della sessione 75

83 6 Caso di studio: GUI di IntelliPatent 4.0 Nelle figure 6.7 e 6.8 vengono analizzati i casi di perdita di segnale da parte del client e del server, dando così una valutazione della robustezza dell algoritmo proposto. Figura 6.7. Meccanismo per gestire la chiusura automatica della sessione: caso di perdita del segnale lato client La scelta di un valore maggiore per il secondo timer permette di tollerare la perdita consecutiva di più segnali isalive(ids). 76

84 6.3 Progettazione: implementazione mediante OpenLaszlo Figura 6.8. Meccanismo per gestire la chiusura automatica della sessione: caso di perdita del segnale lato server Invece, la perdita di uno o più segnali consecutivi lato server non comporta problemi, in quanto allo scadere del timeout il client invia un nuovo segnale e il meccanismo riparte correttamente. Caricamento dei brevetti Il caricamento di una riga alla volta delle informazioni in tabella non è una funzione nativamente supportata dall ambiente OpenLaszlo, ma non per questo proibita. Questa funzionalità si ottiene grazie alla gestione asincrona delle chiamate remote al web service da parte del linguaggio LZX, che consente di non effettuare il caricamento di tutta la pagina, ma bensì l aggiornamento della sola parte interessata. 77

85 6 Caso di studio: GUI di IntelliPatent 4.0 La parte di codice che realizza tale meccanismo implementato ad hoc è riportato di seguito. <!-- Rappresentazione del documento XML --> <dataset name="nextpatent" />... <!-- Operazione RPC (Remote Procedure Calls) --> <remotecall name="getnextpatent" funcname="getnextpatent" dataobject="nextpatent"> <handler name="onerror" args="error"> patent.getnextpatent.invoke([idsession]); </handler> <handler name="ontimeout" args="errortimeout"> patent.getnextpatent.invoke([idsession]); </handler> <handler name="ondata" args="value"> // 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

86 6.3 Progettazione: implementazione mediante OpenLaszlo contatorerighe++; canvas.barraapprox(); // chiamata successiva patent.getnextpatent.invoke([idsession]); } 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 getnextpatent del web service che ritorna un brevetto alla volta e viene schematizzato dal diagramma di flusso della figura

87 6 Caso di studio: GUI di IntelliPatent 4.0 Figura 6.9. Flow-chart per il caricamento dei brevetti 80

88 6.3 Progettazione: implementazione mediante OpenLaszlo Il risultato che si ottiene sulla GUI di IntelliPatent 4.0 è mostrato nella schermata della figura Figura Caricamento dei brevetti riga per riga Si può osservare come sia possibile aprire più finestre contemporaneamente anche si fase di caricamento per poter già lavorare con l applicativo. Visualizzazione del file XML Nel linguaggio LZX non sono supportati comandi per visualizzare il contenuto di un file XML in maniera formattata. La soluzione più semplice è quella di demandare tale funzione ad una pagina JSP richiamata dal codice LZX seguente. <button isdefault="true">view <handler name="onclick"> finestrasave.close(); 81

89 6 Caso di studio: GUI di IntelliPatent 4.0 <![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 può osservare come il passaggio dei parametri tra la pagina LZX e JSP avviene mediante il metodo HTTP GET. Di seguito si riporta il codice relativo alla pagina JSP che svolge tale funzionalità. <%@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

90 6.3 Progettazione: implementazione mediante OpenLaszlo }... 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 risultato ottenuto. Figura Meccanismo per la visualizzazione di un file XML 83

91 6 Caso di studio: GUI di IntelliPatent 4.0 Salvataggio dei file Un altra problematica riscontrata è l assenza nel linguaggio LZX di comandi per la gestione del file system e, quindi, per il salvataggio dei file. Anche in questo caso la soluzione è quella di ricorrere all utilizzo di una pagina JSP richiamata dal seguente codice LZX. <button>save <handler name="onclick"> 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 individuati 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 " ).join(" "); SaveFrame.document.open("text/html","replace"); SaveFrame.document.write(str); SaveFrame.document.close(); 84

92 6.3 Progettazione: implementazione mediante OpenLaszlo } </script> SaveFrame.focus(); var file=""; if ( msieversion() > 6 ) file = filename; else file = filename + ext; SaveFrame.document.execCommand( SaveAs,false,file); } <% // 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

93 6 Caso di studio: GUI di IntelliPatent 4.0 Lo schema di figura 6.12 riporta il principio di funzionamento e il risultato ottenuto. Figura Meccanismo per il salvataggio dei file 6.4 Valutazione dei risultati raggiunti Di seguito vengono riportate delle schermate di come si presenta l interfaccia utente grafica realizzata per IntelliPatent 4.0, illustrando i requisiti della sezione 6.1 che sono stati soddisfatti e i punti critici incontrati. Dopo una schermata di login (figura 6.13), che permette l autenticazione dell utente, si accede al modulo di ricerca (6.14). 86

94 6.4 Valutazione dei risultati raggiunti Figura IntelliPatent 4.0: finestra di LOGIN Figura IntelliPatent 4.0: finestra di SEARCH Il form di ricerca prevede la presenza di codice JavaScript per il controllo della correttezza della compilazione dei vari campi con eventuale segnalazione dei campi mancanti o inesatti. Inoltre, è presente la funzione di cronologia (history) delle varie ricerche effettuate. 87

95 6 Caso di studio: GUI di IntelliPatent 4.0 Dal menu è possibile selezionare il caricamento della finestra di alert (figura 6.15), per gestire la ricerca in tempo differito tramite segnalazione dell avvenuta ricerca mediante indirizzo . Figura IntelliPatent 4.0: finestra per la gestione degli ALERT 88

96 6.4 Valutazione dei risultati raggiunti Le schermate con le tabelle dei risultati ottenuti, sia in tempo reale sia in tempo differito, sono simili e mostrate nelle figure 6.16 e Figura IntelliPatent 4.0: prima tabella con i risultati Per una maggiore comodità di visualizzazione dei dati, le numerose colonne contenenti le informazioni brevettuali sono state raggruppate e suddivise in due tabelle, a loro volta gestite mediante l uso di schede (tab), eliminando così la barra di scorrimento orizzontale ritenuta una soluzione poco usabile. Inoltre, le colonne delle tabelle possono essere ordinate. Questa funzionalità è stata sviluppata lato client grazie alle funzioni della libreria fornita da OpenLaszlo. Anche in presenza di molte informazioni ricercate, l ordinamento delle righe delle tabelle risulta veloce. 89

97 6 Caso di studio: GUI di IntelliPatent 4.0 Un osservazione importante va fatta sulle due tabelle. Esse risultano sincronizzate sia nell ordinamento che nella selezione di una riga, in modo tale da avere le varie righe delle due tabelle sempre correlate fra di loro. Figura IntelliPatent 4.0: seconda tabella con i risultati aggiuntivi Infine, si può osservare come sia possibile aprire più finestre contemporaneamente per una migliore consultazione e per un facile confronto delle informazioni brevettuali. 90