UNIVERSITÀ DEGLI STUDI DI FERRARA
FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA SPECIALISTICA DI
INGEGNERIA INFORMATICA
PROTOTIPO DI UN
WEB OPERATING SYSTEM
SVILUPPATO CON TECNOLOGIA WEB 2.0
Tesi di Laurea di:
MARGUTTI FRANCESCO
Relatore:
Prof. Ing. CESARE
STEFANELLI
Correlatore
Ing. LUCA TEBALDI
ANNO ACCADEMICO 2005 - 2006
Università degli studi di Ferrara
2
Università degli studi di Ferrara
a papà e mamma
3
Università degli studi di Ferrara
4
Università degli studi di Ferrara
INDICE
INTRODUZIONE ..................................................................... 9
Capitolo 1: IL WEB, VERSIONE 2.0.................................. 15
1.1
Storia del Web ........................................................................... 15
1.2
Caratteristiche del Web ............................................................. 16
1.3
I limiti del Web 1.0 ..................................................................... 17
1.4
Il Web 2.0 .................................................................................. 18
1.5
Confronto fra Web 1.0 e Web 2.0.............................................. 20
1.6
Le Tecnologie ............................................................................ 22
1.7
Esempi di applicazioni in Web 2.0............................................. 25
1.7.1 Esempio 1: del.icio.us..................................................... 28
1.7.2 Esempio 2: Wikipedia ..................................................... 29
Capitolo 2: TECNOLOGIE e STRUMENTI ........................ 31
2.1
Asynchronous Javascript And XML : AJAX............................... 32
2.1.1 JavaScript ....................................................................... 36
2.1.2 XML................................................................................. 37
2.1.3 L’oggetto XMLHttpRequest: la A di AJAX....................... 40
2.1.4 Il DOM............................................................................. 40
2.1.5 I CSS............................................................................... 42
2.2
Il linguaggio per dialogare col server: Ruby .............................. 43
2.3
Il linguaggio di interrogazione col database: SQL ..................... 45
2.4
Lo strumento di sviluppo: Ruby on Rails ................................... 46
2.4.1 Architettura dell’applicativo: model / view / controller ..... 47
2.5
Prototype e script.aculo.us ........................................................ 49
5
Università degli studi di Ferrara
Capitolo 3: PROGETTO DESKTOP@UNIFE .....................51
3.1
Rich Internet Application ............................................................52
3.2
Motivazioni del progetto ............................................................54
3.3
Specifiche di progetto ................................................................55
3.4
Architettura del Web operating system ......................................57
3.4.1 Il “fat Client” .....................................................................59
3.4.2 L’application server .........................................................61
3.5
Fasi di progetto ..........................................................................62
Capitolo 4: DESKTOP@UNIFE: MANUALE UTENTE.......65
4.1
Accesso all’applicativo ...............................................................65
4.2
La “scrivania” del Web operating system...................................66
4.3
L’aggregatore di feed .................................................................68
4.4
Il gestore di mail.........................................................................71
4.5
Il gestore di bookmark................................................................74
4.6
L’editor di testo...........................................................................76
4.7
Il filesystem remoto ....................................................................80
4.8
La ricerca nel Web .....................................................................84
4.9
Help............................................................................................84
Capitolo 5: IMPLEMENTAZIONE DI [email protected]
5.1
Casi d’uso ..................................................................................87
5.2
I dati ...........................................................................................89
5.2.1 Entità e attributi ...............................................................91
5.3
Organizzazione Rails di “myportal” ............................................98
5.3.1 I controller......................................................................100
5.3.2 Le viste ..........................................................................102
5.3.3 Gli script e i file CSS .....................................................107
5.4
6
L’accessibilità dell’applicativo ..................................................109
Università degli studi di Ferrara
Capitolo 6: Conclusioni .................................................. 111
BIBLIOGRAFIA................................................................... 113
WEBGRAFIA ...................................................................... 115
RINGRAZIAMENTI ............................................................. 119
7
Università degli studi di Ferrara
8
Università degli studi di Ferrara
INTRODUZIONE
Quando si cerca di dare una definizione di cosa sia il Web 2.0, risulta sempre
piuttosto difficile trovare un modo unico e ben definito che ne esemplifichi tutte le
caratteristiche e potenzialità. In sostanza, con il Web 2.0, il Web diventa una vera e
propria piattaforma di sviluppo, nella quale poter implementare nuovi applicativi e
servizi residenti in remoto.
Web 2.0 è fondamentalmente un modo di intendere la rete, una "filosofia" fondata
su un insieme di approcci per usare il Web in modo nuovo e innovativo. Si sposta
l’attenzione su ciò che avrebbe dovuto essere fin da principio il fulcro di tutta la rete:
l'interazione con l’utente.
Risulta perciò piuttosto chiaro che il Web 2.0 non è un software specifico, né un
nuovo protocollo, né una nuova architettura o un nuovo standard ma bensì un
aggregatore di tecnologie che permettono ai dati di diventare indipendenti dalla
persona che li produce o dal sito in cui vengono creati. L'informazione può essere
suddivisa in unità che viaggiano liberamente da un sito all'altro, spesso in modi che
neanche il produttore aveva previsto o inteso.
Il paradigma del Web 2.0 permette agli utenti di prendere informazioni da diversi siti
simultaneamente e di distribuirle sui propri per nuovi scopi, confermando ancor più
la filosofia e la necessità di spostarsi verso l’open-source, cioè verso tutti quei
contenuti che risultano essere accessibili e utilizzabili in modo libero. Esso lascia ai
dati una identità propria, che può essere cambiata, modificata o miscelata da
chiunque per un suo scopo preciso. Una volta che i dati hanno una consistenza,
all’informazione è concessa la possibilità di spostarsi per essere riutilizzata, in
modo da formare una vera rete di siti in grado di interagire ed elaborare le
informazioni collettivamente.
L’intera rete si sta trasformando e inevitabilmente sta subendo gli effetti
dell’introduzione del Web 2.0. Google Maps, Wikipedia, la pubblicazione di feed (ad
9
Università degli studi di Ferrara
esempio gli RSS), la creazione di blog, sono solo alcuni esempi di come si stiano
sviluppando applicazioni collaborative all’interno di Internet.
Proprio gli RSS sono stati tra le prime tecnologie a fondarsi sul Web 2.0. Essi infatti
permettono agli utenti di ottenere aggiornamenti automatici non appena un sito
cambia, anziché controllarlo ogni volta per avere le ultime informazioni. Tramite gli
RSS, il Web 2.0 viene ampiamente usato per ricercare, filtrare e miscelare le
notizie, gli articoli e altri tipi di contenuto in nuovi oggetti di informazione.
Un altro esempio di come tale tecnologia possa trovare un’applicazione concreta
risiede nell’utilizzo delle open API. Queste, infatti, consentono un accesso ad ampi
database informativi proprietari che possono essere utilizzati per creare nuovi mix e
combinazioni che altrimenti non sarebbero possibili. Amazon, Google, Yahoo,
eBay, Skype, e molte altre società del Web (persino Microsoft si sta muovendo in
questa direzione) hanno tutte open API che permettono agli sviluppatori di
inventare e creare nuove applicazioni che migliorano i dati e le informazioni
preesistenti.
Ma le potenzialità di questo nuovo approccio non si limitano semplicemente alla
possibilità di sviluppare applicazioni che mettano in gioco diversi attori. Basti
pensare a AJAX e a tutte le novità che questa nuova tecnologia ha introdotto.
Tramite i siti potenziati con questa tecnologia, gli utenti possono interagire con le
informazioni nelle singole pagine come se stessero usando un'applicazione,
abbandonando la vecchia metafora del Web come percorso di navigazione
sequenziale in mezzo a pagine statiche.
AJAX (acronimo di Asynchronous JavaScript And XML) è un approccio di sviluppo
Web basato su linguaggi JavaScript e XML. Questa miscela di tecnologie permette
alle pagine di funzionare più come applicazioni per il desktop che come pagine di
contenuto statico antiquate che si trovano di solito sul Web.
Il vantaggio principale di AJAX rispetto alle altre tecnologie sta nel fatto che risulta
possibile avere una pagina con più contenuti dinamici che si modificano
contemporaneamente in seguito all'azione di un utente. Questo consente
10
Università degli studi di Ferrara
innanzitutto di migliorare la User-Experience e rendere la Web UI il più simile
possibile all'interfaccia grafica che abbiamo normalmente sui nostri computer, sui
desktop dei nostri sistemi e quindi abbassare moltissimo le differenze dal punto di
vista percettivo che si hanno tra un'interfaccia Web tipicamente percepita come
poco interattiva, come può essere quella di Windows o di Linux, che risultano
essere sicuramente molto più personalizzabili.
Il vantaggio più immediato nell'adozione di AJAX è sicuramente quello di colmare il
gap con interfacce grafiche più efficaci come quelle realizzate con FLASH e ad un
costo concettualmente prossimo allo zero. In realtà AJAX ha una valenza anche
sulle comunicazione e sul carico generale dell'applicativo Web; quanto espresso
risulta evidente se si considerano i due aspetti fondamentali di questa tecnologia,
fondata su un meccanismo asincrono di request/response e sulla capacità di
manipolazione dell'eventuale documento XML di risposta. I vantaggi del primo
punto risultano evidenti se si pensa al fatto che generalmente, sui siti Web ogni
interazione dell'utente implica un re-load della pagina. Inoltre non è possibile un
caricamento selettivo della vista di un determinato widget. Con AJAX questo
problema viene risolto e questo implica minor materiale spostato su rete, minori
tempi di attesa per l'utente e conseguente maggiore scalabilità dell’applicativo.
Inoltre un meccanismo asincrono si avvicina maggiormente al concetto di servizio e
alla necessità di un basso accoppiamento tra Client e Server. Il secondo punto è
conseguenza della natura stessa dell'oggetto XmlHttpRequest. Questo elemento
converte l'eventuale risposta proveniente dal server in un oggetto manipolabile in
locale, con un'operatività del tutto simile a quanto fatto sul DOM di una pagina
HTML. Questo discorso apre la strada all'adozione di linguaggi XML personalizzati
per le risposte verso il Client e la possibilità, sempre lato Client, di alterare gli
elementi renderizzati fornendo un feedback immediato all'Utente.
Il progetto desktop@UniFe si inserisce in tutta la panoramica descritta sopra,
trovando la sua collocazione nell’esigenza di creare uno strumento utilizzabile in
ambito accademico per la gestione e l’utilizzo dei servizi con un unico applicativo.
11
Università degli studi di Ferrara
La progettazione e la realizzazione di un desktop Web fondato sulla tecnologia
AJAX e sulla filosofia del Web 2.0 è il risultato della necessità di sfruttare appieno le
potenzialità di questi due strumenti.
L’Università di Ferrara mette a disposizione molteplici servizi ai propri utenti: posta
elettronica, liste d’iscrizione agli esami, news di Ateneo, spazio disco virtuale,
segreteria virtuale di gestione dei piani di studi.
Scopo finale del progetto è quello di permettere a ciascun utente di personalizzare i
contenuti del proprio desktop Web, aggregando su uno spazio virtuale tutti i servizi
forniti dall’Ateneo ed eventualmente aggiungendo altri servizi, come ad esempio un
editor di testo, l’aggregazione di feed provenienti da diversi siti o la gestione di
propri bookmark Web, da provider esterni.
Si vuole consentire l’utilizzo di un ambiente desktop, graficamente molto simile a
quello dei comuni sistemi operativi locali. Questo per consentire la miglior
comprensibilità e utilizzabilità dell’applicativo realizzato. Supponendo, infatti il Web
desktop con le caratteristiche fondamentali di un SO, con una barra degli strumenti
per la gestione dei vari servizi forniti e la possibilità di inserire icone sulla scrivania
virtuale, si è pensato di semplificare al massimo la struttura grafica, minimizzando
così anche i tempi necessari per rendere lo strumento utilizzabile appieno
dall’utente.
Lo studio e la progettazione di desktop@UniFe ha consentito di inquadrare alcune
priorità imprescindibili:
•
Necessità di rendere l’applicativo scalabile, con conseguente possibilità
futura di ampliare l’applicativo;
•
Raggiungibilità del servizio da qualsiasi punto del Web;
•
Compatibilità dell’applicativo con i tre maggiori browser in circolazione
(IE, Mozilla e Safari);
•
Aggregazione e integrazione dei servizi, fornendo un’interfaccia comune;
•
Utilizzo di contenuti e informazioni esterne, derivanti da servizi già
presenti all’interno dell’Università di Ferrara o da fonti esterne all’Ateneo;
12
Università degli studi di Ferrara
•
Concedere all’utente la possibilità e la libertà di configurare il proprio
desktop, sia nei contenuti che nella disposizione grafica degli elementi;
•
Garantire una fruibilità buona in termini di velocità di risposta;
•
Semplicità di comprensione del funzionamento del servizio.
L’orientamento Web 2.0 di questo progetto ha portato all’incapsulamento di
funzionalità create precedentemente da altre tesi, ampliando in particolare il
progetto desktop@UniFe con nuove funzionalità non previste inizialmente nel
prototipo sviluppato in precedenza.
Scopo di questa tesi è di creare un’applicazione utilizzabile da utenti dell’università
per comporre i servizi esposti lato server. Inoltre risulta determinante la scelta degli
strumenti utilizzati, che consentono una semplice estendibilità futura del progetto.
Non ultimo, si è scelto di prestare particolare attenzione a tutta la parte di
sicurezza, garantendo una buona separazione tra i dati personali degli utenti, i
codici dell’applicativo e i contenuti pubblicati. Tutto questo, gestendo anche la
comunicazione dei dati sensibili tra client e server attraverso protocolli di sicurezza.
Infine di particolare rilevanza è la possibilità di usufruire del servizio fornito da
desktop@UniFe attraverso piattaforme differenti, superando così problemi di
eterogeneità sia hardware che software e garantendo una fruibilità a browser
diversi.
13
Università degli studi di Ferrara
14
Università degli studi di Ferrara
Capitolo 1: IL WEB, VERSIONE 2.0
1.1 Storia del Web
L’inizio della storia del Web è da ricondursi al marzo 1991 quando l'inglese Tim
Berners Lee, un ricercatore del Cern di Ginevra, rilasciò la prima pagina con gli
ipertesti. Il 'progetto W3', diretto dallo stesso Lee, aveva l'obiettivo di sviluppare un
sistema
di
pubblicazione
e
reperimento
dell'informazione
per
documenti
multimediali, distribuito su rete geografica.
Dal punto di vista funzionale il Web aveva l’obiettivo di creare uno strumento in
grado di muoversi facilmente nella rete alla ricerca di informazioni, documenti e
dati, e d'altro canto consentisse la diffusione telematica di documenti elettronici
multimediali, attraverso il canale di distribuzione più vasto e ramificato del mondo:
Internet. Se al Cern si definivano dal 1989 i vari standard su cui si basa oggi il Web
(gli indirizzi URL e il linguaggio HTML), grande impulso al World Wide Web venne
dagli Stani Uniti. La prima pagina Web americana era formata da tre linee di testo e
due link, uno per l'e-mail e l'altro diretto al database dell'università di Stanford. Da
sottolineare che allora non era chiaro quale fra le varie possibilità offerte da Internet
avrebbe prevalso. Il Web, per esempio, aveva come rivale la rete Gopher
dell'università dell'Illinois, il cui declino coincise con la decisione di rendere a
pagamento l'uso di tale protocollo.
Dunque il World Wide Web, l'ipertesto globale costruito sulla base di Internet, deve
la sua nascita a un ricercatore che progettò il Web per uno scopo puramente
sociale, tanto da dichiarare: "Il Web è una creazione più sociale che tecnica. L'ho
progettato per aiutare la gente a lavorare insieme - e non come un giocattolo
tecnico". Fu lui e la sua organizzazione (il 3WConsortium) a difendere il Web
dall'assorbimento commerciale e fu la comunità scientifica a partecipare
liberamente per far crescere il progetto. Grande impulso alla diffusione del Web
venne dalla creazione del primo browser grafico user-friendly per pc. Da quel
15
Università degli studi di Ferrara
codice open-source (Mosaic) derivò direttamente Netscape Navigator, mentre dalla
sua rielaborazione nacque Internet Explorer.
1.2 Caratteristiche del Web
Il Web, o "ragnatela mondiale" (è questo il significato della tripla w) mira al
superamento delle barriere geografiche che impediscono la collaborazione fra
gruppi scientifici fisicamente distanti, ma anche ad accelerare lo scambio di
informazioni grazie a protocolli standardizzati.
Figura 1.1: Architettura Client-Server
L'architettura del Web è di tipo client - server. Questa è caratterizzata da un'entità
che offre il servizio (server) e un'altra (client) che vi accede e ne usufruisce
16
Università degli studi di Ferrara
secondo una serie di regole specifiche (si veda la Figura 1.1). Il programma client
funziona da interfaccia fra utente finale e server Web, gestendone l'interazione;
esso si collega al server tramite il protocollo http per richiedere un documento
identificato dal proprio url, scarica sulla propria macchina i dati che ha prelevato,
legge da un buffer i dati scaricati dal server interpretando i tag html che
determinano lo stile di visualizzazione sulla pagina Web ed infine visualizza i widget
grafici costruiti in precedenza, grazie all'aiuto delle librerie grafiche.
Il programma server, invece, riceve le richieste di connessione in rete e distribuisce
i
documenti
richiesti
da
qualche
utente,
tramite
un
programma
client.
Il programma www può essere eseguito su diverse piattaforme ma per sfruttare
totalmente le caratteristiche peculiari di tale sistema si deve possedere una
macchina con capacità grafiche e audio oltre ad una connessione ad Internet
abbastanza veloce, che consenta il trasferimento di immagini, animazioni e suoni in
tempi accettabili.
L’architettura www consente
di
astrarre
dalla struttura fisica della rete
presentandola con una struttura più pratica, trasformandola cioè in un ipermedia,
cioè in un insieme di notizie collegate tra loro nella rete non solo in forma di
documenti testuali ma anche di testi, immagini, suoni, video. I dati per poter essere
immessi in rete devono essere tradotti in un unico formato denominato html
(HyperText Markup Language), standard di lettura per i Client browser.
1.3 I limiti del Web 1.0
Da subito il Web evidenziò tre caratteristiche fondamentali che ne determinarono lo
sviluppo smisurato nel mondo della telematica:
•
l’estrema facilità di utilizzazione delle interfacce;
•
la sua organizzazione ipertestuale;
•
la possibilità di trasmettere informazioni multimediali
17
Università degli studi di Ferrara
Nonostante questi tre punti, da subito ci si accorse che chiunque avesse voluto
sviluppare applicazioni Web, avrebbe dovuto affrontare due problemi fondamentali:
la mancanza di stato delle connessioni http e l’impossibilità di comunicare con il
server tra una visualizzazione di pagina e l’altra.
Col tempo il primo problema è stato risolto con l’introduzione dei cookie per
l’identificazione degli utenti e con la registrazione delle sessioni sui server. Il
secondo ordine di problemi si è rivelato molto più difficile da affrontare e in
particolar modo da risolvere. I tag <frameset> e <frame> hanno sempre
rappresentato una soluzione parziale, i cui aspetti negativi, spesso creavano
maggiori problemi nella gestione degli oggetti sull’ipertesto che benefici.
In questo modo il divario tra applicazioni sviluppate per ambienti locali come ad
esempio desktop, dominati da interfacce utente OpenGL, e applicativi Web si è
fatto via via sempre più ampio.
1.4 Il Web 2.0
Con il nome Web 2.0 si intende un generico stato di evoluzione di Internet e in
particolare del World Wide Web. In sostanza il Web 2.0 è identificabile in una serie
di siti Web con interfaccia, una facilità e una velocità d'uso tali da renderli simili alle
applicazioni tradizionali che gli utenti sono abituati a installare nei propri computer.
Web 2.0 è un termine coniato dalla casa editrice O’Reilly, specializzata in
pubblicazioni riguardanti le nuove tecnologie. Il concetto di Web 2.0 pone l’accento
sulle capacità di condivisione dei dati tra le diverse piattaforme tecnologiche, sia
hardware che software.
Il filo conduttore è una nuova filosofia all'insegna della collaborazione. I servizi e gli
strumenti del Web 2.0 trasformano ogni utente da consumatore a partecipante, da
utilizzatore passivo ad autore attivo di contenuti, messi a disposizione da chiunque
si affacci a Internet, indipendentemente dal dispositivo che utilizza.
18
Università degli studi di Ferrara
In particolar modo, l’approccio del Web 2.0 si prefigge il compito di ripensare alle
modalità con le quali progettare l'informazione(si veda la Figura 1.2):
•
Il contenuto è completamente svincolato dalla sua rappresentazione;
•
L'informazione è aggregata e riassemblata secondo i bisogni degli utenti ed
è fruibile su diverse piattaforme di distribuzione;
•
La comunicazione è sempre più flessibile e adattata ai contesti ed ai
comportamenti di fruizione;
•
Utilizzazione di nuove modalità di ricombinazione di vecchi contenuti che
rendono obsoleti i tradizionali concetti di protezione dei diritti;
•
Riprogettazione dei metadati con la stessa cura con cui vengono costruiti i
contenuti.
Figura 1.2: Architettura del Web 2.0
19
Università degli studi di Ferrara
1.5 Confronto fra Web 1.0 e Web 2.0
Per comprendere appieno la novità del Web 2.0 spesso conviene procedere
effettuando un confronto con il Web 1.0, indicando come nel passaggio di versione
gli elementi fondamentali si siano evoluti o siano 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.
Senza entrare nel merito attraverso un'ampia dissertazione, si possono valutare
alcune differenze tra Web 1.0 e Web 2.0 analizzando la tabella comparativa
pubblicata sul Blog NevOn che evidenzia le differenze tra Web 1.0 e Web 2.0 in
termini di servizi offerti e di concetti sviluppati.
Figura 1.3: Comparazione tra Web 1.0 e Web 2.0
Come mostrato in Figura 1.3 si può perciò capire come alcuni concetti fondamentali
del Web 1.0 siano stati completamente rivoluzionati:
20
Università degli studi di Ferrara
•
Da Client/server a SOA: L'architettura si sposta verso un modello orientato ai
servizi con comunicazioni basate su protocolli aperti e standard, facili da
comporre;
•
Da unidirezionale a bidirezionale: Evoluzione da siti intesi come contenitori di
informazioni in sola lettura verso servizi interattivi e cooperativi (Wikipedia,
blog, flikr, del.icio.us etc);
•
Da Directory a Folksonomy: La categorizzazione delle informazioni si sposta
da un modello tassonomico, ovvero alla classificazione gerarchica e statica
dei dati, verso un modello collaborativo. Ciò che cambia in maniera definitiva
è il modello di conoscenza e di reperimento delle informazioni, indicizzate su
modelli basati sul tagging. Un Web basato sulla folksonomy sarebbe
soggetto all’interpretazione degli utenti e consentirebbe una indicizzazione
sia verticale (attraverso la tassonomia), che orizzontale (attraverso la
folksonomia)
•
Da stickiness a syndication: Le tecniche utilizzate fino a ieri per tenere più
tempo possibile i visitatori su un sito Web (stickiness significa 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.
Nonostante l’esempio, il dibattito sulle differenze tra Web 1.0 e Web 2.0 è ancora
aperto, a tal punto che risulta piuttosto difficile trovare un parere comune su questi
due approcci. Infatti se si analizza il Web 2.0 secondo la visione proposta da Tim
Berners Lee, si mette in discussione l’esistenza stessa di questo nuovo approccio
al Web. Egli infatti fa notare che l'idea di read/write Web stava già alla base
dell'idea originale del Web. Dunque il "Web 2.0" non è altro che il Web 1.0 che ha
raggiunto la sua maturità. Ovviamente di posizione opposta è O'Reilly, detentrice
del trademark Web 2.0, che continua a espandere le motivazioni su cos'è il Web
2.0 insistendo anche su punti come il read/wr e su concetti base quali:
•
Servizi e non software pacchettizzati
21
Università degli studi di Ferrara
•
Web come piattaforma per lo sviluppo e la distribuzione dei servizi
•
Architettura orientata ai servizi
•
Architettura per favorire la partecipazione ed elevata interattività
•
Ridistribuzione dei contenuti
•
Social networking
1.6 Le Tecnologie
Proprio per la sua natura, il Web 2.0 deve essere considerato come una
aggregazione di tecnologie in costante e continua evoluzione. In particolar modo le
principali sono:
•
XML o eXtensible Markup Language: è un insieme di regole che
identificano come sia possibile definire dei tag che separano un
documento in singole parti e sottoparti. E’ un linguaggio di Markup come
Html, ma è stato definito in modo da non essere limitato a un particolare
vocabolario o utilizzo.
•
JAVASCRIPT: è un linguaggio di scripting che dispone di funzionalità
orientate agli oggetti e viene direttamente incorporato nelle pagine
HTML. A differenza di molti altri linguaggi di scripting come PHP, RUBY,
ASP o JSP che vengono eseguiti sul server, Javascript è eseguito dal
browser a livello locale.
•
API (acronimo di Application Program(ming) Interface), indica un
insieme di procedure disponibili al programmatore, di solito raggruppate
a formare un set di strumenti specifici per un determinato compito. È un
metodo per ottenere un'astrazione, di solito tra l'hardware e il
programmatore, o tra software a basso ed alto livello. Le API permettono
di evitare ai programmatori di scrivere tutte le funzioni dal nulla. Esse
stesse sono un'astrazione. Infatti, attraverso dei software predisposti,
forniscono dei servizi utilizzabili su qualsiasi applicativo.
22
Università degli studi di Ferrara
•
WEB SERVICE. Un servizio Web è un'interfaccia che descrive una
collezione di operazioni, accessibili attraverso una rete mediante
messaggi in formato XML. Tali operazioni possono essere viste come
delle funzioni messe a disposizione da una libreria condivisa, o dalle
classi di un package Java. Una delle caratteristiche più interessanti dei
Web services è la possibilità di utilizzarli per comunicazioni e scambi di
informazioni automatici: perciò senza interazione tra persona e
applicazione (come avviene nella navigazione sul Web) bensì
interazione tra applicazioni. La descrizione formale e standardizzata dei
servizi Web, infatti, consente la ricerca e l'utilizzo dei Web services
senza richiedere necessariamente l'intervento umano.
•
RSS: acronimo di RDF Site Summary ed anche di Really Simple
Syndication è uno dei più popolari formati per la distribuzione di
contenuti Web; è basato su XML, da cui ha ereditato la semplicità,
l'estensibilità e la flessibilità. RSS definisce una struttura adatta a
contenere un insieme di notizie, ciascuna delle quali sarà composta da
vari campi (nome autore, titolo, testo, riassunto). Quando si pubblicano
delle notizie in formato RSS, la struttura viene aggiornata con i nuovi
dati; visto che il formato è predefinito, un qualunque lettore RSS potrà
presentare in una maniera omogenea notizie provenienti dalle fonti più
diverse.
Molte di queste tecnologie concorrono nella definizione di un nuovo approccio al
Web, basato su una gestione della comunicazione tra client e server asincrona e
indipendente dalla pagina visualizzata:
•
AJAX: Asynchronous Javascript And XML. E’ un acronimo che sta per
Asynchronous Javascript And Xml. In altre parole, AJAX è un pattern
che sfrutta le tecnologie attualmente esistenti sul Web (HTML,
Javascript, CSS, XMLHttpRequest, ecc.) per effettuare richieste al
server, in modalità asincrona (vedi Figura 1.4), senza effettuare il
postback completo dell'intera pagina. Il cuore sta nell'oggetto
23
Università degli studi di Ferrara
XMLHttpRequest che viene utilizzato dal javascript per invocare le
operazioni sul server e ricevere la relativa risposta.
Figura 1.4: Comunicazione tra Client e Server con Ajax
E’ un oggetto implementato per la prima volta in Internet Explorer di
Microsoft e in seguito adottato da tutti i principali browser Web, sia quelli
basati sul motore Gecko (come Firefox e Mozilla), sia altri, quali Opera e
Safari. Questo oggetto permette di costruire chiamate http dal client al
server e, inoltre, di aver accesso ed elaborare i dati inviati dal server in
risposta alla richiesta. Pur non essendo uno standard tutti i vendor
hanno utilizzato la stessa interfaccia al fine di semplificarne l'uso; l'unica
differenza tra la varie implementazioni sta nel fatto che IE non ha nel
proprio DOM un oggetto XmlHttpRequest, ma utilizza un ActiveX esterno
(con conseguente problema di sicurezza), mentre gli altri browser lo
hanno integrato.
24
Università degli studi di Ferrara
1.7 Esempi di applicazioni in Web 2.0
Il Web 2.0 rende possibili applicazioni innovative, fondate principalmente sul
concetto di condivisione e di rielaborazione, fra cui:
•
Blog
•
Wiki
•
Social network
•
Podcasting
•
Vodcasting
•
Desktop Web
Tutte permettono la partecipazione nonché la diffusione di ciò che viene prodotto
all’interno delle comunità interattive di fruitori/autori di contenuti.
Le materie e gli argomenti trattati spaziano lungo tutti i campi del sapere, rendendo
ogni informazione immediatamente visibile e rielaborabile per qualsiasi media. Può
capitare che un articolo apparso su un quotidiano online sia commentato su un
blog, per poi essere arricchito dall’aggiunta di contenuti audio e video, essere
condiviso all’interno di una comunità, diventando a ogni passaggio sempre più
approfondito e "popolare" (si veda Figura 1.5).
Il fiore all'occhiello del Web 2.0 è senza dubbio il blog, vero e proprio luogo di
incontro, discussione e condivisione di argomenti e contenuti, disponibili come
testo, immagini, audio e video. L’elemento più innovativo di questo strumento/sito è
la tecnologia grazie alla quale i contenuti dei feed sono fruibili tramite appositi
software che interpretano i file in linguaggio XML, rendendo visibili le informazioni
ivi contenute senza bisogno di navigare il blog o il sito che li ha prodotti. E' anche
possibile aggregare più feed, filtrandoli e rielaborandoli, per presentarli su un altro
sito Web o su un servizio di news navigabile tramite il cellulare.
La diffusione dell’informazione avviene anche tramite i podcast (file audio) e i
vodcast (file video), leggibili da programmi dedicati allo stesso modo dei feed RSS.
25
Università degli studi di Ferrara
Figura 1.5: Servizi offerti tramite approccio Web 2.0
Scorrendo l'elenco delle soluzioni Web 2.0, i wiki risultano essere l’espressione più
democratica della diffusione della conoscenza attraverso la tecnologia. La logica
che muove e sviluppa i wiki è la partecipazione degli utenti a un obiettivo comune,
come la realizzazione della più grande enciclopedia mondiale, "Wikipedia", o la
creazione di un glossario informatico, o di una knowledge base dedicata a un
argomento specifico. Il metodo di lavoro è in questo caso l’elemento innovatore;
chiunque può aggiungere o modificare il contenuto (testo, immagini e video)
presente in un wiki. Ecco perché si può affermare che la partecipazione libera del
singolo produce un bene culturale comune, fruibile da tutti gratuitamente.
Tra gli applicativi principali sviluppati attraverso un approccio Web 2.0 vi sono i
social network, o reti sociali, che consistono in gruppi di persone, con vincoli
familiari e non, con passioni e interessi comuni, intenzionati a condividere pensieri
e conoscenze. Si trovano online comunità di persone che condividono i link ai siti
26
Università degli studi di Ferrara
che ritengono interessanti, oppure alle proprie foto o video, come anche poesie, o
anche resoconti di eventi cui hanno partecipato. Persone che hanno la capacità e la
voglia di distribuire contenuti multimediali relativi ai propri interessi. Questi gruppi si
rivelano spesso una preziosa fonte di informazioni e al contempo divulgatori
specializzati in argomenti di nicchia.
Il feed RSS accomuna tutte le applicazioni sopra citate, perché permette di
diffonderne il contenuto con una modalità semplice e immediata. Questa capacita
divulgativa può essere applicata a qualsiasi sito voglia informare i propri utenti sulle
novità, come avviene per i quotidiani online che diffondono le proprie news, o per i
grandi motori di ricerca che informano sui nuovi servizi attivi o in corso d'opera.
Il cuore del Web 2.0 è il contenuto, fruibile in tutte le sue applicazioni multimediali,
prodotto
dall’interazione
delle
persone
tramite
piattaforme
ad
hoc.
Le applicazioni sono le più disparate, da quelle a scopo commerciale come
Amazon a quelle votate alla libera circolazione del pensiero.
Tra le principali ci sono i Web desktop, che rendono possibile la creazione di siti
Web che siano in tutto e per tutto simili a un comune desktop. Il vantaggio è quello
che viene offerta la possibilità di organizzare i propri contenuti, mettendoli a
disposizione di tutti, con un sistema aperto. Questo non ha l'ostacolo di essere
vincolato a una particolare piattaforma o architettura. Il sistema grafico inoltre rende
disponibili questi contenuti come se fossero sul proprio desktop. L'utilizzo di questa
soluzione può trovare largo uso nella creazione di "ambienti grafici virtuali" dove
l'utente può muoversi con buona libertà. Inoltre risiedendo su un server può
facilitare tantissimo la connettività degli utenti che in tal modo possono accedere ai
propri dati da un qualsiasi punto geografico, non dovendo installare niente in locale
ma avendo tutta la logica applicativa in remoto.
Un esempio di come il Web 2.0 si sia sviluppato all’interno del mondo Web con
notevole successo è dato da due servizi come del.icio.us e Wikipedia.
27
Università degli studi di Ferrara
1.7.1 Esempio 1: del.icio.us
Del.icio.us rappresenta un «social bookmarking». Il termine inglese bookmark vuol
dire segnalibro, ma nel Web è usato per indicare l'attività di marcare una pagina
Web, creando un proprio elenco di siti preferiti o comunque da ricordare.
Figura 1.6: Esempio di del.icio.us
Questa operazione di solito fatta sul proprio computer, è stata portata su Web con
notevole successo da del.icio.us, che propone di farla in pubblico, socialmente
mettendo a disposizione di altri (tutti o gruppi di amici) gli indirizzi Web ritenuti
interessanti. Attraverso del.icio.us viene dato grande impulso al nuovo concetto di
folksonomy.
Il meccanismo di funzionamento di del.icio.us si basa sull’associazione di una
etichetta (tag) a ciascun link, di modo che le informazioni possano essere più
facilmente trovate attraverso una ricerca per categorie. Si tratta di un'operazione
analoga a quella dei motori di ricerca, ma realizzata da persone anziché da
28
Università degli studi di Ferrara
software automatici. I risultati sono meno numerosi che su servizi come Google, ma
potenzialmente possono risultare più interessanti perché alla base di ogni link
messo in pubblico c'è la valutazione di un umano intelligente che ha esaminato
quelle pagine.
1.7.2 Esempio 2: Wikipedia
Wikipedia nacque il 15 gennaio 2001 come progetto complementare di Nupedia (un
progetto con scopo analogo ma la cui redazione era affidata ad esperti)
Wikipedia è una enciclopedia on-line. La sua caratteristica fondamentale è quella di
essere totalmente libera. Per raggiungere questo scopo, l'idea di base è quella per
cui chiunque può partecipare, modificare e cancellare i contenuti previsti o in essa
contenuti. La motivazione è quella di condividere il sapere di ciascuno,
indipendentemente dalla sua professione. Una rete ipertestuale praticamente
infinita, con la possibilità di avere a disposizione una navigazione a rete,
impossibile da trovare in approcci legati al Web 1.0.
Figura 1.7: Inserimento di una nuova voce nell’enciclopedia da parte di un utente
29
Università degli studi di Ferrara
E’ multimediale e multilingue e risulta essere la concreta realizzazione del concetto
di rete, inteso in senso assoluto. Attualmente è pubblicata in oltre 200 lingue
differenti e contiene voci sia sugli argomenti propri di una tradizionale enciclopedia
che su quelli di almanacchi, dizionari geografici e di attualità.
Wikipedia contiene in totale più di 5,3 milioni di voci, 15,3 milioni di pagine, 175,4
milioni di modifiche alle pagine (con una media di quasi 35 modifiche per pagina) e
4 milioni di utenti registrati.
I volontari di Wikipedia sostengono la politica del "punto di vista neutrale" secondo
la quale le opinioni presentate da personaggi importanti o da opere letterarie
vengono riassunte senza tentare di determinarne una verità oggettiva. A causa
della sua natura aperta, vandalismi e imprecisioni sono problemi riscontrabili in
Wikipedia.
30
Università degli studi di Ferrara
Capitolo 2: TECNOLOGIE e STRUMENTI
L'esigenza di sfruttare la grande diffusione di Internet e la relativa semplicità di
sviluppo, hanno portato alla proliferazione di software basati sul Web.
Le conseguenze di questi sforzi sono state quelle di accrescere in maniera
smisurata la nascita e la successiva espansione di nuove tecnologie, rendendo il
Web un punto di incontro tra filosofie di programmazione e linguaggi totalmente
diversi tra loro.
Inoltre, la necessità di spostare sulla rete la maggior parte degli strumenti utilizzabili
solo in ambienti locali, ha spinto nella ricerca di nuovi approcci, che rendessero più
flessibile e accessibile il mondo del Web. La conseguenza di questo è che ogni
strumento offerto da applicazioni desktop è ormai fruibile utilizzando un browser:
dai programmi gestionali per aziende all’utilizzo di account di mail, dai videogiochi
alle enciclopedie, oramai tutto si trova "anche su Internet".
Se dal punto di vista funzionale la transizione dal desktop al Web è avvenuta con
successo, questo non si può dire per la fruibilità delle funzioni: l'esperienza
dell'utente è profondamente diversa, ricca e interattiva sul desktop, povera e lenta
sul Web. Oggi la maturazione delle tecnologie di base del Web permette di colmare
la distanza che separa il desktop dal Web: un'applicazione residente su Internet
può essere virtualmente indistinguibile dalla controparte sviluppata per il desktop.
Per fare questo, però è necessario appoggiarsi su una nuova filosofia: spostare la
maggior parte del controllo e della parte applicativa del servizio dal server al client.
Questo è possibile solamente attraverso l’uso di AJAX, acronimo di "Asynchronous
JavaScript And XML", per le interazioni client server e la gestione delle azioni
dell’utente, un linguaggio come Ruby per l’interpretazione delle richieste provenienti
dai browser e SQL per le interrogazioni al database e il reperimento delle
informazioni in esso contenute.
31
Università degli studi di Ferrara
2.1 Asynchronous Javascript And XML : AJAX
Come già detto più volte AJAX è un approccio allo sviluppo di applicazioni Web,
basato sulla sinergia tra tecnologie preesistenti.
Il termine Ajax fu coniato da Adaptive Path per indicare su quali di esse si sarebbe
dovuto fondare un nuovo modo di comunicare tra client e server. La specificità di
tale tecnologia sta nella capacità di scambiare informazioni tra applicazioni remote
in modo totalmente asincrono e nascosto all’utente (vedi Figura 2.1).
Figura 2.1: Comunicazione Asincrona di Ajax
32
Università degli studi di Ferrara
Infatti mentre nelle applicazioni tradizionali il browser è utilizzabile soltanto quando
non sono in corso trasmissioni di richieste pagine (linee “data trasmission”) o
quando il server non sta lavorando (linee “system processing”) , in Ajax le richieste
al server non coinvolgono direttamente il browser, che può continuare a rispondere
ai comandi dell’utente e aggiornare (attraverso Ajax engine e su comando del
motore JavaScript) solo le parti della pagina che ne hanno effettivamente bisogno.
Ajax è una tecnica che estende il modello di applicazione Web tradizionale,
consentendo di inviare le richieste ai server all’interno di singole sezioni di pagina.
Questa filosofia permette di creare pagine Web che agiscono come vere e proprie
applicazioni per desktop. Tale meccanismo funziona basandosi sui protocolli di
comunicazione già presenti nel modello client-server del Web 1.0.
Al caricamento di un'applicazione AJAX (una "semplice" pagina html, in
apparenza), viene caricato ed eseguito un programma JavaScript che si interpone
tra l'utente e il browser: il programma "intercetta" le azioni dell'utente e sulla base di
queste guida il browser nelle azioni che gli competono (in particolar modo
trasformazione di oggetti DOM in rappresentazioni grafiche e gestione del
protocollo HTTP).
In sintesi, un'applicazione Ajax segue ancora il vecchio paradigma client/server:
l'innovazione sta nel fatto che tutte le comunicazioni avvengono in background. Il
modello Ajax prevede la sostituzione di tutte le azioni che normalmente
scatenerebbero una richiesta Http al server con chiamate JavaScript al motore. È
quest'ultimo a decidere se e come contattare il Web server. Se il motore è in grado
di rispondere da solo all'utente lo farà immediatamente, e il browser potrà
aggiornare subito la parte corrispondente della pagina.
In tutti i casi in cui servono nuovi dati dal server, da stringhe di testo al risultato di
un'operazione o a nuovi file grafici per aggiornare una mappa, questi, grazie
all'oggetto XMLHttpRequest, verranno richiesti dal motore JavaScript senza
bloccare il browser, anche per un solo campo alla volta. Qualsiasi elemento di una
pagina Web può essere tenuto sotto controllo e aggiornato in questo modo: ogni
33
Università degli studi di Ferrara
componente
Dom
raggiungibile
via
JavaScript
con
il
metodo
document.getElementByldO è accessibile ad un'applicazione Ajax.
I Componenti AJAX (si veda Figura 2.2) per la gestione delle informazioni sul Web
vengono suddivisi in base allo scopo per il quale sono utilizzati e in funzione della
parte di tecnologia Ajax che implementano:
•
PROTOCOLLO HTTP per il trasporto dei dati. HTTP (HyperText
Transfer Protocol) è la base del World Wide Web. La caratteristica
fondamentale che ne ha determinato un grande sviluppo ma che ha
limitato molto lo sviluppo di applicazioni Web simil-desktop è
l’impossibilità di connessioni con stato, ovvero per ogni richiesta è
necessario aprire una nuova connessione.
•
XHTML e CSS per la presentazione delle pagine. Questi due
linguaggi, insieme, descrivono con precisione l'aspetto che una pagina
deve avere.
•
DOM (Document Object Model) per consentire dinamismo e
interazione alla pagina. Una pagina XHTML interpretata dal browser, si
trasforma al suo interno in un oggetto DOM, una rappresentazione
astratta del documento stesso. E' possibile intervenire su ogni aspetto
di un oggetto DOM: ogni modifica si riflette in tempo reale sul modo in
cui il browser "disegna" la pagina.
•
XML per lo scambio e la manipolazione dei dati. E’ il principale
standard per lo scambio dei dati.
•
XMLHttpRequest. Consente il trasporto asincrono dei dati. Il client
può inviare una richiesta al server e venire "avvertito" quando la
risposta è pronta. Tramite questa funzionalità è possibile per un
programma
prendere
pieno
controllo
sul
protocollo
HTTP
implementato dal browser.
•
JAVASCRIPT. E’ un linguaggio comune per gestire tutti gli eventi
locali “scatenati” dall’utente. JavaScript permette di modificare gli
oggetti
DOM,
di
elaborare
documenti
XML
e
comunicazione client-server tramite XMLHttpRequest.
34
di
gestire
la
Università degli studi di Ferrara
Da notare che a parte l’oggetto XMLHttpRequest, in Ajax non c’è alcuna tecnologia
nuova; infatti anche le applicazioni client-server Html tradizionali, sono sviluppate
su tali tecnologie e, al pari di quelle Ajax, non richiedono il download di alcun
software. D’altra parte, se per un utente finale l’unica vera differenza è l’accesso via
browser ad applicazioni veloci quanto quelle desktop, per quanto riguarda lo
sviluppo, significa concepire applicazioni event-driven con ambienti di sviluppo e
linguaggi finora utilizzati in altra maniera. Per ulteriori approfondimenti si veda
“http://en.wikipedia.org/wiki/Ajax_(programming)”.
Figura 2.2: Tecnologie alla base di AJAX
35
Università degli studi di Ferrara
2.1.1 JavaScript
JavaScript è un linguaggio di scripting che dispone di funzionalità orientate agli
oggetti e viene direttamente incorporato nelle pagine HTML. A differenza di molti
altri linguaggi di scripting come PHP, Ruby o Perl che vengono eseguiti sul server,
JavaScript è eseguito dal browser a livello locale.
E' un linguaggio apparentemente molto simile, come struttura e sintassi, ad altri
linguaggi di programmazione come il C e il Java, ma per alcune caratteristiche si
differenzia da essi in maniera considerevole.
JavaScript, infatti è stato pensato e creato per gestire tutti i possibili eventi che si
verificano in locale, consentendo di creare delle strutture di controllo per ogni
azione compiuta dall’utente.
Le differenze con il Java (le Applet) sono molte, a partire dagli scopi per i quali i due
linguaggi sono stati pensati (si veda la Tabella 2.1 ).
Javascript
Java (Applet)
E’ un linguaggio compilato e gestito
E’ un linguaggio interpretato dal client
sul server, per poi essere eseguito sul
client.
E’ un linguaggio basato sulle classi.
E’ orientato agli oggetti. E’ possibile
definire una funzione per ogni evento
scatenato nel browser
Il codice è contenuto all’interno delle
pagine HTML, fra i tag <script> e
</script>
Le variabili e le costanti non sono mai
dichiarate, e vengono assegnate in
maniera dinamica
Gli oggetti e le funzioni sono racchiusi
in esse e vengono usati attraverso
delle chiamate prestabilite. Non è un
linguaggio basato sugli eventi.
Le Applet sono ben distinte dal codice
HTML.
Ad ogni variabile e ad ogni costante
deve essere assegnato un tipo.
Tabella 2.1: Confronto fra Javascript e Applet Java
36
Università degli studi di Ferrara
JavaScript permette l'inserimento di contenuti eseguibili all'interno di pagine Web,
consentendo così la creazione di pagine HTML dinamiche a livello locale,
attraverso l’interazione con l’utente.
L’utilizzo del JavaScript permette inoltre una miglior progettazione a livello di
performance dell’applicativo in quanto offre la possibilità di ridurre al minimo i flussi
di conversazione tra client e server, implementando il maggior numero di
funzionalità a livello locale.
La gestione degli eventi e della comunicazione con gli oggetti contenuti nel DOM è
stata
perciò
completamente
demandata
a
questo
linguaggio,
in
quanto
conseguenza della capacità di tradurre le “volontà” dell’utente in modifiche
immediate dell’interfaccia della pagina.
Attraverso delle funzioni preesistenti, si riesce inoltre a capire il tipo di browser
utilizzato dall’utente, e quindi ad implementare operazioni differenti per ciascuno di
essi.
JavaScript è una raccomandazione del W3C, che ne pubblica un tutorial
all’indirizzo “http://www.w3schools.com/js/ “.
2.1.2 XML
XML (acronimo di eXtensible Markup Language) è un meta-linguaggio per definire
la struttura di documenti e dati. Concretamente, un documento XML è un file di
testo che contiene una serie di tag, attributi e testo secondo regole sintattiche ben
definite.
Un documento XML è intrinsecamente caratterizzato da una struttura gerarchica.
Esso è composto da componenti denominati elementi, ciascuno dei quali
rappresenta un componente logico del documento e può contenere altri
sottoelementi o del testo. Ad essi possono essere associate altre informazioni che
ne descrivono le proprietà. Queste informazioni sono chiamate attributi.
L'organizzazione degli elementi segue un ordine gerarchico che ne prevede uno
che funge da radice, chiamato root element, e tutti gli altri che ne descrivono le
37
Università degli studi di Ferrara
foglie. Si può rappresentare graficamente la struttura di un documento XML tramite
un albero come quello rappresentato in Figura 2.3, generalmente noto come
document tree.
Figura 2.3: Document tree di un documento XML
Nella figura abbiamo un root element denominato articolo che contiene una lista di
elementi che rappresentano i vari paragrafi dell'articolo. Ciascun paragrafo a sua
volta contiene del testo, degli esempi di codice e delle immagini. La maggior parte
degli elementi di questo document tree possiede degli attributi: titolo, tipo, file.
La struttura logica di un documento XML dipende dalle scelte progettuali. E’ poi
compito dei CSS decidere come organizzare graficamente gli elementi all'interno di
una pagina Web, basandosi sui contenuti all’interno del documento XML.
La definizione di grammatiche per documenti XML è rappresentato dal DTD
(Document Type Definition). Un DTD è un documento che descrive i tag utilizzabili
in un documento XML, la loro reciproca relazione nei confronti della struttura del
documento e altre informazioni sugli attributi di ciascun tag.
38
Università degli studi di Ferrara
La struttura logica di un documento XML viene tradotta in una corrispondente
struttura fisica composta di elementi sintattici chiamati tag. Questa struttura fisica
viene implementata tramite un file di testo creato con un qualsiasi editor. La
rappresentazione fisica di un documento XML può essere come quello
rappresentato in Figura 2.4.
Figura 2.4: Esempio di codiceXML
La prima riga del documento lo identifica come un documento XML e ne specifica la
versione (in questo caso la 1.0). Il corpo vero e proprio del documento segue
questa prima riga, rappresentando gli elementi tramite tag, cioè sequenze di
caratteri delimitate dai segni '<' e '>' proprio come avviene per l'HTML.
A differenza dell'HTML in cui i tag sono predefiniti, XML lascia la libertà di definire i
tag secondo le proprie esigenze. Proprio questa caratteristica rende tale linguaggio
il più idoneo per lo scambio di dati tra un client ed un server, in quanto consente di
incapsulare tutte le informazioni tra tag, visualizzabili in locale in maniera
personalizzata a seconda delle esigenze del client. Una descrizione esauriente di
tale linguaggio è reperibile all’indirizzo “http://www.w3schools.com/xml/”.
39
Università degli studi di Ferrara
2.1.3 L’oggetto XMLHttpRequest: la A di AJAX
Come già detto più volte le chiamate Ajax sono di tipo asincrono, vale a dire non
bloccanti. Per fare questo Ajax utilizza XMLHttpRequest, un oggetto implementato
per la prima volta in Internet Explorer da Microsoft e in seguito adottato da tutti i
principali browser Web, sia quelli basati sul motore Gecko (Firefox e Mozilla), sia
altri, quali Opera e Safari di Apple.
Questo oggetto permette di costruire chiamate http asincrone dal client al server e,
inoltre, di avere accesso ed elaborare i dati inviati dal server in risposta alla
richiesta. Dopo avere inviato la richiesta al server, il ciclo di eventi principale del
browser si prepara per rimanere in ascolto di un evento provocato dall’istanza di
XMLHttpRequest. Le novità fondamentali apportate con l’introduzione di questo
oggetto rispetto all’utilizzo degli <iframe>, che venivano considerati gli unici in
grado di gestire aggiornamenti di parti di una pagina Web, sono riassumibili in
alcuni punti fondamentali. XMLHttpRequest infatti:
•
Semplifica l’esecuzione di GET, POST e altri tipi di richieste HTTP;
•
Non modifica in alcun modo il DOM;
•
Offre Api molto più potenti;
•
Permette di personalizzare gli header HTTP;
•
Consente di aggiornare qualsiasi elemento del DOM.
2.1.4 Il DOM
Il Document Object Model di una pagina Web è una descrizione della sua struttura
interna vista come gerarchia di oggetti JavaScript. Lo standard più completo e
aggiornato è quello del World Wide Web Consortium (W3C).
Come mostrato in Figura 2.5, l’elemento all’origine di ogni gerarchia DOM è la
finestra del browser in cui una pagina è visualizzata. Nel DOM i documenti hanno
una struttura logica che è molto simile ad un albero. Il DOM non specifica come i
40
Università degli studi di Ferrara
documenti devono essere implementatimi bensì risulta essere un modello logico
che può essere implementato in qualsiasi modo utile. Una proprietà importante del
modello della struttura del DOM è l'isomorfismo strutturale: se due qualsiasi
implementazioni del Document Object Model sono usate per creare una
rappresentazione dello stesso documento, creeranno lo stesso modello di struttura,
con esattamente gli stessi oggetti e relazioni.
Figura 2.5: Gerarchia DOM di una pagina Web
Il nome "Document Object Model" è stato scelto perchè è un "modello dell'oggetto"
nel senso tradizionale del design orientato all'oggetto: le pagine sono modellate
usando gli oggetti e il modello comprende non solo la struttura di un documento ma
anche il suo comportamento e gli oggetti da cui esso è composto. In altre parole, i
nodi in Figura 2.3 non rappresentano una struttura di dati, ma oggetti che hanno
funzioni ed identità. In pratica il DOM identifica:
41
Università degli studi di Ferrara
•
le interfacce e gli oggetti usati per rappresentare e manipolare un
documento;
•
la semantica di queste interfacce e oggetti - includendo sia il
comportamento che gli attributi;
•
le relazioni e le collaborazioni tra queste interfacce e gli oggetti.
Il Document Object Model consiste attualmente di due parti, DOM Core e DOM
HTML. Il DOM Core rappresenta la funzionalità usata per i documenti XML, e serve
anche come base per il DOM HTML. Un'implementazione del DOM deve
implementare tutte le interfacce fondamentali nel capitolo Core con la semantica
come definita. Inoltre, deve implementare almeno una delle interfacce HTML DOM.
Ogni oggetto del DOM possiede metodi di utilizzo e tipi di dato dipendenti dalla sua
funzione all’interno della pagina stessa e a ciascuno può essere associato un
diverso stile di presentazione. La funzione principale del DOM è però quella di
offrire a un programma JavaScript la capacità di rilevare eventi su ogni singolo
componente di una pagina (dal click su un pulsante alla scrittura in uno specifico
campo di un modulo) e di modificarne le rispettive proprietà.
Un altro aspetto importante è il fatto che, anche se viene sfruttato prevalentemente
in ambito Ajax, JavaScript non è certo l’unico linguaggio con cui è possibile
lavorarci. Per esempio anche PHP, Ruby, Perl, Python contengono Api complete
per accedere al Dom e ai metodi ad esso associati.
2.1.5 I CSS
I CSS (acronimo di Cascade Style Sheets) sono uno strumento finalizzato alla
graficazione degli elementi in pagine Web. Infatti essi permettono di gestire colori,
posizionamento, impaginazione, font (caratteri tipografici) e molto altro ancora in
maniera molto più completa del semplice HTML. Uno dei tanti vantaggi nell'usare i
fogli di stile è la possibilità di usare un solo documento esterno collegato a tutte le
pagine con il vantaggio di riutilizzare delle impostazioni grafiche già utilizzate per
42
Università degli studi di Ferrara
altri elementi. Ristabiliscono, secondo lo spirito originario di HTML, la separazione
di significato e presentazione.
Sono una raccomandazione del W3C, che ne ha rilasciato diverse versioni: nel
dicembre del 1996 (CSS1), rivista e ampliata nel 1998 (CSS2) e implementata nello
standard HTML 4.
L’uso dei CSS risolve il problema, in termini più tecnici, riguardo alla separazione
SGML tra stile, contenuti e struttura. Infatti l’HTML "tradizionale" non soddisfa
questa condizione, ma anzi, ne esaspera la confusione. Lavorando perciò in
abbinamento al linguaggio HTML offre un meccanismo per aggiungere dello stile ad
una pagina Web. Più precisamente in un foglio di stile sono specificati un set di
regole stilistiche che descrivono come un documento HTML verrà presentato
all'utente. Visto in quest'ottica, HTML viene usato per descrivere la struttura del
documento e le sue varie parti non curandosi del suo aspetto.
Questa tecnologia inoltre gode di ulteriori proprietà: è molto flessibile in quanto
fornita di un meccanismo capace di propagare un determinato aspetto di
presentazione su tutte le pagine, cosicché una modifica di presentazione fatta in un
unico file si ripercuote a tutti i documenti che ne fanno riferimento semplificando
notevolmente il lavoro di revisione e mantenimento delle pagine di un sito Web.
2.2 Il linguaggio per dialogare col server: Ruby
Ruby è un linguaggio di scripting completamente a oggetti. E’ stato ideato da
Yukihiro "Matz" Matsumoto tra il 1993 ed il 1995.
Il linguaggio che ha
maggiormente ispirato l'autore è sicuramente Smalltalk, da cui Ruby ha tratto la
maggior parte delle sue caratteristiche. Il suo paradigma è puro, come quello di
Smalltalk, ossia ogni componente del linguaggio, dalle costanti numeriche alle
classi, è un oggetto, e come tale può possedere metodi; a differenza dei linguaggi
come C++ e derivati, tuttavia, gli oggetti in Ruby sono qualcosa di molto più
dinamico, in quanto è possibile aggiungere o modificare metodi a run-time. Il tipo di
43
Università degli studi di Ferrara
un oggetto, perciò, non è definito tanto dalla classe che lo ha istanziato, quanto
dall'insieme dei metodi che possiede.
Ruby permette di ridefinire gli operatori come in C++, è quindi possibile usare i vari
+, -, *, <, << per compiere operazioni su tipi di dato definiti dall'utente. Inoltre
essendo un linguaggio interpretato non necessita di compilazione e questo lo rende
molto adatto per RAD (Rapid Application Development) perché permette di saltare
la fase di compilazione. Anche in virtù del fatto di essere un linguaggio molto
giovane, Ruby presenta tutte le peculiarità di un linguaggio di programmazione OO
moderno.
Gli oggetti vengono creati chiamando un costruttore, vale a dire un metodo speciale
associato a una classe: il costruttore standard è chiamato new(). Ad esempio a
fronte di una classe LineItem, si può creare oggetti LineItem mediante le istruzioni
rappresentate in Figura 2.6.
Figura 2.6:Codice Ruby per creare oggetti
Entrambe
le
istanze
derivano
dalla
stessa
classe,
tuttavia
possiedono
caratteristiche univoche: ciascuna ha un proprio stato, conservato internamente in
apposite
variabili d’istanza. Nel caso dell’esempio, quindi, ciascun oggetto
Line_Item conterrà una variabile d’istanza che registra la quantità degli articoli.
Nell’ambito di ciascuna classe si possono definire alcuni metodi d’istanza. Ogni
44
Università degli studi di Ferrara
metodo di questo tipo rappresenta un insieme di funzionalità che può essere
chiamato dall’interno della classe stessa e, se le regole di visibilità lo consentono,
anche dall’esterno. I metodi vengono invocati trasmettendo a un oggetto un
messaggio, che contiene il nome del metodo, nonché tutti i parametri di cui esso
può avere bisogno.
Tra le caratteristiche principali di Ruby, quelle che ne hanno determinato il
successo sono :
•
potenti operazioni su stringhe e espressioni regolari;
•
dichiarazioni delle variabili non necessarie;
•
variabili non tipizzate;
•
sintassi semplice e consistente;
•
gestione della memoria.
2.3 Il linguaggio di interrogazione col database: SQL
SQL (Structured Query Language) è un linguaggio che consente di scrivere
interrogazioni a un DB (o query) in termini relativamente semplici e comprensibili. È
un linguaggio che serve per eseguire varie operazioni sia sui dati che sulle strutture
che li contengono. La sigla è ormai diventata sinonimo di linguaggio standard per la
gestione dei database relazionali.
SQL assolve alle funzioni di Data Description Languge (linguaggio di descrizione
dei dati e delle strutture che li conterranno), di Data Manager Language (linguaggio
per la manipolazione dei dati) e di linguaggio di interrogazione. SQL è un linguaggio
di alto livello perché permette di svolgere operazioni dichiarando cosa si deve
ottenere e non come si deve ottenere. Esso libera lo sviluppatore dal gravoso
compito di scrivere pagine e pagine di codice
Il linguaggio, oltre a offrire agli sviluppatori un mezzo con cui ottimizzare il carico di
lavoro, rappresenta uno standard comune per l’accesso a svariati database. Si
45
Università degli studi di Ferrara
prefigge di riuscire a istaurare con la base di dati una comunicazione fondata su
poche ma efficaci righe di codice, con l’intento di dare a ciascuna richiesta un
significato preciso a cui fornire una risposta univoca basata sulla restituzione di
record prelevati dalle tabelle.
La sintassi di SQL è molto rigida e semplice, e ciò garantisce una completa
indipendenza dal supporto su cui è chiamato a operare.
2.4 Lo strumento di sviluppo: Ruby on Rails
Ruby on Rails (spesso chiamato RoR o semplicemente Rails) è un framework open
source, scritto in Ruby, per lo sviluppo di applicazioni Web che segue strettamente
l’architettura MVC (Model-View-Controller). E’ semplice da usare e permette di
sviluppare applicazioni con meno codice rispetto ad altri framework e con
pochissime configurazioni. La semplicità deriva dal fatto che il framework è stato
estratto da Basecamp, un’applicazione per il project management che consente la
collaborazione di progetti.
Rails è distribuito tramite RubyGems o sotto altre forme a seconda del sistema
operativo utilizzato. La filosofia e le linee guida che lo governano sono riassumibili
attraverso due concetti:
•
•
Don’t Repeat Yourself (DRY)
Convention over configuration.
DRY significa letteralmente ”non ripetere te stesso”, in riferimento alla necessità di
dare le definizioni una sola volta all’interno dell’applicazione (se ad esempio un
record di una tabella necessita di un prezzo, valore numerico positivo, il vincolo
viene espresso una sola volta all’interno dell’intera applicazione) e ancor più di
scrivere il codice in modo che possa essere riutilizzato nel caso all’interno della
pagina ci siano altri elementi che lo richiedano. Convention over configuration,
invece sposta l’attenzione sulla necessità di rispettare delle convenzioni stabilite da
46
Università degli studi di Ferrara
Rails durante la programmazione; questo significa che il programmatore ha bisogno
di metter mano alla configurazione soltanto per ciò che differisce dalle convenzioni.
Ad esempio, se un modello è costituito dalla classe Post, la corrispondente tabella
nel database deve chiamarsi posts (con la lettera iniziale minuscola e la s alla fine
della parola). Con tale convenzione non è perciò necessario andare a
implementare alcun meccanismo che consenta il collegamento tra database e
modello.
2.4.1 Architettura dell’applicativo: model / view / controller
Un aspetto molto importante di RoR è la sua architettura Model-View-Controller
(MVC). Lo sviluppo di un’applicazione in rails ruota completamente attorno a questi
tre oggetti.
Figura 2.7: Architettura modello-vista-controller
47
Università degli studi di Ferrara
Model: nelle applicazioni con questa architettura il modello consiste nelle classi che
rappresentano le tabelle del database. Queste classi derivano da ActiveRecord e,
seguendo le convenzioni di RoR, ActiveRecord automatizza la maggior parte delle
funzioni necessarie, come il collegamento al database o le relazioni tra le tabelle,
tramite delle semplici dichiarazioni all’interno del modello. Al modello è affidato il
mantenimento dello stato dell’applicazione, che può essere transitorio, ossia durare
il tempo di pochissime interazioni da parte dell’utente, ad esempio per mantenere
memorizzate le aperture di più finestre contemporaneamente, oppure permanente,
cioè registrato all’esterno dell’applicazione in un database. Un modello non
rappresenta soltanto dati, ma stabilisce le regole applicative (business rule) cui
devono attenersi tutti i dati all’interno dell’applicazione; questo garantisce che i dati
vengano sempre memorizzati in uno stato consistente. Il modello, quindi, svolge
simultaneamente le funzioni di “custode” e di “contenitore” di dati.
View: come mostrato in Figura 2.7 alla fase 4 del processo, la vista presenta
all’utente i dati, nel caso di un’applicazione Web sotto forma di pagine HTML. E’
possibile l’utilizzo di parti comuni, template, tra le varie pagine (come barre dei
menù, piè di pagina, …), l’uso di frammenti di codice richiamati da altri frammenti
che rappresentano oggetti o collezioni di oggetti. Questa parte del framework è
gestita dall’ActionPack; l’elaborazione dei dati da visualizzare viene fatta all’interno
del Controller ed è completamente separata dalla presentazione stessa. Perciò il
suo compito si limita alla presentazione dei contenuti o alla loro reperimento
mediante moduli di input, mai alla loro gestione e al loro inserimento nelle basi di
dati. L’attività di una vista si esaurisce non appena i dati sono stati visualizzati.
All’interno della vista vengono inserite tutte quelle logiche applicative che dovranno
gestire le interazioni con l’utente e supportare il funzionamento del sistema a livello
client.
Controller: Il controller coordina l’applicazione: riceve gli eventi dal mondo esterno
(vedi Figura 2.7 fase 1), interagisce con il modello e elabora i dati tramite il Model
(fase 2) e fornisce all’utente la vista appropriata tramite la View (fase 3 e 4). E’ il
cuore dell’application server, in quanto a esso è demandata tutta la parte di
comunicazione e gestione sia con il Web desktop che con i servizi terzi presenti
48
Università degli studi di Ferrara
all’interno di esso. Il controller viene richiamato dall’utente tramite il browser. Egli
deriva da ActionPack, nel quale vengono scritti i metodi che sono richiamati
direttamente dalle richieste del browser.
Rails permette inoltre di creare lo Scaffold, uno scheletro che consente di effettuare
sul database operazioni base come le CRUD (acronimo di Create, Retrieve,
Update, and Delete) . Questo scheletro, creando automaticamente i file necessari
al modello, alla vista e al controllore, dà all’utente l’opportunità di effettuare
operazioni di base come l’inserimento, la modifica, la cancellazione e la
visualizzazione dei dati all’interno del database. Inoltre questa struttura può essere
utilizzata come base di partenza dell’applicazione sviluppata, modificando e
ampliando opportunamente le varie parti che lo necessitano.
I tre componenti modello-vista-controller costituiscono l’architettura denominata
MVC, utilizzata per sviluppare desktop@UniFe proprio perché consente una
semplificazione della gestione di tutta la logica applicativa.
Ovviamente all’interno di questa struttura si sono poi andati a integrare tutti i
linguaggi e le filosofie legate al Web 2.0 che hanno consentito lo sviluppo del Web
Operating System descritto nel prossimo capitolo.
2.5 Prototype e script.aculo.us
Nello sviluppo della parte lato client dell’applicativo ci si è appoggiati sulla libreria
prototype, contenente le primitive per la referenziazione degli elementi DOM e per
la gestione delle chiamate remote AJAX. Inoltre per riuscire ad implementare
funzionalità grafiche avanzate, come ad esempio il drug&drop delle icone o il
riposizionamento dei moduli feed, si è fatto largo uso delle API offerte da
script.aculo.us.
Prototype.js e' una libreria JavaScript scritta da Sam Stephenson, contenente molte
funzioni JS richiamabili a piacimento. L'obiettivo ovvio e' quello di evitare di scrivere
49
Università degli studi di Ferrara
del codice ripetitivo. Le funzionalità principali sono legate alla funzione $(‘ ‘) con la
quale è possibile referenziare qualsiasi tipo di oggetto presente in una pagina
HTML, ricevendo in cambio il riferimento all’elemento e alla classe Ajax.Request,
responsabile di tutte le chiamate remote asincrone utilizzate dal desktop.
Ovviamente su questa classe si appoggiano anche le principali API di Ruby
riguardanti le connessioni al Server.
Anche Script.aculo.us fornisce delle librerie Javascript facili da usare e compatibili
per migliorare i siti e gli applicativi Web, anche se di più alto livello rispetto a
prototype. Le sue caratteristiche principali sono sintetizzabili con l’analisi di alcune
funzionalità rese disponibili:
•
Drag-and-drop per migliorare l'interazione dell'utente con il browser. Queste
API forniscono pure un supporto per la serializzazione di liste ordinabili, float
e per chiamate AJAX.
•
Controlli: Per fornire agli utenti dei campi di testo auto-completanti
localmente o controllati da AJAX.
•
Miglioramento degli effetti visivi: attraverso l’implementazione di funzionalità
avanzate legate alla modifica delle caratteristiche grafiche legate agli
elementi DOM.
50
Università degli studi di Ferrara
Capitolo 3: PROGETTO DESKTOP@UNIFE
Il progetto desktop@UniFe ha come obiettivo la realizzazione di un Web desktop
per l’aggregazione di servizi. Lo scopo è quello di consentire una personalizzazione
di un applicativo Web-based simile a un comunissimo desktop da PC. Si mira a far
confluire il maggior numero di servizi in un’unica pagina Web, gestibile dall’utente
attraverso gli strumenti che abitualmente vengono messi a disposizione di
applicazioni locali.
Si vuole perciò creare un Web operating system nel quale spostare il concetto di
gestione in ambiente locale, quindi associato a un determinato dispositivo, a un
ambiente distribuito, fruibile ovunque e con qualunque dispositivo. Il fine ultimo è
perciò quello di sviluppare una RIA (Rich Internet Application) che attraverso
un’unica autenticazione permetta di usufruire dei servizi dell'Università degli Studi
di Ferrara e, allo stesso tempo, consenta una integrazione con servizi terzi quali la
gestione di folksonomy di contenuti Web, lettura di feed RSS e ATOM,
personalizzazione di un servizio di aggregazione di account di mail, integrazione di
Gmail e di Google, attraverso il quale poter fare ricerche direttamente “dall’interno”
dell’applicativo (vedi Figura 3.1).
Inoltre si vuole inserire la possibilità di creare documenti testuali attraverso l’uso di
un editor di testo con funzionalità tipiche dei più comuni programmi di editing usati
in ambienti locali. Non ultimo, la possibilità di gestire uno spazio virtuale attraverso
un file manager appositamente creato per upload e download di propri file,
rendendoli perciò accessibili dovunque e in qualsiasi momento tramite un semplice
browser.
Tale applicativo dovrebbe poi essere accorpato nel CMS (Content Management
System) adottato per il portale di Ateneo.
51
Università degli studi di Ferrara
Figura 3.1: Progetto logico di desktop@UniFe
Questo Web Desktop raccoglie al suo interno la filosofia portata avanti dal Web 2.0,
secondo la quale l’applicativo Web non deve più essere visto come un semplice
contenitore di siti ma come una piattaforma per lo sviluppo e la distribuzione di
servizi.
3.1 Rich Internet Application
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.
52
Università degli studi di Ferrara
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 gestione totalmente rinnovata, fondata sul meglio
delle caratteristiche funzionali e progettuali che finora erano prerogativa del Web o
delle applicazioni desktop.
Le caratteristiche fondamentali delle RIA, riassunte in Figura 3.2, sono evidenziabili
attraverso la sintesi di sei punti fondamentali:
•
Web deployment;
•
Logica applicativa suddivisa tra Client (desktop-based) e Server (browserbased);
•
Interazione immediata senza percezione di una comunicazione col Server;
•
Flussi di esecuzione multipli e scambio di informazioni basato su XML;
•
Accesso a rich content: audio/video.
Inoltre è da tener presente che lo sviluppo di una RIA
consente di apportare
notevoli miglioramenti sia a livello grafico, eliminando molti vincoli legati alla
staticità degli elementi visualizzati in una pagina Web, sia a livello prestazionale,
garantendo aggiornamenti solamente di quei moduli strettamente vincolati
all’azione dell’utente all’interno del Web-desktop.
Figura 3.2: Architettura di riferimento delle RIA
53
Università degli studi di Ferrara
3.2 Motivazioni del progetto
L’Università degli studi di Ferrara distribuisce vari servizi e pubblica numerosi
contenuti:
•
Posta elettronica;
•
Spazio Web;
•
Liste d’esame;
•
Spazio disco virtuale;
•
News di ateneo.
Questi servizi sono tutti accessibili attraverso il Web, ma ognuno necessita di una
autenticazione e di una gestione dedicata (come mostrato in Figura 3.3). Inoltre,
per quanto riguarda alcuni di essi, spesso gli utenti necessitano di assistenza in
loco per problematiche riscontrate negli strumenti utilizzati in locale, come ad
esempio Client di posta.
Figura 3.3: Servizi UniFe
54
Università degli studi di Ferrara
Per risolvere questo problema si deve fornire un unico punto di accesso a tutti i
servizi (single sign on) e che allo stesso tempo consentisse una maggior versatilità
nell’utilizzo dell’applicativo creato, come mostrato in Figura 3.4.
Figura 3.4: Single sign on desktop@UniFe
3.3 Specifiche di progetto
Come oramai evidenziato più volte, lo scopo finale dell’applicazione è quello di
creare un Web operating system. Per fare questo si è cercato di includere nelle
specifiche di progetto molte delle caratteristiche alla base del concetto di desktop
che si è soliti utilizzare sul proprio PC.
Il desktop è un’interfaccia grafica che permette l’utilizzo dei servizi attraverso
l’interazione con le icone presenti sul video, le barre degli strumenti visualizzate alla
base della pagina e la presenza di directory nelle quali poter archiviare i file. Tutti
questi elementi vengono personalizzati e gestiti (posizionamento e loro
55
Università degli studi di Ferrara
denominazione) dall’utente, che ne determina la disposizione attraverso l’uso di
drag&drop e di funzionalità quali il resize.
Applicare questi concetti a un browser Web, significa concedere le stesse
funzionalità grafiche, gestendo però in maniera totalmente diversa la parte
applicativa presente al di sotto: le directory infatti non saranno locali ma remote, le
impostazioni del desktop non saranno memorizzate in locale ma bensì in un
database presente sul server e la logica di funzionamento verrà suddivisa in parte
sul server e in parte sul client. Non ci sarà perciò la necessità di dover installare
alcun pacchetto per dover far funzionare il servizio. La conseguenza di tale scelta
sarà un disaccoppiamento tra la macchina fisica locale dall’applicativo desktop, in
maniera che l’utente non dovrà mai interessarsi del luogo su cui saranno salvati i
propri dati e dove saranno residenti gli applicativi.
Tra le specifiche, di particolare importanza è la flessibilità dell’applicativo, sia a
livello architetturale, sia a livello di utilizzabilità.
Infatti, una delle caratteristiche fondamentali di un desktop locale è la possibilità di
installare qualsiasi tipo di programma, senza dover stravolgerne la struttura. Questo
garantisce l’inserimento di nuove funzionalità in maniera pratica, non dovendo
rimaneggiare l’architettura dei dati ogni volta. Ciò deve avvenire anche nel Web
desktop, dove l’aggiunta di un nuovo servizio deve avvenire con modalità il più
possibile semplici, andando a integrare quelli già presenti. L’applicazione dovrà
essere personalizzabile a piacimento dall’utente, in modo che tali operazioni
avvengano in maniera intuitiva, con semplici spostamenti di mouse o di inserimenti
da menù.
Prevedendo l’utilizzo dell’applicativo anche a risoluzioni differenti (si pensi
addirittura allo schermo di un palmare), si dovrà prevedere una struttura grafica
fluida e dipendente dalla grandezza dello schermo dell’utente, consentendo
comunque il posizionamento dei moduli principali del servizio in zone sempre
“accessibili” e riposizionabili.
56
Università degli studi di Ferrara
Essendo il desktop una metafora della propria scrivania su monitor, dove sono
posizionati i documenti e le cartelle a cui si è interessati in un ordine logico
personale, dovrà essere garantita la massima interagibilità con l’utente,
consentendo sia l’interfacciamento a servizi pubblicati da terzi, come ad esempio
caselle di posta elettronica o gestione di propri bookmark, sia l’utilizzabilità di
strumenti di lavoro simil Office, che consentano di creare propri file da salvare a
discrezione dell’utente in remoto o in locale.
La filosofia sulla quale il Web operating system si fonda è quella legata al Web 2.0,
cioè alla possibilità di riutilizzare e condividere contenuti già esistenti. Proprio per
questo si dovrà prevedere la possibilità di condividere propri documenti con altri
utenti, sia in modalità di lettura che in modalità di scrittura, lasciando al creatore la
scelta degli individui con i quali collaborare.
Tutte le impostazioni e le personalizzazioni dovranno essere mantenute in
database, in modo da riuscire a riproporre l’ultimo ambiente di lavoro dell’utente,
indipendentemente dal dispositivo con il quale si è acceduti al Web desktop, che
sia da casa o dal lavoro, da un PC o da un palmare.
Sarà necessario prevedere un alto grado di sicurezza, sia facendo attenzione a
lasciare i dati sensibili in luoghi protetti, garantendo che non sia possibile
appropriarsi dell’identità virtuale di altri, sia cercando di spostare l’applicazione o
parte di essa su canali di comunicazione sicuri (https).
3.4 Architettura del Web operating system
Il Web operating system è un servizio fruibile e gestibile via Web, perciò vincolato ai
protocolli di comunicazione che regolano lo scambio di informazioni tra client e
server e sottoposto alle limitazioni derivanti dall’avere l’insieme dei dati residenti in
remoto. Proprio per questo nel progettare il sistema, si è partiti dall’analisi dei
meccanismi con i quali a livello client avvengono le interazioni con l’utente. Come
mostra la Figura 3.5 queste vengono catturate e gestite autonomamente da AJAX
57
Università degli studi di Ferrara
Engine, un'infrastruttura in Javascript che ha la funzione di gestire ed inoltrare le
richieste. Nel caso fosse necessaria una comunicazione al Server, il motore
effettua una richiesta asincrona all’application Server che, dopo averla elaborata,
reperisce le informazioni che servono per la risposta e genera dinamicamente una
pagina XML da rinviare al client in base ai dati ricevuti. Tali dati vengono cercati o
nel database legato all’applicazione, nel quale sono contenute tutte le informazioni
necessarie al desktop per funzionare, o nei servizi gestiti direttamente dall’Ateneo,
o attraverso richieste a servizi esterni pubblicati all’interno del Web operating
system. In questo modo vengono richieste solo le informazioni strettamente
necessarie evitando di ricaricare ogni volta interamente la pagina, con un notevole
vantaggio di traffico di rete.
Figura 3.5: Architettura di desktop@UniFe
58
Università degli studi di Ferrara
3.4.1 Il “fat Client”
Lo strumento utilizzato per accedere al servizio sarà un comunissimo browser Web,
al quale è demandato il compito di raccogliere tutte le azioni dell’utente e,
attraverso appositi linguaggi, codificarle e inviarle all’application server. Avrà
successivamente il compito di raccogliere le informazioni arrivate da remoto e
ripresentarle a video. Vista però la natura del Web operating system, sarà
necessario sviluppare il sistema facendo in modo che il browser non sia
semplicemente un visualizzatore di dati arrivati da remoto ma bensì uno strumento
particolarmente attivo da poter gestire e rispondere alle azioni dell’utente.
Si è scelto di spostare a livello client il maggior numero di funzionalità possibili,
spostandosi dall’architettura delle comuni applicazioni Web a tre livelli, nel quale
gran parte della logica applicativa risiede sul Web service, ad un’architettura a due
livelli, nella quale la maggior parte della logica applicativa risiede su client (vedi
Figura 3.6).
Figura3.6: Architetture Web a 3 e 2 livelli
59
Università degli studi di Ferrara
Proprio per questo il lato client dell’applicazione non è un “thin client”, che
tipicamente non possiede logica applicativa e dipende principalmente dal server
centrale per elaborare dati, limitandosi a visualizzare pagine Web all’interno di un
percorso di navigazione, ma bensì un “fat client”, nel quale la capacità del browser
di gestire in locale gran parte delle interazioni con l’utente è conseguenza dell’avere
la logica di gestione del sistema in locale. Per apprezzare le differenze tra i due tipi
di client, si osservi la Figura 3.7 che mostra alcuni punti base di ciascun approccio.
Figura 3.7: Thin client vs Fat Client
Saranno perciò implementate molte operazioni che verranno controllate localmente
su client, senza perciò comunicare con il server:
60
•
drag&drop;
•
modifica del tema del desktop;
•
apertura e chiusura di finestre;
•
gestione dell’editor;
•
resize di finestre;
Università degli studi di Ferrara
•
risposte ad eventi scatenati con l’uso del mouse;
•
creazione, modifica e cancellazione di icone e cartelle;
•
interazione con la barra degli strumenti e con il menù di avvio.
Ovviamente qualsiasi modifica avvenga dello stato, verrà poi memorizzata in un
database remoto, al quale specificare le modifiche attraverso una comunicazione
asincrona tra client e server.
3.4.2 L’application server
L’application server avrà il compito di gestire la comunicazione con il client
attraverso un linguaggio comune a entrambi, mantenere lo stato della
comunicazione e della sessione avviata dall’utente e interagire con i vari servizi, sia
interni che esterni, previsti nel desktop. Tali comunicazioni dovranno avvenire in
modo totalmente asincrono, ovvero non sarà mai necessario ricaricare totalmente
la pagina visualizzata dall’utente ma solamente i moduli e gli oggetti interessati a un
aggiornamento dei loro contenuti.
L’unico momento nel quale l’operazione di caricamento avverrà in maniera totale
sarà all’atto di login, quando l’application server invierà al client la struttura del Web
desktop e i dati archiviati relativi all’utente specifico.
Il flusso delle operazioni sarà perciò riassumibile in alcune fasi:
•
il client invia all’application server i dati dell’utente per l’autenticazione;
•
l’application server, verificate le credenziali ricevute, andrà ad interrogare il
database per ricevere le informazioni riguardanti i servizi attivi nel Web
operating system dell’utente;
•
successivamente
le
invierà
al
client
(attraverso
un
linguaggio
convenzionale), insieme alla logica applicativa del desktop;
61
Università degli studi di Ferrara
•
durante l’uso dell’applicativo, ogni volta che l’utente compie delle modifiche
al suo stato, viene inviato dal client al server un messaggio contenente le
modifiche da apportare ai dati presenti su database;
•
il server invierà, quando richiesto, le informazioni necessarie per aggiornare
e ricaricare parte dei moduli presenti nel Web desktop dell’utente.
Ovviamente tutte le informazioni raccolte dal Web desktop relative ai servizi terzi,
dovranno sempre essere reperite dall’application server, che è l’unico punto di
contatto dell’intero sistema verso l’esterno.
3.5 Fasi di progetto
Un applicativo complesso come un Web operating system ha richiesto una
progettazione accurata soprattutto in riferimento alle fasi di sviluppo e di
programmazione. Come prima cosa si è dovuto stabilire su quali tecnologie fondare
l’intero servizio; infatti una scelta corretta degli strumenti garantisce una maggiore
semplicità di programmazione e una migliore flessibilità ed estendibilità futura.
Il passo successivo è stato quello di analizzare i prototipi di Web desktop già
abbozzati, cercando di carpirne le positività e provando ad inquadrare i possibili
sviluppi e miglioramenti. A questo punto si è iniziato a schematizzare e progettare
l’intera struttura dati sulla quale fondare l’intero applicativo, in modo che fosse
sempre possibile integrarla e ampliarla. Sempre in questa fase, è stato necessario
capire in quale modo gestire l’autenticazione dell’utente, cercando di basarsi sugli
strumenti già presenti.
Fatto questo, si è iniziato a creare un primo prototipo, partendo dalla creazione
della struttura generale del desktop, dentro la quale andare poi ad inserire tutti i
servizi. Durante questa fase si sono andate ad implementare tutte quelle
funzionalità essenziali e comuni a tutte le aree del sistema, come ad esempio
controllo del drag&drop, gestione delle finestre contenenti i servizi (creazione,
62
Università degli studi di Ferrara
cancellazione e riduzione ad icona), creazione dei moduli comuni (titoli, segnalibri,
tab).
Da notare che tali operazioni, pur “svolgendosi” in locale, sono state gestite anche
in remoto, attraverso la configurazione dei controller appropriati.
Una volta creato questo primo prototipo si è andato a testare la sua stabilità,
cercando di gestire possibili errori o malfunzionamenti e cercando di rendere l’intero
flusso di comunicazione il più possibile snello e veloce.
Fatto questo si è potuto procedere con la seconda fase, finalizzata all’aggregazione
delle varie funzionalità inquadrate in fase di progetto. Per ciascun servizio si è
creato un controller dedicato e una serie di viste che garantissero lo scambio di
informazioni con l’utente. Tali moduli sono stati inseriti all’interno del prototipo
creato in precedenza, che è stato testato ogni volta che una funzionalità nuova
veniva inserita con successo all’interno dell’applicativo. E’ infatti indispensabile che
i
servizi
non
interferiscano
tra
loro
e
siano
compatibili
e
usabili
contemporaneamente all’interno dello stesso dispositivo.
Una volta integrate un certo numero di funzionalità, è stato indispensabile curare la
parte di sicurezza, spostando la comunicazione tra client e server su canali sicuri.
E’ importante che anche nella fase di beta testing questo aspetto sia stato curato e
valutato, per capire i risvolti che l’integrazione con LDAP e comunicazione over
HTTPS porta all’applicativo.
Solo a questo punto è stato possibile pubblicare il Web desktop, dando agli utenti la
possibilità di iniziare ad usufruire dei servizi contenuti in esso.
Una volta valutata la stabilità di tutto il sistema è stato possibile continuare ad
aggregare nuovi servizi, seguendo il ciclo di integrazione e test utilizzato per
valutarne la sicurezza e il funzionamento.
Da notare che essendo un progetto relativo ad un Web operating system sviluppato
secondo la filosofia Web 2.0, non si può porre un limite prefissato al numero di
63
Università degli studi di Ferrara
contenuti che si potranno aggregare all’interno di desktop@UniFe, lasciando altresì
aperta la possibilità di ampliamento e sviluppo a seconda delle necessità.
Figura 3.8: Fasi di progetto
64
Università degli studi di Ferrara
Capitolo 4: DESKTOP@UNIFE: MANUALE UTENTE
Desktop@UniFe è un progetto sperimentale dell’Università di Ferrara per lo
sviluppo di un Web operating system, un sistema operativo on line, Web based.
Esso risiede completamente e unicamente sul Server e non richiede alcun tipo di
installazione, né di plug-in né tanto meno di software dedicati.
Il sistema operativo è ancora all’inizio del proprio percorso di sviluppo ma possiede
già molte delle caratteristiche progettate in fase di ideazione, che caratterizzano
comunemente i veri sistemi operativi locali.
4.1 Accesso all’applicativo
L’accesso all’applicativo avviene attraverso la schermata di autenticazione come
quella mostrata in Figura 4.1, nella quale è richiesto l’inserimento di username e
password. Una volta verificate le credenziali l’applicativo inizia una fase di sturt-up,
nella quale vengono caricate tutte le funzionalità del Web operating system in
locale, in modo che la maggior parte dei servizi e dei dati siano consultabili e
utilizzabili in maniera veloce e immediata, senza dover interrogare ogni volta il
Server, rimanendo in attesa delle sue risposte. Perciò le informazioni legate agli
account di posta o quelle relative alla lettura dei feed sono scaricate direttamente
sul computer dell’utente, a scapito di un breve tempo di attesa durante la fase di
accesso al servizio. La maggior parte della gestione dell’applicativo avviene infatti
attraverso l’uso di Javascript, a cui è demandato il compito di gestire i dati scaricati
da remoto e di rispondere agli eventi scatenati dall’utente attraverso l’uso del
mouse o della tastiera. Ovviamente l’uso di desktop@UniFe è esclusivo per coloro
che possiedono una matricola presso l’Ateneo, visto che le credenziali di accesso
sono proprio quelle relative alla propria immatricolazione.
65
Università degli studi di Ferrara
Figura 4.1: Schermata di accesso
4.2 La “scrivania” del Web operating system
Dopo l’autenticazione, l’utente si trova a operare in un contesto decisamente
familiare. Sul desktop sono presenti le principali icone di sistema, da quella riferita
all’Home Page di Ateneo, all’icona relativa alla modifica del tema del sito e
all’apertura dei servizi presenti all’interno dell’applicativo (vedi Figura 4.2):
66
•
Aggregatore di Feed;
•
Gestore di Mail;
•
Filesystem remoto;
•
Editor di Testo;
•
Gestore di Bookmark;
•
Ricerca di contenuti all’interno del Web.
Università degli studi di Ferrara
Figura 4.2: La scrivania
Oltre alle icone mostrate è possibile inserire link personali attraverso il click ad
“Aggiungi nuovo Link”, posto in alto a destra della schermata. Tale operazione fa
apparire un modulo nel quale è possibile specificare il nome dell’icona da creare, il
collegamento alla pagina desiderata e l’immagine da mostrare sul desktop,
seguendo il procedimento evidenziato in Figura 4.3.
Figura 4.3: Inserimento di una icona
67
Università degli studi di Ferrara
L’apertura delle applicazioni incorporate all’interno del desktop può avvenire anche
attraverso l’alter ego del più classico pulsante ‘Avvio’ di Windows. Esso consente di
muoversi all’interno di un menu a tendina come quello mostrato in Figura 4.4. Offre
diverse possibilità: dal pannello per la configurazione della propria scrivania, al
programma di editor, fino alla gestione di file e directory.
La prova che quello che viene visualizzato non è una comune pagina Web
all’interno del browser si ha terminando la sessione attraverso l’uso del link logout
in fondo al menù e loggandosi, di nuovo, da un computer diverso. L’ambiente di
lavoro è esattamente come lo si è lasciato all’ultimo accesso comprese le modifiche
apportate alle icone o ai colori della scrivania.
Figura 4.4: Il menù a tendina
4.3 L’aggregatore di feed
Il feed reader integrato nel Web desktop è un programma in grado di effettuare il
download di un feed RSS o ATOM (è sufficiente che l'utente indichi al programma
68
Università degli studi di Ferrara
l'URL del feed), effettuarne il parsing e visualizzarne i contenuti in base alle
preferenze dell'utente.
Inoltre il servizio è stato corredato di alcune funzionalità avanzate; ad esempio
l’applicativo è in grado di rilevare automaticamente se il produttore del feed ha
effettuato aggiornamenti al feed stesso, effettuandone il download a intervalli di
tempo regolari specificati dall’utente. In questo modo i moduli vengono rinfrescati
visualizzando sempre le ultime notizie pubblicate dal produttore.
La pagina visualizzata inizialmente dal servizio è come quella mostrata in Figura
4.5, nella quale i feed sono visualizzati in moduli indipendenti su colonne diverse. E’
possibile personalizzare la pagina specificando un numero di colonne diverso dal
menù a tendina posto in alto a destra.
Figura 4.5: L’aggregatore di feed
69
Università degli studi di Ferrara
Ovviamente ciascun modulo può essere gestito in maniera indipendente dagli altri,
decidendo il numero di titoli da visualizzare, la sua posizione all’interno della pagina
(modificabile attraverso una semplice operazione di drag&drop) e il tempo di
aggiornamento delle informazioni contenute in esso.
L’inserimento di un nuovo feed può avvenire attraverso due operazioni, a seconda
che l’utente sia in possesso dell’url del documento xml a cui fare riferimento o,
invece voglia scegliere da un elenco. Il primo modo è utilizzabile ciccando su
“Aggiungi Nuovo Feed” posto in alto a destra. Nel campo apparso si può inserire
direttamente l’url dell’xml, consentendo all’applicativo di scaricare le informazioni
nel feedreader. Spesso però l’utente non è in grado di fornire direttamente tale
informazione, essendo in possesso solamente dell’indirizzo del sito a cui accedere
per scaricare gli RSS. In tali casi inserendo l’url del sito l’applicativo è in grado di
verificare se esso pubblica dei feed e, in caso affermativo, di far comparire una lista
di quelli disponibili da cui l’utente può scegliere quello a lui più gradito, come
mostrato in Figura 4.6.
Figura 4.6: ricerca dei feed pubblicati da un sito
70
Università degli studi di Ferrara
Il secondo modo per inserire i moduli all’interno della pagina è quello di scegliere i
feed direttamente da un elenco di contenuti preimpostati cliccando sul link
“Seleziona nuovo Contenuto”. In questo caso l’utente selezionandone uno richiama
l’url associato direttamente dal database.
Il cuore del feedreader, però, è l’operazione di lettura degli articoli attraverso la
selezione di un titolo a cui si è interessati. In tal caso il documento viene mostrato in
una finestra come quella mostrata in Figura 4.7, nella quale è presente anche la
possibilità di accedere direttamente al sito nel quale il contenuto è stato prodotto
attraverso il link “Link all’articolo”.
Figura 4.7: Lettura di un feed
4.4 Il gestore di mail
Il gestore di account di posta elettronica integrato nel Web operating system è un
aggregatore che permette di operare sul contenuto di una o più caselle di posta
(fino a un massimo di 4). Esso presenta all'incirca le stesse caratteristiche di tutti i
71
Università degli studi di Ferrara
maggiori client di posta, differenziandosi per presentazione grafica e per
funzionalità implementate.
La funzione principale è la visualizzazione di una lista di messaggi presenti nella
casella, in cui per ogni messaggio si vedono solo alcuni header, come il Subject, la
data di invio ed il mittente. Tali informazioni sono contenute all’interno di moduli
come quelli mostrati in Figura 4.8.
Ovviamente la lettura del corpo della mail avviene attraverso la selezione di quella
desiderata.
Le
funzionalità
implementate
riguardano
principalmente
l’aggiornamento delle mail per garantire sempre una consultazione real-time della
propria casella di posta e la compatibilità con un numero molto ampio di provider,
consentendo l’uso del servizio con domini differenti.
Figura 4.8: Gestore di mail
72
Università degli studi di Ferrara
L’aggiunta di un nuovo account avviene attraverso il modulo “Aggiungi Nuova Mail”.
In tale finestra è possibile inserire tutti i dati relativi alla propria casella di posta e
alla configurazione che si vuole applicare ad essa: dal numero di mail visualizzate
al tempo di aggiornamento del modulo (vedi Figura 4.9). La scelta del mail server,
invece può avvenire o attraverso la selezione della voce desiderata da un menu a
tendina o attraverso la specifica dei parametri di connessione selezionando la voce
“altro account…”.
Tali configurazioni sono sostituibili in ogni momento attraverso l’uso della finestra di
modifica, mostrata in Figura 4.10, associata a ciascun modulo.
La maggior parte delle funzionalità di creazione mail sono invece state trascurate,
consentendo all’utente di compiere tali operazioni collegandosi direttamente al sito
interessato e componendo le proprie mail direttamente con gli strumenti offerti dal
dominio.
Figura 4.9: Inserimento nuovo account
Figura 4.10: Modifica impostazioni account
73
Università degli studi di Ferrara
4.5 Il gestore di bookmark
Il gestore di bookmark è un servizio basato sul Web, dove vengono resi disponibili
elenchi di segnalibri (bookmark) creati dagli utenti. Questi elenchi sono liberamente
consultabili e condivisibili con gli altri utenti appartenenti alla stessa comunità
virtuale.
L’intero servizio è basato sull’operazione di folksonomy gestita da del.icio.us. Infatti
per poter usufruire delle funzionalità messe a disposizione dall’applicativo per il
tagging dei siti bisogna aver compiuto la registrazione. Una volta memorizzati
username e password per l’accesso, si entra nella finestra dei bookmark, nella
quale è possibile gestire i propri tag e i propri segnalibri attraverso le funzionalità
disponibili. La Figura 4.11 mostra la disposizione delle finestre visualizzate. I tag
sono elencati in ordine alfabetico nel modulo di destra, mentre tutti gli URL
referenziati appaiono nella finestra di sinistra. Cliccando su un segnalibro è
possibile visualizzare gli url etichettati con quel particolare tag. Ovviamente
l’accesso al contenuto del link avviene attraverso il click sul titolo del sito. Come si
può notare dalla figura, ciascun item è seguito da tutti i tag ed esso associati che,
se selezionati, portano alla visualizzazione di tutti i titoli referenziati da quel
particolare segnalibro.
Figura 4.11: Il gestore di bookmark
74
Università degli studi di Ferrara
I contenuti gestiti dal servizio possono essere modificati attraverso due operazioni
attivabili attraverso il link “Inserisci nuovo Contenuto” posto in alto a sinistra:
l’inserimento di un nuovo item o la rinomina di un tag registrato. La prima
operazione può essere portata a termine inserendo nel modulo visualizzato in
Figura 4.12a il titolo da associare alla pagina Web a cui fare riferimento.
Ovviamente è possibile inserire i tag da associare, che possono essere già presenti
all’interno dell’elenco dei propri segnalibri oppure completamente nuovi. In
quest’ultimo caso l’applicativo provvede automaticamente a creare un nuovo tag e
ad inserirlo nella lista di quelli già registrati. La seconda operazione, invece, può
essere gestita attraverso la compilazione dei due campi mostrati in Figura 4.12b.
La modifica delle configurazioni del servizio può avvenire attraverso il link “Modifica
Impostazioni” in alto a destra nella Figura 4.11. Tale operazione consente di
modificare il numero di tag o di item visualizzati o di cambiare i parametri di
connessione (username e password) con del.icio.us.
Figura 4.12a: Modulo di inserimento item
Figura 4.12b: Modulo di rinomina tag
75
Università degli studi di Ferrara
4.6 L’editor di testo
Per lo sviluppo e la creazione dell’editor di testo ci si è appoggiati su TinyMCE, un
piccolo WYSIWYG (“What You See Is What You Get”, quello che si vede è quello
che si ottiene) editor scritto in Javascript per i Web browser che permette di editare
testi in modo comodo. Ha le funzionalità comuni di molti word processor e
soprattutto ha molte caratteristiche simil-office, molto conosciute e perciò facilmente
comprensibili e usabili.
L’accesso all’editor porta a una finestra come quella mostrata in Figura 4.13,
caratterizzata dalla barra degli strumenti in alto e dalla zona editabile in primo
piano.
Si è scelto di configurare TinyMCE nella sua forma “ADVANCED”, caratterizzata da
funzionalità base come i classici taglia-incolla o le funzioni di gestione dei font e da
altre più avanzate, come l’opportunità di inserire immagini o tabelle, gestendo la
Figura 4.13: L’editor di testo
76
Università degli studi di Ferrara
loro formattazione a piacimento. La barra degli strumenti dell’editor si presenta
come quella mostrata in Figura 4.14, molto simile a quella degli editor tipicamente
usati in ambienti locali.
Figura 4.14: Barra degli strumenti dell’editor
Ogni utente ha la possibilità di aprire contemporaneamente fino a 4 istanze
dell’editor, avendo in questo modo la possibilità di creare più testi in
contemporanea e potendo sfruttare la funzione di copia-incolla tra documenti
diversi, ovviamente ciascuno di essi con formattazioni grafiche proprie.
Di particolare interesse è la possibilità di condividere ciascun documento creato con
altri utenti. Per far questo è necessario spuntare la casella “Consenti condivisione
del documento” e inserire il numero di persone, le loro matricole e i permessi da
associare a ciascuno di esse relativi al documento, come mostrato in Figura 4.15.
Le modalità di condivisione possono essere solamente in lettura o anche in
scrittura, concedendo a quest’ultimi la possibilità di modificare il testo.
Ogni file creato può essere salvato in uno spazio virtuale personale su server,
richiamabile in ogni momento. Tale operazione è effettuabile attraverso il click sulla
Figura 4.15: Barra di condivisione del documento
77
Università degli studi di Ferrara
prima icona in alto a sinistra (quella raffigurante un floppy-disk). In questo modo
l’utente accede ad una finestra di riepilogo del documento, nel quale è invitato a
inserire il nome da associare al file creato e la cartella nella quale inserirlo. Anche
in questo caso, come nel servizio dei bookmark se la cartella non esiste viene
creata automaticamente dall’applicativo. Come mostrato in Figura 4.16, nella
stessa finestra è riportata un’anteprima del documento creato e il riepilogo delle
condivisioni effettuate.
L’editor di testo può essere utilizzato anche per richiamare documenti già salvati in
precedenza o condivisi da altri utenti. Per far questo l’utente deve cliccare sul
pulsante “Apri Documento” mostrato in alto a sinistra in Figura 4.13. Nella finestra
che appare sono riportate tutte le cartelle create dall’utente e contenenti i file
costruiti attraverso l’editor Web integrato in desktop@UniFe (si veda Figura 4.17).
Aprendo una cartella è possibile selezionare qualsiasi documento sia per essere
modificato attraverso l’uso dell’editor (cliccando direttamente sul titolo del file), sia
per essere cancellato dal proprio spazio (cliccando sulla x a fianco del titolo del
file).
Figura 4.16: Riepilogo pre-salvataggio
78
Università degli studi di Ferrara
Figura 4.17: Finestra “Apri File”
I file condivisi possono essere aperti nell’editor di testo solo se l’utente proprietario
del documento ha concesso i privilegi di scrittura sul proprio elaborato. In tal caso
potranno essere apportate modifiche al testo, senza però poter alterare i privilegi
specificati dal possessore. Invece, se all’utente sono stati concessi solo i privilegi di
lettura, esso potrà semplicemente visualizzare il contenuto senza poter applicare
cambiamenti (si valuti le differenze di visualizzazione in Figura 4.18).
Figura 4.18: Visualizzazione di file condivisi
79
Università degli studi di Ferrara
La diversità dei permessi associati è visualizzabile dall’icona a fianco del titolo del
documento; in riferimento alla Figura 4.17 si veda ad esempio il file “bookmark” in
sola lettura rispetto ai file “mail” e “feed” con privilegi di scrittura.
Per tutti i file condivisi la cancellazione del documento può avvenire solo da parte
del proprietario, anche se coloro che hanno privilegi sull’elaborato hanno la
possibilità di cancellare la propria condivisione associata al documento (cliccando
sulla x a fianco del titolo del file in condivisione).
4.7 Il filesystem remoto
Il file system è un meccanismo con il quale i file sono immagazzinati e organizzati
su un dispositivo di archiviazione. Abitualmente si tende ad associare tale termine a
componenti come hard disk o CD-ROM. Più precisamente, un file system è
l'insieme dei tipi di dati astratti necessari per la memorizzazione, l'organizzazione
gerarchica, la manipolazione, la navigazione, l'accesso e la lettura dei dati.
All’interno del Web operating system si è inserito un applicativo di questo tipo, con
l’intento di consentire agli utenti di mantenere i propri file in una locazione remota,
accessibile da qualsiasi punto della rete. Tali dati saranno perciò usufruibili in ogni
momento.
La finestra di gestione di tale servizio è rappresentata in Figura 4.19. Essa è
caratterizzata da alcuni moduli: quello più in alto riguarda la barra delle funzionalità
utilizzabili per la gestione dei file; subito sotto si trova l’elenco di tutti i tag specificati
(rappresentati come delle cartelle per consentire una miglior comprensione
all’utente); infine si ha l’elenco dei file uplodati. Tali file sono visualizzati dentro dei
moduli, inizialmente collassati.
80
Università degli studi di Ferrara
Figura 4.19: Il filesystem
Il cuore del filesystem è legato all’operazione di upload dei file. Ad essa si può
accedere attraverso il link “Upload File”. In Figura 4.20 è rappresentato il modulo
che appare. Esso consente di selezionare un file in locale attraverso la ricerca sul
proprio disco. Inoltre è richiesto l’inserimento di almeno un tag da associarvi (anche
più di uno), in modo da riuscire a creare un albero di “cartelle” nelle quali
memorizzare i dati inviati. A discrezione dell’utente è possibile inserire anche una
brevissima descrizione del documento, da usarsi come promemoria per la sua
spiegazione.
Figura 4.20: Il form di upload
81
Università degli studi di Ferrara
Per garantire la sicurezza del server remoto si è deciso di controllare la natura del
file subito prima del suo invio: tutti i file eseguibili o contenenti codice pericoloso
sono perciò bloccati e non uplodabili come anche tutti i file di dimensioni superiori ai
7 Mb.
Un’altra funzionalità implementata è quella legata alla ricerca di documenti secondo
parametri immessi dall’utente. Cliccando su “Trova File” si può immettere una
parola da ricercare all’interno dei titoli o delle descrizioni associate. Tale
esplorazione visualizza a video tutti i file soddisfacenti la condizione. Se ad
esempio immettessimo la parola “tesi” in un filesystem come quello mostrato in
Figura 4.19 si avrebbe come risultato della ricerca un elenco come quello mostrato
in Figura 4.21, con i file divisi a seconda che la parola sia stata trovata nel nome
del file o nella sua descrizione.
Figura 4.21: Risultati della ricerca
Cliccando sui nomi delle cartelle si accede a tutti i file aventi tra i tag anche quello
selezionato. Per gestire i dati, invece, è necessario utilizzare direttamente i moduli,
nei quali sono presenti i riferimenti a tutti i file insieme ad alcune opzioni per la loro
82
Università degli studi di Ferrara
gestione. Per avere un piccolo resoconto delle caratteristiche fondamentali dei dati
è possibile espandere il modulo (vedi Figura 4.22) in modo che vengano
visualizzate informazioni come la dimensione del file o la data dell’upload, una
breve descrizione o i tag associati.
Su ciascun file è possibile compiere tre tipi di operazioni: la cancellazione
attraverso il click su “Elimina”, la modifica dei dati associati (quindi descrizione e
nomi dei tag) usando il link “Modifica” e il download in locale del file. Quest’ultima
operazione non cancella il file remoto ma ne invia una copia all’utente.
All’interno del filesystem si è voluto integrare anche la gestione dei file di testo
creati con l’editor integrato nel Web operating system. Perciò cliccando su
“Documenti dell’Editor” si accede a tutti i propri elaborati, potendo compiere su di
essi le stesse operazioni effettuabili su qualsiasi altro tipo di file (download in
formato .doc e cancellazione).
Figura 4.22: Il modulo dei file
83
Università degli studi di Ferrara
4.8 La ricerca nel Web
All’interno del Web desktop si è integrato il motore di ricerca “Google”, riconosciuto
come il più grande e affidabile tra i motori di ricerca, occupandosi dell'80% di tutte
le ricerche effettuate su internet attraverso il suo sito. L’accesso a tale servizio può
essere effettuato o dal menù a tendina o direttamente attraverso l’icona visualizzata
sulla scrivania. Tale operazione fa apparire un semplice campo di testo come
quello mostrato in Figura 4.23 nel quale inserire il parametro (o i parametri) per la
ricerca.
Essa avviene in maniera totalmente asincrona e i risultati vengono mostrati
secondo il formato tipico di google, con il titolo in primo piano e una breve
anticipazione del contenuto a seguire. Unico vincolo del servizio è la
visualizzazione di massimo 8 risultati. Un link alla fine degli otto item porta
direttamente al sito di google nel quale sono visualizzati i restanti.
Figura 4.23: Il modulo dei file
4.9 Help
Nonostante una delle caratteristiche del servizio sia la semplicità di utilizzo, come
ormai ribadito numerose volte in questa tesi, è stato necessario inserire ugualmente
la possibilità di consultare una guida, definita col nome “Help”.
Cliccando su di essa si apre una finestra nella quale sono riportate tutte le
indicazioni per un buon utilizzo del Web operating system. Essa, infatti, contiene
84
Università degli studi di Ferrara
spiegazioni utili per una facile navigazione o per un uso corretto delle varie
funzionalità offerte. A seconda del servizio utilizzato, il click del mouse fa apparire
informazioni contestuali riguardo ciò che si sta utilizzando. Ad esempio il click su
“Help” mentre si utilizza l’editor di testo farà apparire un documento appositamente
redatto per chiarire il suo uso (si veda la Figura 4.24).
Tutte le funzionalità descritte hanno come filo conduttore quello di essere gestite in
maniera totalmente asincrona, quindi senza la necessità di ricaricare ogni volta la
pagina. In questo modo anche l’impressione lasciata all’utente è quella di utilizzare
un applicativo residente in locale, nel quale i tempi di attesa per le risposte del
server sono mascherati dagli aggiornamenti
in background effettuati dal Web
operating system.
Figura 4.24: L’help del Web desktop
85
Università degli studi di Ferrara
86
Università degli studi di Ferrara
Capitolo 5: IMPLEMENTAZIONE DI DESKTOP@UNIFE
La struttura del Web operating system si fonda sulle caratteristiche fondamentali
delle applicazioni Web sviluppate con il framework Rails. Perciò alla definizione
della struttura generale del Desktop (finestre di gestione dei servizi e creazione
delle funzionalità base dell’applicativo) è seguita una fase di creazione e gestione di
vari servizi, secondo il modello tipico Model-View-Controller adottato da RoR (Ruby
on Rails).
In particolar modo si è partiti dall’analisi dei casi d’uso di alto livello (use case),
definendo a grandi linee il flusso di consultazione delle funzionalità Web gestite dal
servizio e cercando di determinare i dati richiesti dall’applicazione per lo sviluppo
del database, lasciando la possibilità di estendere in futuro le potenzialità del Web
desktop con nuovi servizi.
Il progetto infatti è caratterizzato da un uso considerevole di informazioni,
necessariamente memorizzate all’interno di una base di dati. Proprio per questo
scopo è stato creato il database “myportal”, nel quale sono state inserite 16 tabelle,
ognuna delle quali con una funzione particolare.
5.1 Casi d’uso
Un caso d’uso definisce il modo in cui un sistema viene utilizzato da una
determinata entità. Nel caso di desktop@UniFe si è pensato di sviluppare
l’applicativo facendo riferimento ad un ipotetico sistema operativo locale utilizzato
da un utente per aprire programmi quali editor di testo o filesystem. Per compiere
tali operazioni, l’utente utilizzerebbe il menu di avvio posto alla base sinistra della
sua pagina o un’icona all’interno della propria scrivania. Inoltre, potendo aprire più
programmi contemporaneamente, l’utente si aspetta di trovare all’interno della
87
Università degli studi di Ferrara
propria barra degli strumenti un segnalibro che indichi quali ha aperto. Si è cercato
di riprodurre tali funzionalità anche all’interno dell’applicativo sviluppato, facendo
attenzione a mantenere un buon grado di usabilità di tutto il sistema.
A parte queste caratteristiche generali di gestione delle pagine e del loro
collegamento, risulta pressoché impossibile determinare a priori un ipotetico flusso
di navigazione dei servizi, visto che l’accesso a uno rispetto a un altro dipende
dall’esigenza dell’utente. Perciò si può semplicemente abbozzare uno schema di
massima come quello mostrato in Figura 5.1 che descrive le possibili scelte
effettuate da un utente nella fruizione del desktop.
Figura 5.1: Possibili scelte dell’utente
88
Università degli studi di Ferrara
Come si può notare, l’apertura di un servizio rispetto ad un altro è del tutto
indifferente, in quanto la modularità del sistema consente una gestione
indipendente di ciascun servizio. L’architettura del sistema ha perciò tenuto conto di
questa caratteristica: si è creato un controller dedicato per ciascun servizio
integrato all’interno del desktop, riuscendo a separare i flussi di gestione delle
funzionalità a livello architetturale. Se ad esempio si pensa ad una ipotetica
sessione di lavoro di un utente, si può prevedere che mentre sta creando un testo
all’interno dell’editor, i suoi moduli di mail o di feed vengano aggiornati in maniera
asincrona in contemporanea. Tali operazioni vengono gestite separatamente dai
controllori dedicati ai vari servizi.
5.2 I dati
Per realizzare il database con cui si sono immagazzinate le scelte e le preferenze
dell’utente, ci si è basati su un database MySql, un database management system
(DBMS) relazionale. Una volta modellato, ci si è preoccupati di portarlo in terza
forma normale per evitare tutte le problematiche legate ad anomalie di inserimento,
cancellazione e aggiornamento, quindi per garantire l’integrità e la correttezza dei
dati in esso archiviati.
La struttura di “myportal” (è il nome del database) segue uno schema Entity –
Relationship, in grado di mettere in luce sia le tabelle presenti all’interno del DB
insieme ai loro attributi, che le relazioni che intercorrono tra esse.
Si è scelto di utilizzare 16 tabelle, suddividendo in questo modo in locazioni diverse
i dati utilizzati da servizi differenti.
Di seguito è riportato lo schema generale della struttura del database (vedi Figura
5.2), corredata dagli attributi di ciascuna tabella e dalle relazioni logiche instaurate
tra di esse. Inoltre in ciascuna tabella è riportata anche la chiave primaria
(evidenziata dalla sigla PK) e quella importata dalla tabella con cui è stata creata la
relazione (indicata da FK1).
89
Università degli studi di Ferrara
Figura 5.2: Schema del database “myportal”
90
Università degli studi di Ferrara
5.2.1 Entità e attributi
Come mostra la Figura 5.2 il database costruito è caratterizzato da 11 tabelle
associate all’utente e alle scelte da lui effettuate e da 5 tabelle completamente
scollegate da esso. Questa scelta è legata al fatto che tutti i contenuti visualizzati
nel desktop risiedono in DB, anche quelli di default, cioè uguali per tutti gli utenti
fruitori dell’applicativo.
Un’altra particolarità è legata ai nomi associati alle tabelle. Essi sono tutti al plurale
(si noti la s finale) e iniziano con la lettera minuscola. Tale convenzione è stata
adottata per consentire a Rails di far comunicare il modello associato a ciascuna
tabella (caratterizzato dallo stesso nome al singolare) all’entità corrispondente. Ad
esempio alla tabella users è associata la classe User nel modello, a filesystems la
classe Filesystem e così via.
Di seguito è riportata una breve lista di tutte le tabelle costruite, riferite al contesto
nel quale vengono usate ed interrogate.
Figura 5.3
1. DATI DI SETTAGGIO DEL DESKTOP:
a. Entità users: raccoglie i dati relativi alle preferenze dell’utente, dal
tema del sito (contenuto nell’attributo stile), alla disposizione delle
icone sul desktop (attributo disposIcone)
91
Università degli studi di Ferrara
b. Entità icons: al suo interno sono mantenute tutte le icone inserite
personalmente dall’utente, ciascuna delle quali associata ad un nome,
a un url a cui fare riferimento e a un’immagine da visualizzare sulla
scrivania.
c. Entità icondefaults: in essa sono mantenute tutte le icone che si è
deciso di lasciare di default per tutti gli utenti. Tali icone consentono
ad esempio di aprire i vari servizi sviluppati all’interno dell’applicativo
(aggregatore di feed, gestore di mail, editor di testo…) o di collegarsi
direttamente ad alcuni servizi pubblicati dall’Ateneo ma non integrati
nel desktop (registrazione agli esami). E’ caratterizzata dagli stessi
attributi della tabella icons.
Figura 5.4
2. DATI RELATIVI ALL’HELP DI desktop@UniFe:
a. Entità helps: contiene tutti gli help associati all’applicativo, ciascuno
legato ad uno dei servizi implementati all’interno del Web operating
system. I record puntano a dei file html nei quali sono state
memorizzate tutte le informazioni a riguardo dell’utilizzo del desktop e
la soluzione a possibili inconvenienti causati da un uso non
appropriato delle funzionalità in esso contenute.
92
Università degli studi di Ferrara
Figura 5.5
3. DATI RELATIVI ALL’AGGREGATORE DI FEED:
a. Entità feeds: questa tabella tiene traccia delle preferenze legate alla
visualizzazione dei moduli RSS o ATOM registrati dall’utente. Perciò
vi è un solo record legato a ciascun user, caratterizzato dal numero di
colonne per la visualizzazione dei feed e dall’indicazione relativa
all’attivazione del servizio.
b. Entità moduls: raccoglie tutti i riferimenti ai feed registrati dall’utente.
Ciascun utente può registrarne un numero a suo piacimento. Il record
legato a tale modulo è contraddistinto da attributi legati al reperimento
dei contenuti da visualizzare. Perciò vi è l’url del feed dal quale
l’applicativo preleva il documento xml con le informazioni (attributo
url_link), il numero di articoli da visualizzare (n_item), il tempo ogni
quanto aggiornare il modulo (min_refresh). Inoltre sono stati inseriti
alcuni campi riferiti alla visualizzazione grafica del modulo, che può
presentarsi aperto, visualizzando i titoli degli articoli (collassato=0), o
ridotto ad icona (collassato=1), in una colonna rispetto ad un’altra.
c. Entità tagfeeds: l’aggregatore di feed consente di inserire RSS o
ATOM specificati direttamente dall’utente attraverso l’inserimento
dell’indirizzo corretto al quale reperire le informazioni. Si è però voluto
creare un elenco di possibili siti sorgenti che pubblicano feed (ad
93
Università degli studi di Ferrara
esempio ANSA, PUNTOINFORMATICO, HTML.IT). I riferimenti a tali
feed sono contenuti in questa tabella, contenente record non legati ad
alcun utente, ma inseriti dall’aggregatore in una finestra di supporto
all’inserimento di contenuti.
Figura 5.6
4. DATI RELATIVI AL GESTORE DI MAIL:
a. Entità mails: si può utilizzare il Web operating system per gestire
contemporaneamente fino a quattro account di posta. Questo è
possibile attraverso la memorizzazione in questa tabella dei parametri
di connessione ai Server di posta ospitanti tali caselle. Perciò dopo
aver inserito il login (attributo referenzeUser) e la password
(referenzePassword) vengono memorizzate in DB anche l’indirizzo
del Server al quale reperire le mail (imap_pop) e la porta alla quale
connettersi (porta). I restanti attributi specificano le preferenze
grafiche e di gestione legate alla visualizzazione del modulo relativo
all’account. Dal tempo di aggiornamento delle mail (refresh) al
numero di istanze visualizzate (numItem) fino alla specifica del nome
94
Università degli studi di Ferrara
da associare alla casella di posta (nomeCartella). Si è scelto di
limitare a 4 il numero max di account registrabili per non
sovraccaricare la comunicazione tra client e server durante gli
aggiornamenti dei moduli.
b. Entità imaps: raccoglie tutti i parametri legati ai server di posta più
comunemente usati. Infatti si presume che non tutti gli utenti
conoscano i parametri di configurazione per scaricare la posta. Perciò
si sono inseriti tali dati all’interno di questa tabella, consentendo
all’utente di richiamare automaticamente un record attraverso la
specifica del dominio delle proprie mail.
Figura 5.7
5. DATI RELATIVI ALL’EDITOR DI TESTO:
a. Entità editors: questa tabella contiene tutti i file di testo redatti e
salvati dall’utente tramite il servizio di editing di testi inserito
nell’applicativo. Ovviamente gli attributi di tale tabella si riferiscono al
file creato: nome del file (salvato nell’attributo Titolo), cartella nella
quale inserire tale file (cartella), orario dell’ultima modifica apportata
(Orario). Si è deciso di salvare tutto il contenuto del documento
all’interno del database, nel campo Testo, caratterizzato da un
95
Università degli studi di Ferrara
dominio di tipo blob, che consente la memorizzazione di dati sia
testuali che legati ad immagini. L’ultimo attributo della tabella è legato
al numero di persone con le quali l’utente ha deciso di condividere il
file, con una cardinalità max di 4.
b. Entità utilizzators: i record in essa contenuti sono legati ai file
memorizzati all’interno di editors. Infatti se si è deciso di condividere il
documento, in questa entità sono memorizzati i numeri di matricola
delle persone scelte e i privilegi ad esse associati (scrittLet).
Figura 5.8
6. DATI RELATIVI AL GESTORE DI BOOKMARK:
a. Entità bookmarks: tutto il servizio legato al tagging dei siti è gestito da
questa tabella. Essa non contiene alcun tipo di informazione legata ai
contenuti visualizzati dal servizio; vi sono invece inserite le credenziali
dell’utente per la connessione al sito di del.icio.us (loginMark e
passwordMark) che gestisce effettivamente e concretamente tutta
l’operazione di etichettatura dei siti Web. Gli altri tre attributi presenti
consentono di specificare il numero di istanze di tag e di siti di volta in
volta visualizzati dai moduli presenti all’interno della finestra di
gestione dei bookmark.
96
Università degli studi di Ferrara
Figura 5.9
7. DATI RELATIVI AL FILESYSTEM:
a. Entità filesystems: tale tabella è il fulcro di tutto il servizio legato alla
gestione dei file uplodati sul server dall’utente. Infatti in essa sono
contenute tutte le caratteristiche di ciascuno di essi: il nome del file
(nomeFile), la sua dimensione (fileSize), la tipologia del file uplodato
(tipoFile, ad esempio tipo testo, tipo immagine, tipo archivio), una
brevissima descrizione inserita dall’utente per spiegare il file
(descFile) e la data di upload del file (dataFile) per riuscire a tenere
una cronologia degli upload eseguiti.
b. Entità tagsfilesystems: tale tabella contiene i record per eseguire
l’associazione molti a molti tra filesystems e alltags. I record vengono
97
Università degli studi di Ferrara
inseriti automaticamente dall’applicativo ogni volta che si associa un
tag ad un file.
c. Entità alltags: ogni utente può associare a ciascun file uplodato una
serie di tag da lui scelti. I nome di questi marcatori vengono tenuti
memorizzati in questa tabella nell’attributo name e il numero di file
referenziato da ciascun tag è inserito nel campo Occorrenze. Infatti
ogni tag può essere associato a più file contemporaneamente, anche
di utenti diversi.
d. Entità fileTemps: questa tabella è stata costruita per essere utilizzata
come base d’appoggio nell’operazione di download dei file dal Server
al Client. Infatti ogni qual volta un utente decide di scaricare il file in
locale, il record correlato viene automaticamente inserito in questa
tabella, per poi essere cancellato non appena l’operazione è stata
conclusa. Da notare che gli attributi che la contraddistinguono sono gli
stessi della tabella filesystems contenente i riferimenti a tutti i file
uplodati.
5.3 Organizzazione Rails di “myportal”
Come si spiegava in fase di presentazione del capitolo, il Web operating system è
stato sviluppato secondo l’organizzazione tipica delle applicazioni Rails. Perciò
l’analisi della struttura di programmazione del Web desktop risente di tale
meccanismo.
In particolare la struttura è come quella visualizzata in Figura 5.10. La cartella App
è il centro di tutta l’organizzazione in quanto in essa è contenuto il codice
specializzato per l'applicazione Web. All'interno di essa esistono 4 sottodirectory,
ovvero controllers, models, views e helpers, contenenti ciascuna i file specializzati
ad un particolare ambito dell’applicazione. L’altra directory fondamentale per la
creazione del Web desktop è Public, nella quale sono state inseriti i file Javascript,
Css e immagini utilizzati nel sito.
98
Università degli studi di Ferrara
Figura 5.10: Organizzazione Rails dell’applicazione
Le restanti cartelle all’interno di myportal contengono informazioni di configurazione
dell’applicazione (come la directory config) o istruzioni per la connessione al
database (cartella db). Si hanno pure repository contenenti i plug-in utilizzati o gli
script su cui ci si è appoggiati per lo sviluppo delle parti client (cartelle vendor,
components e script). Infine Rails offre gli strumenti per il controllo del
99
Università degli studi di Ferrara
funzionamento del sito, gestibili attraverso l’uso dei log e dei file di test creati
automaticamente dall’applicazione.
5.3.1 I controller
Il cuore delle applicazioni sviluppate con Ruby on Rails sono i controller, cioè i
componenti a cui è affidato il compito di gestire a livello Server le richieste giunte
dai Client e di elaborare una risposta dipendente dai parametri ricevuti. Per
esempio come mostrato in Figura 5.11, quando proviene una richiesta da
http://unife.it/ajaxportal/Rssfeed/viewfeed/8, Rails esegue alcune operazioni:
•
Carica il file feed_controller.rb e istanzia un oggetto della classe
FeedController.
•
Chiama il metodo viewfeed() della stessa classe e a lui passa il parametro 8.
•
Il metodo interroga il modello corrispondente alla gestione dei feed e
restituisce i dettagli relativi a quello che ha identificato con il parametro
ricevuto.
•
Infine invia una risposta al Client.
Figura 5.11: Url di richiesta
100
Università degli studi di Ferrara
A riguardo dell’operazione di response, esistono tre modi per farla. Il metodo più
comune consiste nel visualizzare un template. Secondo il paradigma MVC, il
template è una vista che prende le informazioni fornite dal controller e se ne serve
per produrre una risposta per il browser. Un altro metodo è quello legato alla
restituzione di una stringa direttamente al browser, senza richiamare una vista.
Questo meccanismo è stato utilizzato soprattutto per inviare notifiche di errore o per
attivare alcune funzioni Javascript attraverso la modifica di parametri. Infine l’ultimo
metodo consiste nell’inviare al client dati diversi dal codice HTML. Quest’ultima
operazione è stata di notevole importanza soprattutto nelle operazioni di download
di file utilizzate dal servizio di filesystem.
Un controller risponde sempre all’utente una richiesta alla volta. Da ciò discende
che per riuscire a gestire in maniera pseudo-contemporanea tutti i servizi
implementati o integrati nel Web operating system si sono sviluppati lo stesso
numero di controller:
•
Ajaxportal_controller: è il file principale di tutta l’applicazione. Al suo interno
sono gestiti tutti gli eventi legati alla parte di autenticazione al Web desktop,
all’uso della home (perciò tutte le azioni riguardanti le icone, la modifica del
tema e la visualizzazione degli help) e al motore di ricerca google integrato.
•
Rssfeed_controller: in questo file sono presenti tutte le azioni legate
all’aggregatore di feed; dalla gestione delle colonne nelle quali sono
visualizzati gli RSS alla configurazione dei singoli moduli. In esso si trovano
anche tutte le funzioni di collegamento con il model “feed”, al quale è
demandata tutta la parte di dialogo con il database ed in particolare con le
tabelle interessate.
•
User_mail_controller: questo controller, oltre ad avere le azioni di risposta
alle richieste inviate attraverso il servizio di mail integrato, offre numerose
funzionalità di dialogo con i principali provider di posta. Infatti tutta la parte
legata allo scaricamento delle mail dai Server di posta viene effettuata al suo
interno attraverso funzioni appositamente create. Sono presenti anche
alcune funzioni per l’interrogazione al model “mail”, incaricato ai dati relativi
agli account registrati.
101
Università degli studi di Ferrara
•
Editor_controller: questo file si occupa principalmente di gestire il salvataggio
e il successivo reperimento dei documenti creati e modificati con l’editor.
Infatti tutta la parte legata alla loro creazione è gestita in locale attraverso le
funzioni Javascript. Vi sono anche numerose funzioni per la gestione della
condivisione degli elaborati. Proprio per questo si interfaccia con i model
“editor” e “utilizzator”, aventi le azioni per gestire i dati relativi a tali
operazioni.
•
Bookmark_controller: si occupa di mantenere il Web operating system
collegato al server di del.icio.us, dal quale reperisce tutte le informazioni
legate ai bookmark registrati. Il suo collegamento con il model “bookmark”
serve principalmente per ricevere ad ogni accesso le credenziali dell’utente
per l’autenticazione al servizio. Sono presenti anche alcune funzionalità
legate alla gestione dei tag e dei siti elencati.
•
Filesystem_controller: questo file risulta essere quello più ricco di
funzionalità. Infatti in esso sono gestiti un numero molto ampio di eventi
legati ai file salvati in remoto: upload, modifica, download, cancellazione
ricerca attraverso parametri immessi dall’utente sono solo alcuni esempi di
azioni controllate. Inoltre sono state costruite alcune procedure per
l’interfacciamento con il controller legato all’editor, per consentire l’uso anche
dei file da esso creati. Infine sono presenti anche alcune funzioni per
interfacciarsi al model “filesystem”, nel quale sono presenti le istruzioni di
interrogazione al DB.
5.3.2 Le viste
Le viste contengono al loro interno le pagine HTML effettivamente visualizzate
dall’utente sul proprio browser. Sono state divise a seconda del servizio a cui fanno
riferimento, perciò a ciascuna di esse è associato un controller particolare, avente
al suo interno le funzionalità per rispondere alle request implementate dalla pagina.
102
Università degli studi di Ferrara
La maggior parte di esse sono state create come template, consentendo in questo
modo di essere utilizzate per aggiornare solamente parti della pagina visualizzata.
Per comprendere meglio la modalità di funzionamento utilizzata per gestire questi
oggetti si possono analizzare i template da tre punti di vista: posizione, ambiente di
funzionamento e contenuto.
Per riuscire a richiamare un template è stata utilizzata l’istruzione:
render(:partial => ‘nometamplate’)
Essa consente di richiamare qualsiasi file visualizzandolo all’interno dell’elemento
desiderato.
Ovviamente
questo
tipo
di
gestione
consente
di
modificare
dinamicamente il contenuto a seconda dei template che di volta in volta si va a
richiamare. Essi infatti contengono una combinazione di testo fisso (in formato
HTML) e di codice Ruby, quest’ultimo utilizzato per aggiungere contenuti dinamici.
Il codice viene eseguito in un ambiente che gli consente di accedere alle
informazioni impostate dal controller. Tutti i file sono contenuti all’interno della
cartella “view” mostrata in Figura 5.10, divisi in sottodirectory aventi lo stesso nome
del controllore a cui fanno riferimento.
A parte la specificità delle istruzioni legate a ciascun servizio contenute nelle
singole pagine, la vera novità contenuta all’interno dei template risiede nelle
funzioni Ruby utilizzate al loro interno per implementare le chiamate AJAX.
Innanzitutto, Rails offre le librerie JavaScript native per il prototipo, gli effetti, il drug
& drop e i controlli. Queste consentono di eseguire ogni sorta di manipolazione
AJAX e DOM secondo l’approccio orientato agli oggetti.
La sintassi di una chiamata AJAX di base da un template è descritta in Figura 5.12.
Figura 5.12: Url di richiesta
103
Università degli studi di Ferrara
La forma standard del metodo link_to_remote() accetta tre parametri:
•
Il testo del collegamento;
•
L’attributo id= dell’elemento da aggiornare nella pagina;
•
L’URL di un’azione da chiamare all’interno di un controller.
Quando l’utente fa click sul collegamento, l’azione (viewfeed, in questo caso) viene
invocata sul Server. Qualsiasi elemento l’azione restituisca sarà utilizzato in
sostituzione del contenuto dell’elemento mydiv nella pagina corrente. La vista che
genera la risposta non dovrà utilizzare alcun wrapper di layout Rails, dal momento
che l’aggiornamento interessa soltanto una parte della pagina HTML.
Dal momento che la funzione Ruby utilizzata non è altro che un modo per generare
codice HTML, si può analizzare quello che è accaduto durante l’esecuzione
dell’esempio. Il testo generato è rappresentato in Figura 5.13.
Figura 5.13: Codice HTML generato
Il metodo link_to_remote genera un tag HTML <a> che, al click dell’utente, produce
una nuova istanza di Ajax.Updater; quest’ultimo viene definito nella libreria
JavaScript
Prototipe
inclusa
dalla
vista.
Internamente,
l’istanza
chiama
XMLHttpRequest, che a sua volta genera una richiesta POST http all’URL fornito
come secondo parametro. Lo stesso processo si può analizzare visualizzando cosa
avviene sul Server (vedi Figura 5.14).
Figura 5.14: Istruzione Server legata alla chiamata AJAX
104
Università degli studi di Ferrara
Il Server Web ha ricevuto una richiesta POST HTTP per eseguire una chiamata a
/ajaxportal/Rssfeed/viewfeed. Dal punto di vista del Server, si tratta di un
normalissima chiamata HTTP. Egli restituisce quindi l’output dell’azione chiamata
(viewfeed(), in questo caso) all’oggetto XMLHttpRequest creato nel frattempo da
link_to_remote(), e l’istanza di Ajax.Updater prende il sopravvento, sostituendo il
contenuto dell’elemento passato come primo parametro (mydiv) con i dati restituiti
dall’oggetto XMLHttpRequest; Il browser a questo punto aggiorna la pagina per
visualizzare il nuovo contenuto. Per quanto riguarda l’utente, dunque, tutto il
processo si traduce in un banale aggiornamento asincrono della pagina.
Ovviamente la funzione link_to_remote non è l’unica utilizzabile per costruire
chiamate AJAX. Infatti ne esistono altre tre, utilizzabili a seconda del contesto in cui
ci si trova ad operare:
•
E’ possibile modificare qualsiasi modulo per utilizzare AJAX, sostituendo la
chiamata a form_tag() con form_remote_tag(). Questo metodo serializza tutti
gli elementi del modulo e li invia al Server, utilizzando come al solito
XMLHttpRequest. Si può vedere un esempio della funzione mostrato in
Figura 5.15.
Figura 5.15: Form_remote_tag
•
Un altro metodo utilizzato all’interno del Web operating system per costruire
chiamate
AJAX
è
l’uso
degli
observer.
Essi
utilizzano
l’oggetto
105
Università degli studi di Ferrara
XMLHttpRequest ogni qual volta l’utente modifica i dati di un modulo, oppure
in uno specifico campo.
Figura 5.16: Funzione observe_field
L’observer rimane in attesa di eventuali cambiamenti a un determinato
campo (search in questo caso), verificando la presenza di queste modifiche
ogni xx secondi (xx è il valore definito in :frequency).
•
L’ultima
funzione
di
supporto
sfruttata
all’interno
dell’applicativo,
periodically_call_remote(), è utile se si vuole aggiornare periodicamente una
parte della pagina tramite una chiamata AJAX al Server. I parametri passati
alla funzione sono molto simili a quelli di observe_field (si veda Figura 5.17).
Figura 5.17: Funzione periodically_call_remote
Poiché Ajax lavora in background, risulta perfettamente trasparente all’utente: il
servizio può ricevere una richiesta AJAX senza che l’utente sia informato su ciò che
sta avvenendo. Il browser, infatti non segnala neppure il caricamento della pagina.
Ad esempio si provi ad immaginare l’azione di click di un utente su un pulsante per
cancellare un file dal proprio filesystem e che tale pulsante invii una richiesta al
106
Università degli studi di Ferrara
Server: senza retroazione, l’utente non può sapere che cosa accade. Si tenga
presente che l’utente-tipo, quando non vede l’effetto di un’azione, spesso torna a
fare click, più volte, sul pulsante. Perciò si è deciso di inserire accanto a tutte le
operazioni lato Server scatenate direttamente dall’utente (perciò non riguardano
operazioni come ad esempio l’aggiornamento in backgrount degli account di posta)
un elemento di feedback, in modo che l’utente risulta visivamente informato che
qualcosa è in corso di esecuzione. Tali feedback sono identificabili con le barre di
attesa, immagini animate che consentono di comunicare all’utente l’imminente
conclusione dell’azione richiamata. Si veda un esempio di tali barre in Figura 5.18.
Figura 5.18: Barre d’attesa
5.3.3 Gli script e i file CSS
Alla base dell’iterazione tra l’utente e il Web operating system vi è un motore
JavaScript che ha anche il compito di fare da intermediario tra il browser e il Server
Web. Quando ci si connette inizialmente al Server, la prima cosa che viene
effettivamente scaricata è un frame, invisibile all’utente, contenente il motore in
questione, con la logica lato client del Web dektop.
Tale logica è stata sviluppata all’interno di alcuni file JavaScript di cui il principale è
“myscript.js”. In esso si ritrovano tutte le funzioni e le classi per la gestione dei
principali eventi scatenati dall’utente con il mouse. E’ responsabile della gestione di
tutte le parti dinamiche del sito, riuscendo a gestire anche le funzionalità avanzate
come il drug&drop degli oggetti e la costruzione di documenti attraverso l’uso
dell’editor di testo. Infatti ogni funzionalità lato Server è stata gestita prima di tutto a
107
Università degli studi di Ferrara
livello Client, in modo da dare all’utente l’impressione di una risposta immediata da
remoto. Ad esempio lo spostamento delle icone sulla scrivania avviene grazie ad
una funzione JavaScript denominata “Druggable”, che offre visivamente una
modifica immediata della disposizione degli oggetti. In background, il Web
operating system costruisce la chiamata AJAX per modificare i dati relativi in DB.
Quest’ultima operazione ovviamente può richiedere un tempo variabile, dipendente
soprattutto dalla velocità di connessione dell’utente. Tale limitazione comunque è
completamente nascosta grazie all’uso dello script lato Client.
Tutta la presentazione grafica del Web desktop è demandata ai file CSS costruiti e
mantenuti memorizzati nella cartella “Stilesheet” all’interno della directory “public”
(si veda Figura 5.10). Tali file si occupano di gestire tutta la rappresentazione
dell’applicativo,
consentendo
di
mantenere
separati
il
codice
dalla
sua
presentazione. Al sito è associato un documento CSS denominato “myAJAXportal”,
nel quale sono presenti tutte le classi degli elementi visualizzati nel Web operating
system, corredati dalla definizione delle proprietà principali (altezza, larghezza,
margini…).
Per consentire la personalizzazione del tema del sito sono stati costruiti altri quattro
file, ciascuno dei quali ridefinisce solamente gli attributi relativi al colore degli
oggetti. Modificando il tema del sito attraverso il campo di selezione appropriato, si
compie uno switch tra i file, andando a ridefinire solamente le proprietà color e
background-color. Tale procedimento è spiegato in Figura 5.19.
Figura 5.19: File CSS associati all’applicativo
108
Università degli studi di Ferrara
Come si può vedere dalla figura il file CSS caricato inizialmente dal desktop
dipende dalla natura del browser utilizzato dall’utente. Tale soluzione è stata
adottata per ovviare ai problemi legati alle visualizzazioni differenti che i motori di
render compiono in presenza di stesse proprietà. Se infatti si pensa ai due browser
più diffusi in commercio (Internet Explorer e Mozilla), ci si accorge come essi
interpretino in maniera totalmente differente definizioni di larghezza e altezza degli
elementi DOM visualizzati. La conseguenza della scelta effettuata è la completa
compatibilità con entrambi i browser, consentendo in tal modo l’uso completo delle
funzionalità del Web operating system.
5.4 L’accessibilità dell’applicativo
L'accessibilità, in informatica, è la capacità di un dispositivo, di un servizio o di una
risorsa d'essere fruibile con facilità da una qualsiasi categoria d'utente,
indipendentemente dal contesto in cui opera o dalla tecnologia di cui dispone.
Il termine è comunemente associato alla possibilità anche per persone con ridotta o
impedita capacità sensoriale, motoria, o psichica, di fruire dei sistemi informatici e
delle risorse software a disposizione.
Il Web operating system è stato sviluppato facendo riferimento alle disposizioni
inserite nel documento del 1999 del WAI (Web Accessibility Iniziative) e della legge
4/2004, la così detta “Legge Stanca”, rispettando la correttezza della semantica del
codice utilizzato per lo sviluppo e utilizzando tecniche di programmazione atte a
garantire tale aspetto. Ad esempio non sono stati utilizzati né frame né tabelle.
Vista però la natura del progetto e la tecnologia Ajax utilizzata si è fatto largo uso di
XmlHttpRequest e del linguaggio client-side Javascript, impedendo altresì a coloro
aventi browser con disabilitati tali oggetti di non poter usufruire appieno dei servizi
implementati.
109
Università degli studi di Ferrara
Si è fatto uso di codice HTML, JAVASCRIPT, CSS e RUBY semanticamente
corretto. Inoltre si è provveduto a corredare qualsiasi tipo di oggetto multimediale
della proprietà alt, garantendo in tal modo, qualora non sia possibile visualizzare le
immagini, la loro sostituzione con una descrizione e dando la possibilità a software
quali screen reader di leggere il contenuto e tradurlo a persone con deficit
sensoriali.
Prevedendo l’uso del desktop anche con dispositivi differenti dai Personal
Computer o comunque da sistemi operativi con risoluzioni differenti, si è costruita
tutta
la
struttura
basandosi
su
dimensionamenti
fluidi,
dipendenti
dalle
caratteristiche video dell’utente. Perciò nella specifica delle dimensioni o delle
posizioni degli oggetti sono sempre state utilizzate le percentuali rispetto a unità di
misura come i pixel. Inoltre non potendo prevedere possibili utilizzi futuri
dell’applicativo, lo si è sviluppato utilizzando proprietà grafiche definite standard dal
W3C
e
utilizzando
come
riferimento
il
tutorial
pubblicato
all’indirizzo
“http://www.w3schools.com/css/”.
Ovviamente ci si è concentrati anche sul rendere il Web operating system il più
efficiente e chiaro possibile, unendo alla semplicità d’uso, la chiarezza
comunicativa, nonché la velocità ed efficacia nella navigazione e consultazione dei
contenuti. Si è cercato di raggiungere tali caratteristiche costruendo un applicativo il
più simile possibile agli strumenti abitualmente utilizzati dagli utenti in ambienti
locali, come ad esempio i sistemi operativi, così da annullare tutta la parte di
apprendimento e di conoscenza che abitualmente accompagna l’approccio ad un
nuovo applicativo e consentendo all’utente di avere subito gli strumenti per poter
utilizzare il Web desktop al pieno delle sue potenzialità.
110
Università degli studi di Ferrara
Capitolo 6: Conclusioni
Se da un lato il Web operating system è certamente un’innovazione tecnica
importante, contenente una filosofia nuova di approccio al Web e metodologie di
programmazione basate aggiornamenti Web asincroni, rivoluzionarie rispetto agli
standard precedenti, dall’altro, dal punto di vista dell’utente finale, che utilizza
l’applicativo in maniera totalmente staccata dalle logiche implementative, gli aspetti
interessanti sono di natura differente.
Il sistema operativo è di per sé paradossale: è l’elemento vitale del PC senza il
quale gli applicativi non potrebbero nemmeno essere installati, ed è al contempo il
software che più di ogni altro impegna le risorse del computer. Questo Web
desktop sgonfia tale paradosso. Infatti esso sfruttando la sua natura di applicazione
remota consente di continuare ad accedere alle stesse identiche funzionalità
semplicemente sfruttando la connessione internet. Il risultato è che l’utente si trova
ad avere a disposizione una “scatola vuota”, un PC alleggerito che fungerà
unicamente da terminale. Non sarà più necessario, ogni due o tre release di un
sistema operativo, acquistare un nuovo PC o controllare ogni volta i requisiti minimi
di sistema, mai sufficientemente adeguati ai software di ultima generazione.
Ovviamente le funzionalità implementate per questo prototipo sono abbastanza
limitate, avendo integrato solamente sei o sette servizi. Si è comunque creato un
applicativo estendibile con nuove funzionalità, grazie all’architettura modulare del
sistema, aperta e flessibile, per consentire il potenziamento di desktop@UniFe.
Il Web operating system è stato completamente progettato pensando a chi lo
avrebbe utilizzato. Questo perché il suo successo dipende essenzialmente dalla
capacità di riuscire a trasmettere all’utente la sensazione di gestire in maniera
completa tutte le potenzialità offerte.
Lo scopo è stato raggiunto essenzialmente concentrando gran parte dello sviluppo
nella progettazione e nella realizzazione di numerosi elementi grafici. Il software,
111
Università degli studi di Ferrara
per la verità sarebbe stato ugualmente valido e accessibile se lo si fosse strutturato
utilizzando un’interfaccia meno legata alle immagini, tuttavia i servizi sarebbero stati
sfruttati solamente in modo parziale, nel caso il visitatore non fosse riuscito ad
entrare pienamente in possesso di tutti gli strumenti offerti.
Il design che è stato curato si sposa perfettamente con i concetti di usabilità e di
accessibilità, avendo sviluppato l’applicativo seguendo gli standard Web. La
conseguenza di quanto appena detto è che
il desktop è correttamente
visualizzabile da molti dei browser che supportano gli standard Web: fra questi
ricordiamo Internet Explorer (nelle versioni dalla 5.5 alla 7), Mozilla (nelle versioni
dalla 1. alla 2), Netscape 6 e 7.
La dimensione sociale e collaborativa del Web operating system aumenta
esponenzialmente i margini e la velocità di crescita di questi spazi virtuali,
fondamentali per migliorare l’utilizzo della rete anche da parte di coloro che
abitualmente non hanno familiarità con la creazione di applicazioni Web.
La nascita di questo progetto si inserisce in una ricerca da parte dell’Ateneo di
Ferrara di supportare in maniera sempre più consistente lo sviluppo di applicazioni
Web innovative, cercando di offrire ai propri utenti strumenti all’avanguardia.
Al prototipo mancano ancora alcune funzionalità importanti quali la composizione di
mail e il loro invio o la gestione di un servizio di agenda e di rubrica. Inoltre il
sistema di gestione dei contenuti adottato dall’Ateneo fornisce ulteriori servizi che
possono essere integrati (iscrizione alle liste d’esame o accesso ai vari siti dei corsi
di laurea).
Ovviamente sarà possibile aggregare anche la moltitudine di servizi che le software
house stanno pubblicando sul Web solo se tali funzionalità supporteranno
comunicazioni asincrone sulle quali tale prototipo è basato.
112
Università degli studi di Ferrara
BIBLIOGRAFIA
TESTI DI RIFERIMENTO:
“AJAX IN ACTION”
Dave Crane, Eric Pascarello
casa editrice MANNING PUBBLICATION, anno 2005
“SVILUPPARE APPLICAZIONI WEB CON RAILS”
Dave Thomas, David Heinemeier Hansson
casa editrice APOGEO, anno 2006
“JAVASCRIPT – LA GUIDA”, quarta edizione
Danny Goodman
casa editrice MC GRAW Hill, anno 2001
“ACCESSIBILITÁ: DALLA TEORIA ALLA REALTÁ”
Roberto Scano
casa editrice WEBSTANDARDS, anno 2004
113
Università degli studi di Ferrara
114
Università degli studi di Ferrara
WEBGRAFIA
WEB 2.0: siti Web di riferimento
− Articolo di Tim O’Really sul Web 2.0
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html
− Articolo sulle caratteristiche del Web 2.0
http://www.paulgraham.com/web20.html
− Documentazione e approfondimenti
http://en.wikipedia.org/wiki/Web_2
RUBY ON RAILS: siti Web di riferimento
− Manuale e download del framework:
http://www.rubyonrails.org
− Help del framework:
http://www.onlamp.com
− Documentazione e download dei plug-in:
http://rubygems.org
− Documentazione di riferimento alle API di Ruby on Rails:
http://api.rubyonrails.org
SERVER: siti Web di riferimento
− Server Apache:
www.apache.org
− Server Webrick:
http://www.webrick.org
115
Università degli studi di Ferrara
AJAX: siti Web di riferimento
− Articolo originale di colui che ha coniato il termine
http://www.adaptivepath.com/publications/essays/archives/000385.php
− Documentazione sui concetti di base
http://it.wikipedia.org/wiki/AJAX
− Introduzione alle caratteristiche di Ajax
http://www.antirez.com/articoli/spaghettiajax.html
− Guida completa in italiano
http://javascript.html.it/guide/leggi/95/guida-ajax
− Ajax Tutorial
http://www.xul.fr/en-xml-ajax.html
HTML e DOM: siti Web di riferimento
− Tutorial HTML:
http://www.w3schools.com/html
− Guida di riferimento:
http://www.html.it
− Reference al DOM:
http://www.w3.org/DOM
RUBY: siti Web di riferimento
− Documentazione di riferimento alle classi Ruby:
http://dev.rubycentral.com/ref
− Documentazione Ruby:
http://www.ruby-doc.org
− Guida di riferimento alla programmazione in Ruby:
http://www.ruby-lang.org/en
− Forum sui problemi di programmazione in Ruby;
http://www.ruby-forum.com
116
Università degli studi di Ferrara
JAVASCRIPT: siti Web di riferimento
− Tutorial Javascript:
http://www.w3schools.com/js
− Raccolta di script disponibili:
http://javascript.html.it/script/lista/20/contenuti-dinamici-e-ajax
− Guida di riferimento alla programmazione in Javascript:
http://www.javascript.com
CSS: siti Web di riferimento
− Tutorial CSS:
http://www.w3schools.com/css
− Guida di riferimento:
http://css.html.it
SQL: siti Web di riferimento
− Tutorial SQL:
http://www.w3schools.com/sql
− Guida di riferimento:
http://www.sql.org
STRUMENTI e PLUG-IN UTILIZZATI: siti Web di riferimento
− Prototype:
http://www.fabryprog.it/from_sergiopereira/prototype.js.html
− Scrpt.aculo.us:
http://wiki.script.aculo.us
− TinyMCE (editor di testo):
http://tinymce.moxiecode.com
117
Università degli studi di Ferrara
− Del.icio.us:
http://del.icio.us
− Google Ajax:
http://code.google.com/apis/ajaxsearch
NORME e LEGGI: siti Web di riferimento
− Legge “Stanca”:
http://www.pubbliaccesso.gov.it/normative/legge_20040109_n4.htm
− WAI (Web Accessibility Initiative) :
http://www.w3.org/WAI
− Manuale per l’accessibilità (sito CINECA):
http://www.cineca.it/gai/area/accessibilita.htm
118
Università degli studi di Ferrara
RINGRAZIAMENTI
Ringrazio innanzi tutto la mia Bonny per tutto il sostegno e l’affetto che mi ha
donato in questi anni.
La mia splendida e unica famiglia, che mi ha sostenuto e spronato nei momenti
difficili e ha gioito con me in quelli più felici; la mia mamma e il mio papà che hanno
sempre creduto in me e Chiara e Damiano per essermi stati accanto in ogni
momento.
I nonni per tutti i rosari detti in mio favore.
Tutti i miei cari amici scout, con cui ho affrontato mille avventure.
L’intero ufficio informatico, in particolare Luca, che mi hanno rasserenato durante il
lungo periodo di tirocinio e supportato nelle difficoltà.
Il mio relatore prof. Stefanelli, al quale devo molto soprattutto per l’aiuto e i consigli
a riguardo della stesura di questa tesi.
E un grazie va anche a tutte le persone che ho incontrato in questi anni e del quale
sarebbe troppo lungo fare un elenco. Ciascuna di esse ha rappresentato un punto
importante per la mia crescita.
119
