PROTOTIPO DI UN WEB OPERATING SYSTEM SVILUPPATO … · Tesi di Laurea di: MARGUTTI FRANCESCO...

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


3

a papà e mamma


4


5

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


6

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 L’accessibilità dell’applicativo ..................................................109


7

Capitolo 6: Conclusioni .................................................. 111

BIBLIOGRAFIA................................................................... 113

WEBGRAFIA ...................................................................... 115

RINGRAZIAMENTI ............................................................. 119


8


9

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


10

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


11

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.


12

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;


13

• 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.


14


15

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


16

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


17

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


18

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.


19

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


20

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:


21

• 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


22

• 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.


23

• 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


24

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.


25

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.


26

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


27

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.


28

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


29

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


30

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.


31

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.


32

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


33

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


34

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 di gestire la

comunicazione client-server tramite XMLHttpRequest.


35

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


36

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 interpretato dal client

E’ un linguaggio compilato e gestito

sul server, per poi essere eseguito sul

client.

E’ orientato agli oggetti. E’ possibile

definire una funzione per ogni evento

scatenato nel browser

E’ un linguaggio basato sulle classi.

Gli oggetti e le funzioni sono racchiusi

in esse e vengono usati attraverso

delle chiamate prestabilite. Non è un

linguaggio basato sugli eventi.

Il codice è contenuto all’interno delle

pagine HTML, fra i tag <script> e

</script>

Le Applet sono ben distinte dal codice

HTML.

Le variabili e le costanti non sono mai

dichiarate, e vengono assegnate in

maniera dinamica

Ad ogni variabile e ad ogni costante

deve essere assegnato un tipo.

Tabella 2.1: Confronto fra Javascript e Applet Java


37

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


38

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.


39

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/”.


40

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


41

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:


42

• 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


43

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


44

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


45

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


46

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


47

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


48

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


49

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


50

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.


51

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.


52

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.


53

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 (browser-

based);

• 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


54

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


55

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


56

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.


57

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


58

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


59

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


60

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:

• drag&drop;

• modifica del tema del desktop;

• apertura e chiusura di finestre;

• gestione dell’editor;

• resize di finestre;


61

• 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;


62

• 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,


63

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


64

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


65

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.


66

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):

• Aggregatore di Feed;

• Gestore di Mail;

• Filesystem remoto;

• Editor di Testo;

• Gestore di Bookmark;

• Ricerca di contenuti all’interno del Web.


67

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


68

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


69

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


70

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


71

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


72

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


73

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


74

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


75

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


76

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


77

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


78

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


79

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


80

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.


81

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


82

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


83

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


84

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


85

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


86


87

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


88

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


89

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).


90

Figura 5.2: Schema del database “myportal”


91

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)


92

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.


93

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


94

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


95

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


96

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.


97

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


98

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.


99

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


100

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


101

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.


102

• 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.


103

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


104

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


105

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


106

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


107

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


108

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


109

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.


110

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à.


111

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,


112

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.


113

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


114


115

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


116

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


117

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


http://css.html.it

SQL: siti Web di riferimento

− Tutorial SQL:

http://www.w3schools.com/sql


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


118

− 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


119

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.

PROTOTIPO DI UN WEB OPERATING SYSTEM SVILUPPATO … · Tesi di Laurea di: MARGUTTI FRANCESCO...

Documents

Transcript of PROTOTIPO DI UN WEB OPERATING SYSTEM SVILUPPATO … · Tesi di Laurea di: MARGUTTI FRANCESCO...