C:/Documents and Settings/robi ... - Tesi < Fabio's...

Indice

1 Introduzione 1

2 Modifica di contenuti ipertestuali 92.1 Gli obiettivi della ricerca . . . . . . . . . . . . . . . . 92.2 Il sistema ipertestuale . . . . . . . . . . . . . . . . . 10

2.2.1 L’idea originale del sistema ipertestuale . . . . 102.2.2 Sviluppo e limiti dei sistemi ipertestuali . . . 11

2.3 Esigenza di personalizzazione . . . . . . . . . . . . . 132.4 Soluzioni basate sull’ architettura proxy . . . . . . . 14

2.4.1 Vantaggi delle soluzioni proxy . . . . . . . . . 192.4.2 Svantaggi delle soluzioni proxy . . . . . . . . . 20

2.5 Soluzioni basate sull’ architettura client . . . . . . . . 212.5.1 Vantaggi delle soluzioni client . . . . . . . . . 272.5.2 Svantaggi delle soluzioni client . . . . . . . . . 27

2.6 Meccanismi di estensione del browser . . . . . . . . . 282.6.1 Toolbar: navigare, monitorare e conoscere i siti

Web . . . . . . . . . . . . . . . . . . . . . . . 282.7 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . 34

3 La sidebar ISAWiki 353.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . 353.2 Il progetto ISAWiki . . . . . . . . . . . . . . . . . . . 36

3.2.1 Content Management System . . . . . . . . . 363.2.2 Immediate Site Activator . . . . . . . . . . . . 383.2.3 Wiki Wiki Web . . . . . . . . . . . . . . . . . 403.2.4 ISAWiki . . . . . . . . . . . . . . . . . . . . . 41

3.3 Lo scopo del progetto . . . . . . . . . . . . . . . . . . 433.4 La sidebar ISAWiki: una soluzione client-side . . . . 443.5 Comunicazione con la finestra del browser . . . . . . 463.6 Comunicazione con l’editor . . . . . . . . . . . . . . . 47

3.6.1 Attivazione dell’editor . . . . . . . . . . . . . 483.6.2 Editazione di un nuovo documento . . . . . . 493.6.3 Editazione di una pagina Web . . . . . . . . . 49

iii

iv INDICE

3.6.4 Chiusura dell’editor . . . . . . . . . . . . . . . 513.7 Comunicazione con il server ISAWiki . . . . . . . . . 52

3.7.1 Richiesta di un nuovo documento . . . . . . . 533.7.2 Richiesta di un salvataggio . . . . . . . . . . . 543.7.3 Richiesta della lista delle versioni . . . . . . . 543.7.4 Richiesta di un particolare formato . . . . . . 553.7.5 Richiesta della pagina personalizzata . . . . . 56

3.8 Comunicazione con il server XLink . . . . . . . . . . 583.8.1 Creazione di una linkbase . . . . . . . . . . . 583.8.2 Cancellazione di una linkbase . . . . . . . . . 593.8.3 Creazione di un link . . . . . . . . . . . . . . 593.8.4 Salvataggio di un link . . . . . . . . . . . . . . 613.8.5 Inserimento di un link . . . . . . . . . . . . . 613.8.6 Editazione di un link . . . . . . . . . . . . . . 623.8.7 Rimozione di un link . . . . . . . . . . . . . . 63

3.9 Il framework . . . . . . . . . . . . . . . . . . . . . . . 63

4 Implementazione del progetto 654.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . 654.2 Architettura del sistema . . . . . . . . . . . . . . . . 654.3 Tecnologie utilizzate e requisiti per il funzionamento . 664.4 Configurazione del sistema . . . . . . . . . . . . . . . 67

4.4.1 Brevi accenni alla tecnologia COM . . . . . . 684.5 Realizzazione dell’oggetto Explorer Bar . . . . . . . . 704.6 Comunicazione con la finestra del browser . . . . . . 71

4.6.1 Oggetto IWebBrowser2 . . . . . . . . . . . . . 724.6.2 Meccanismo di callback . . . . . . . . . . . . . 724.6.3 Evento BeforeNavigate . . . . . . . . . . . . . 734.6.4 Evento DocumentComplete . . . . . . . . . . 74

4.7 Controlli della sidebar . . . . . . . . . . . . . . . . . 754.8 Comunicazione con l’editor . . . . . . . . . . . . . . . 77

4.8.1 Attivazione dell’editor . . . . . . . . . . . . . 774.8.2 Editazione di un documento del server ISAWiki 804.8.3 Editazione di un documento dell’origin server 804.8.4 Chiusura dell’editor . . . . . . . . . . . . . . . 814.8.5 Salvataggio di un documento . . . . . . . . . . 83

4.9 Comunicazione con il server ISAWiki . . . . . . . . . 844.9.1 Richiesta di un nuovo documento . . . . . . . 844.9.2 Richiesta di un salvataggio . . . . . . . . . . . 854.9.3 Richiesta della lista delle versioni . . . . . . . 874.9.4 Richiesta di un particolare formato . . . . . . 904.9.5 Richiesta della pagina personalizzata . . . . . 91

4.10 Comunicazione con il server XLink . . . . . . . . . . 92

INDICE v

4.10.1 Il server XLink . . . . . . . . . . . . . . . . . 924.10.2 Protocollo di comunicazione client-server XLink 934.10.3 Lista delle linkbase . . . . . . . . . . . . . . . 944.10.4 Creazione di una linkbase . . . . . . . . . . . 944.10.5 Cancellazione di una linkbase . . . . . . . . . 954.10.6 Definizione di un XPointer . . . . . . . . . . . 964.10.7 Creazione di un XLink . . . . . . . . . . . . . 984.10.8 Salvataggio di un XLink . . . . . . . . . . . . 1004.10.9 Inserimento di un XLink . . . . . . . . . . . . 1004.10.10Editazione di un XLink . . . . . . . . . . . . . 1024.10.11Rimozione di un XLink . . . . . . . . . . . . . 102

4.11 Limiti implementativi . . . . . . . . . . . . . . . . . . 103

5 Conclusioni e sviluppi futuri 105

Bibliografia 107

vi INDICE

Capitolo 1

Introduzione

Nella presente dissertazione si parlera della realizzazione di

un sistema volto ad offrire all’utente un ambiente di navigazione

personalizzato, in grado di rispondere alle sue specifiche esigenze.

In questo capitolo viene presentata l’area di riferimento del

lavoro svolto, evidenziando il suo carattere innovativo rispetto

agli altri sistemi gia sviluppati in merito e, pur entrando

nel vivo dell’argomento, vi saranno mostrati solo gli aspetti

salienti rimandando il lettore ai capitoli successivi per dettagli ed

approfondimenti.

Questa ricerca nasce dall’esigenza di colmare alcune delle carenze

dell’attuale modello ipertestuale del World Wide Web grazie

all’aggiunta di nuove funzionalita. Dal 1990, il World Wide Web

ha raggiunto molteplici e differenziati sviluppi, tuttavia non riesce

ancora a sfruttare tutte le enormi potenzialita del suo modello

base, ossia l’ipertesto. Il concetto e la definizione di ipertesto fu

introdotto da Ted Nelson, che ne parla come di un’“organizzazione

non sequenziale dell’informazione in analogia ai meccanismi cognitivi

dell’essere umano” [Nel65]; dunque, uno strumento mediante il quale

l’utente puo organizzare le proprie idee in modo da non dover

piu essere legato alla usuale struttura lineare del testo; dunque,

un approccio alla gestione delle informazioni in cui i contenuti

sono memorizzati all’interno di una rete di nodi che, mediante

opportuni collegamenti, possono far riferimento gli uni con gli altri.

Nelson ipotizzo che i sistemi ipertestuali avrebbero dovuto riflettere

1

2 CAPITOLO 1. INTRODUZIONE

l’“iperspazio” dei processi mentali dell’uomo.

Negli anni successivi, Nelson sviluppa lo studio del concetto

di ipertesto fino ad esaltarlo nel progetto Xanadu [Nel87], nel

quale propone il sistema ipertestuale come un unico, grande

deposito informativo in cui tutti gli utenti potevano aggiungere

materiale, correggere documenti altrui, aggiungere note e commenti,

organizzare, collezionare e pubblicare qualunque frammento

memorizzato nel sistema. Ogni utente poteva eseguire tali operazioni

contemporaneamente ad altri e senza violare i diritti degli autori

originali, grazie ad un complesso e completo meccanismo di

memorizzazione, indirizzamento e gestione dei permessi. Percio

Xanadu, oltre ad essere un sistema “ipertestuale”, era soprattutto

un sistema di “produzione ipertestuale collaborativa e pluralistica”.

Il World Wide Web ha realizzato molti degli aspetti dell’originaria

visione di Nelson diventando, in tempi sorprendentemente brevi, la

piu visibile manifestazione di un potente mezzo di comunicazione

la cui caretteristica piu importante e la “democraticita”. Ogni

giorno il Web raggiunge un numero sempre maggiore di utenti e

questo grazie anche alla sua semplice architettura e all’adozione di

standard che hanno reso possibile la diffusione di una cosı vasta

quantita di informazioni. Tuttavia proprio l’espansione e la mole di

nozioni che il World Wide Web fornisce ne hanno minato l’ulteriore

evoluzione facendo sı che restasse, per certi aspetti, un passo indietro

rispetto ad altri studi nell’ambito degli ipertesti. In particolare, i

browser pre-Web prevedevano sia un maggiore supporto per editor

per la modifica del contenuto dei documenti, sia un meccanismo

della gestione di collegamenti ipertestuali piu flessibile. Dunque,

World Wide Web e sı oggi un potente mezzo di comunicazione, ma la

vasta quantita d’informazione che vi passa attraverso spesso rischia

di disorientare i lettori richiedendo loro un grande sforzo cognitivo.

Inoltre, gli utenti spesso non riescono ad avere accesso ad una cosı

vasta quantita di informazione e finiscono col diventare dei “lettori

passivi”. Infatti, i moderni browser Web sono ancora caratterizzati

da una separazione troppo rigida tra il ruolo dei lettori e quello

degli autori. I lettori, solitamente, hanno a disposizione numerosi e

3

semplici tool per seguire i percorsi di lettura indicati esplicitamente

dagli autori ma non possono creare nuovi contenuti, link, o versioni

personalizzate delle pagine Web. Gli autori invece, benche abbiano

tutte le facolta per poter compiere queste operazioni di modifica sui

documenti, spesso hanno bisogno di conoscere ed avere a disposizione

un vasto numero di tecnologie e tool per potere creare delle pagine

soddisfacenti.

Molti sistemi sono stati sviluppati con l’obiettivo di trasformare gli

utenti in “lettori attivi”. Alcuni offrono un ambiente per la creazione

di link dinamici in un sistema collaborativo. Altri permettono

semplicemente la condivisione e lo scambio di informazioni o sistemi

per la generazione di annotazioni sulle pagine. Altri ancora,

come mailing-list, newsgroup, shared access ed interactive pages,

permettono meccanismi piu o meno complessi per la condivisione

di risorse, attraverso l’utilizzo di editor testuali. Tutti questi sistemi

sono volti ad offrire all’utente degli strumenti per poter accedere ai

contenuti e modificare le pagine, per soddisfare le proprie necessita,

ma nessuno di essi e stato ancora in grado di dar vita ad un sistema

ipertestuale completo. Ancora oggi la concezione di Nelson nel

progetto Xanadu resta dunque un influente esempio del modello su

cui un sistema ipertestuale dovrebbe basarsi.

L’obiettivo centrale di questo lavoro e quello di offrire all’utente

un sistema ipertestuale in grado di far fronte a molteplici esigenze

quali aggiungere parti all’ipertesto, personalizzarne il contenuto,

collegare e modificare il lavoro anche scritto da altri. Nel corso di

questa dissertazione viene dimostrato come sia possibile arricchire

di nuove funzionalita l’attuale sistema ipertestuale senza il bisogno

di rivoluzionare completamente l’architettura su cui si basa il

Web, ma semplicemente mediante l’utilizzo di tecnologie client-side.

In particolare, e stata realizzata un’estensione dell’interfaccia piu

ampiamente utilizzata, ovvero il browser. Il browser svolge un

ruolo centrale per l’interazione dell’utente con il Web durante la

navigazione, pertanto, per tenere vivo questo rapporto, e necessario

permettere all’utente di costruire un ambiente personalizzato secondo


le proprie necessita.

Il sistema realizzato nel corso di questa tesi e nato come sviluppo

del progetto ISAWiki [DV04] e si e poi evoluto con l’aggiunta di

altre funzionalita. ISAWiki e un progetto ideato da un team di

varie persone, presso il dipartimento di Informatica dell’Universita

di Bologna e ancora in via di sviluppo. ISAWiki nasce dalla

fusione di ISA [Vit03] e della filosofia dei wiki [Cun02]. ISA e

un’applicazione server-side che permette ad un utente di produrre

pagine Web complesse senza possedere alcuna conoscenza tecnica

particolare. La grande innovazione di ISA e quella di consentire la

generazione di contenuti e modelli grafici utilizzando software molti

diffusi e di semplice utilizzo. ISAWiki estende le funzionalita di ISA

integrando in esso le caratteristiche dei CMS ovvero le funzionalita

necessarie per l’automazione dei processi di creazione, revisione,

controllo, composizione e pubblicazione dei documenti. Vengono

inoltre implementate le funzionalita tipiche dei sistemi wiki. I wiki

sono strumenti collaborativi che permettono, tramite l’utilizzo dei

browser maggiormente diffusi, di visualizzare ed editare i documenti

in maniera semplice facendo uso di un linguaggio di markup molto

intuitivo. In tale sistema, pero, l’aspetto grafico non ha importanza

e viene quindi privilegiato il contenuto. ISAWiki eredita tutte le

caratteristiche piu significative e l’approccio innovativo di entrambe

le categorie proponendosi come strumento collaborativo che permette

la condivisione di documenti attraverso il Web e allo stesso tempo la

creazione di siti anche complessi.

Inizialmente il progetto ISAWiki si era sviluppato solamente come

applicazione server-side e offriva all’utente alcuni servizi quali

la memorizzazione dei documenti mediante un meccanismo di

versionamento, la conversione di un documento in diversi formati,

possibilita di associare ad un documento layout diversi, il supporto

per l’editazione dei documenti tramite modifica del codice HTML

o wiki della pagina, la ricerca di particolari pattern di testo nei

documenti memorizzati, la configurazione e il setup utente.

La mancanza di un’interfaccia client pero impediva all’utente di

5

poter sfruttare pienamente tutte le potenzialita del server. Inoltre

era necessario anche arricchire il sistema di alcune funzionalita per

rendere la fase di creazione e di modifica dei documenti ancora piu

semplice per l’utente.

“customization is modifying a web site to suit the

needs of an individual user; customization necessitates

creating a large number of versions of the web site - one

for each user..” [EP00]

Il contributo offerto dal seguente lavoro, all’interno del progetto

ISAWiki, consiste nella realizzazione di un’interfaccia client tramite

la quale l’utente puo utilizzare oltre a tutti i servizi che il sistema

ISAWiki offre, anche altri servizi. Essa e rappresentata da una

sidebar, ovvero un’area di visualizzazione di alcune informazioni

all’interno del browser, che permette ad un utente di assumere un

ruolo di partecipante “attivo” durante la navigazione.

Tramite la sidebar e possibile visualizzare la lista di tutte le versioni

dei documenti presenti sul server e accedere ad ognuna di queste.

Inoltre, la sidebar effettua un meccanismo di monitoraggio sulla

navigazione dell’utente, mediante il quale l’utente, ogni volta che

richiede un documento tramite URL, nel caso in cui esistano delle

versioni personalizzate di questo documento oltre a quello presente

sull’origin server, viene sempre aggiornato con la versione piu recente

(a meno che non venga richiesta una versione particolare). La sidebar

permette anche di attivare una serie di funzionalita realizzate da

altri membri del progetto ISAWiki: tra queste, la piu importante

e quella di ospitare al suo interno un editor mediante il quale

l’utente puo creare e modificare in modo veloce il contenuto di una

pagina Web, direttamente dal browser. Rispetto all’editor testuale

offerto dal server, l’editor presente nella sidebar e in grado di editare

il documento in maniera strutturata, accedendo direttamente alla

risorsa (in place) e senza necessita di conoscere il codice HTML

della pagina. Dal momento che, durante lo sviluppo del progetto


ISAWiki, si e ritenuto non interessante per l’utente modificare l’intera

pagina (i siti professionali sono composti da troppe strutture ed

elementi che rendono il codice complicato anche per una persona

esperta), e stato necessario realizzare uno strumento apposito per

l’analisi e la valutazione degli elementi in essa presenti. La sidebar

utilizza questo strumento per identificare le aree con il reale contenuto

del documento; successivamente rende editabili queste parti ed

attiva l’editor solo su queste zone. Tramite la sidebar e inoltre

possibile pubblicare sul Web i propri documenti, siano essi nuovi

o documenti personalizzati tramite l’editor, poter rivisualizzare le

pagine personalizzate ad una successiva richiesta dello stesso URL e

condividere le pagine personalizzate tra piu utenti.

Per mezzo di questa interfaccia viene fornita la funzionalita

aggiuntiva, rispetto ai servizi offerti solo lato server, di poter

modificare le proprieta delle versioni intermedie, quali la rinomina e

il cambio dei permessi in lettura e scrittura, eliminando la necessita

di creare una nuova versione ed essere obbligati a ridefinirli.

Inoltre dalla sidebar e possibile gestire delle linkbase esterne che

permettono la memorizzazione di informazioni ipertestuali da inserire

in fase di visualizzazione sul documento.

Queste funzionalita rendono il Web un ambiente di editing

collaborativo. Le informazioni aggiunte possono essere condivise,

pubblicate, navigate in maniera sincrona ed asincrona.

La sidebar e stata realizzata grazie ad un’applicazione scritta in C++

e ad un insieme di script Javascript.

I capitoli successivi sono organizzati nel modo seguente:

Nel capitolo 2 saranno discussi in modo approfondito i limiti del

World Wide Web dal punto di vista delle funzionalita ipertestuali, le

varie forme di personalizzazione finora sviluppate e le tecniche sulle

quali si sono basate.

Nel capitolo 3 saranno descritte le funzionalita della sidebar, le scelte

progettuali ed il funzionamento generale del sistema.

Nel capitolo 4 saranno analizzati i dettagli implementativi relativi

alla realizzazione del progetto.

7

Nel capitolo 5 sara riesaminato il lavoro svolto e si delineera una

traccia per migliorare ed ampliare il framework realizzato.

Capitolo 2

Modifica di contenutiipertestuali

Uno degli obiettivi del World Wide Web e fare in modo che

tutti gli utenti abbiano accesso ad un vasto numero di informazioni.

Grazie all’infinita di pagine, il Web potrebbe apparire come il

luogo dove trovare informazioni riguardo ogni argomento. In realta,

anche se navigare il Web e semplice, non sempre l’utente riesce

a trovare cio di cui ha bisogno in una cosı vasta quantita di

informazioni. Molto tempo viene inutilmente speso nel tentativo

di cercare l’informazione desiderata e spesso ci si vede costretti ad

uscire dalle ricerche senza aver ottenuto risultati significativi. E

ampiamente riconosciuto [BMK97] che se l’utente potesse accedere

ad una versione personalizzata del Web, le sue attivita sarebbero

compiute in maniera piu semplice e piu veloce.

2.1 Gli obiettivi della ricerca

Un sistema ipertestuale completo deve permettere al lettore non

solo di navigare secondo le proprie esigenze e gusti ma anche di

aggiungere parti all’ipertesto, di personalizzarne il contenuto, di

commentare, migliorare, collegare e modificare anche il contenuto

scritto da altri. Tutto questo deve ovviamente avvenire senza violare

nessun permesso di scrittura o lettura, visto che chiunque dovrebbe

avere la possibilita di modificare qualunque pagina dell’ipertesto.

L’organizzazione impersonale dell’informazione sul Web ha alcune

9

10 CAPITOLO 2. MODIFICA DI CONTENUTI IPERTESTUALI

conseguenze negative per gli utenti, di conseguenza semplici

agenti possono lavorare insieme per produrre nuove funzionalita

e intelligentemente ed automaticamente personalizzare il Web con

l’obiettivo di estendere l’attuale modello usufruendo dell’enorme

espressivita e delle capacita del sistema ipertestuale. Personalizzare

il Web significa aggiungere nuove funzionalita all’ambiente di

navigazione al fine di migliorare l’ordinaria interazione dell’utente

con il Web.

2.2 Il sistema ipertestuale

Prima di analizzare le caratteristiche del sistema ipertestuale e

necessario approfondire il concetto di ipertesto. L’ipertesto e visto

come un’organizzazione non sequenziale dell’informazione, suddivisa

in nodi di concetto e collegamento tra gli stessi. Il modello

ipertestuale e stato ideato infatti per rendere la lettura e la scrittura

piu vicina ai meccanismi cognitivi propri dell’essere umano: ogni

nostro pensiero e composto da elementi semplici, nodi di informazioni

che messi in relazione tra di loro realizzano significati anche molto

complessi. Il modello ipertestuale trova pero nel mezzo cartaceo

un ostacolo per la sua completa realizzazione, invece il formato

elettronico sembra essere lo strumento piu adatto in grado di dare vita

ad una completa gestione ipertestuale delle informazioni. L’ipertesto,

visto generalmente come un bene utile al sapere individuale perche

crea un modello di gestione dell’informazione vicino ai processi

mentali dell’uomo, non fornisce vantaggi solo dal punto di vista

del singolo, ma, collocandolo all’interno di un ambiente informativo

condiviso, costituisce uno strumento in grado di ampliare le capacita

umane nel campo della gestione collaborativa dell’informazione.

2.2.1 L’idea originale del sistema ipertestuale

I “pionieri dell’ipertesto”, Bush(1945) [Bus45], Nelson (1965)

[Nel65] e Engelbart(1984) [Eng84], avevano visto nei sistemi

ipertestuali un potente mezzo per l’apprendimento individuale, uno

2.2. IL SISTEMA IPERTESTUALE 11

strumento per facilitare il lavoro collaborativo, un sistema per

condividere il proprio sapere al fine di sviluppare un’“intelligenza

collettiva”. Quando Nelson introdusse i due termini “hypertext”

e “hypermedia” la sua idea era quella di realizzare un universo

informativo, il docuverso, nel quale potesse trovare posto tutta

la produzione informativa umana; una rete mondiale, che potesse

essere utilizzata da centinaia di milioni di utenti simultaneamente,

costituita dagli insiemi degli scritti, delle immagini, dei dati

conservati in tutto il mondo. Nel 1987, Ted Nelson progetto Xanadu,

il sistema che avrebbe dovuto gestire la rete, permettendo di sfruttare

completamente il potere del sistema ipertestuale per reperire in

maniera facile ogni documento. Il progetto era basato sull’idea di

una comunita di utenti in grado di condividere risorse, interagire,

modificare le informazioni condivise (anche collegandole tra loro) e

pubblicarle (memorizzandole) in archivi ad accesso pubblico.

Il World Wide Web fu inizialmente sviluppato per essere un potente

mezzo ipertestuale, condivisibile e scrivibile.

2.2.2 Sviluppo e limiti dei sistemi ipertestuali

Nel 1972, in piena guerra fredda, si inizio a definire una rete

militare denominata DARPA che si sarebbe trasformata in pochi

anni in Internet e alla quale nel 1987 sarebbe stato collegato anche

il CERN (Laboratorio Europeo per lo Studio della Fisica delle

Particelle). Fu proprio presso il CERN che Tim Berners-Lee, insieme

a Robert Cailliau, propose uno strumento per la divulgazione e la

catalogazione in rete dei documenti scientifici. Il primo prototipo

del progetto di Berners-Lee che prese vita nel 1990 era costituito da

un insieme di server, in grado di memorizzare i documenti, e da un

browser in grado di visualizzarli, con la particolarita di comprendere

un potente meccanismo di editing costruito sul browser stesso. In

questo modo tutti gli utenti potevano, oltre che leggere, anche

pubblicare le pagine Web. Cosı fin dall’inizio il Web era un mezzo

completamente collaborativo. Tuttavia il primo browser di Tim

Berners-Lee non era portabile su piu piattaforme tanto che presto


nacque la necessita di trasformarlo in uno strumento che permettesse

di accedere ai documenti solo in lettura. Nel 1993, il NCSA Mosaic

“read only” divenne presto la predominante interfaccia del Web,

e formo le basi dei moderni browser Web. Mosaic fu prodotto

originariamente per ambienti X-Windows e successivamente fu reso

compatibile anche per altre piattaforme. Un browser universalmente

compatibile condusse ad una crescita esponenziale dell’informazione

on-line in modo tale da rendere il Web la piu visibile manifestazione

di un nuovo mezzo: l’ipertesto globale.

Dalla meta degli anni novanta, molti sforzi sono stati compiuti nel

tentativo di dare nuovamente all’utente la possibilita di modificare

direttamente le pagine dal browser, ma senza ottenere degli

effettivi risultati. L’utilizzo dell’infrastruttura standard del Web

(client-server), inducendo a creare materiale fuori dall’ambiente del

Web e a pubblicarlo solo successivamente su un server, non solo

associa all’informazione disponibile sul Web la caratteristica di essere

“read-only”, ma delle volte rende lungo e arduo il processo di

creazione di contenuti per il Web, per un utente non troppo esperto.

Ancora oggi resta considerevole il numero di applicazioni il cui ciclo

di vita sarebbe piu semplice se questo fosse supportato interamente

da un ambiente ipermediale.

I correnti browser Web forniscono un limitato supporto per

personalizzare il Web. La ricerca nell’ambito dei sistemi ipertestuali

ha portato a definire una serie di problemi, sia dal punto di

vista del modello sia dal punto di vista delle funzionalita, che

compromettono la funzionalita del World Wide Web. Esistono

alcuni aspetti che impediscono di rendere il Web un vero sistema

ipertestuale completo come: la mancanza di browser che permettano

la modifica e la pubblicazione del documento, la carenza di sistemi

che permettano la raccolta delle informazioni ipertestuali riguardo

il documento, la scarsa evoluzione dei meccanismi di linking. Uno

dei punti deboli del Web e indubbiamente il modello di linking,

per cui il W3C ha proposto uno standard per far evolvere tale

modello. Lo standard XLink [DMO01] definisce un meccanismo

che utilizza sintassi XML (Extensible Markup Language) [BPS04]

2.3. ESIGENZA DI PERSONALIZZAZIONE 13

per definire link ipertestuali tra documenti XML. Tramite XLink

e possibile definire sia collegamenti ipertestuali interni che esterni.

Inoltre sono previsti link bidirezionali, link che collegano un numero

arbitrario di risorse ed e possibile definire un ruolo semantico delle

varie componenti. Tuttavia, sebbene il linguaggio XLink standard

sia potente e completo il supporto nei correnti browser e ancora

incompleto, dal momento che essi sono in grado solo di visualizzare

link HTML.

2.3 Esigenza di personalizzazione

Nasce l’esigenza di fare in modo che l’utente utilizzi il Web non

solo per avere accesso ad una grande quantita di informazioni ma

anche per pubblicare i propri documenti, per gestire i propri dati e

le proprie informazioni.

Si avverte [CHM03] dunque la necessita di provvedere un’ambiente

di manipolazione di contenuti integrato con il browser che abbia i

seguenti requisiti:

• Writable Web: gli utenti dovrebbero avere la possibilita sia

di aggiungere dei nuovi contenuti, delle annotazioni e dei

commenti alle pagine Web sia di condividere le informazioni;

dovrebbero diventare dei “lettori attivi”;

• Information Foraging : gli utenti dovrebbero avere la possibilita

di poter raccogliere e collezionare le informazioni per

poterle facilmente riutilizzare sfruttando tutti i benefici della

condivisione;

• Linkable Web: gli utenti dovrebbero avere la possibilita

di collegare le informazioni presenti all’interno delle pagine

secondo le proprie esigenze per poter avere un accesso piu veloce

ai contenuti di cui hanno bisogno.

In letteratura sono state effettuate molte ricerche per rendere

l’esperienza con il Web personalizzata e per sviluppare dei sistemi

di collaborazione delle risorse.


Molti sistemi usano meccanismi di filtro delle informazioni per

tenere traccia della storia della navigazione dell’utente allo scopo di

riconoscerne le abitudini: ripetute selezioni degli stessi link, tempo

speso su una particolare pagina, numero di accessi ad una specifica

informazione. Tutte queste informazioni vengono poi rielaborate allo

scopo di ottenere un utile modello basato sulle attuali interazioni

dell’utente con il Web durante la sua navigazione.

Questi sistemi possono essere chiamati anche “Web augumentation

tools” [Bou99] e possono essere classificati in base alle tecnologie

utilizzate per la modifica delle pagine e al metodo di integrazione

con il browser (parte del Web browser, plug-in, proxy, Web

server), in base al livello di collaborazione supportata (personale,

condivisibile, asincrona, sincrona), in base alle necessita di sistemi di

memorizzazione esterna (nessuna, locale, remota).

Vediamo di seguito alcuni di questi sistemi che si sono basati su

un’architettura di tipo proxy per raggiungere i loro obiettivi.

2.4 Soluzioni basate sull’ architettura

proxy

Il proxy e “un programma intermediario che agisce tanto come

un server quanto come un client al fine di soddisfare delle richieste

nell’interesse di altri client” [BFF99]. Il proxy si comporta come

un normale client che richiede il documento al server che possiede

l’informazione (origin server), elabora la richiesta in locale e si

collega come un client con un server (non necessariamente l’origin

server) o altro ancora, a seconda delle funzionalita che si sono volute

implementare nel proxy. Una volta stabilita la risposta, il proxy si

occupa di rinviarla al client che l’aveva richiesta.

In letteratura esistono molti sistemi che permettono un intervento

personale dell’utente sulle risorse esterne del World Wide Web

tramite l’utilizzo di un server proxy, che si occupa di modificare i

documenti e mandarli al client al posto di quelle originali. Di seguito

sono presentati alcuni di questi sistemi ritenuti interessanti ai fini di

questa ricerca.

2.4. SOLUZIONI BASATE SULL’ ARCHITETTURA PROXY 15

Aquarelle

Il progetto europeo Aquarelle [Riz97] aveva lo scopo di fornire dei

meccanismi di accesso al particolare tipo di informazione utilizzata

per descrivere il patrimonio culturale europeo, che include pitture,

sculture, siti storici, monumenti e strumenti musicali. Esistono due

tipi di tale informazione: “primary data” e “secondary data”. Il

primo tipo indica l’informazione fornita dai musei, gallerie d’arte,

ed altre organizzazioni culturali che registrano i dettagli delle loro

collezioni. Il secondo e piuttosto un’informazione specialistica

riguardo le collezioni. I dati primari vengono memorizzati su

degli “archive servers” ed i dati secondari vengono memorizzati

su delle “structured folders”; queste ultime contengono riferimenti

agli item sugli archivi dei server e alle altre folder relative.

Aquarelle provvede un’accesso all’informazione mediante “querying”

e “hypertext navigation”. Il sistema permette all’utente di avere

accesso all’informazione, lo assiste nella formulazione delle query di

ricerca, gli suggerisce gli archivi piu rilevanti, comunica le query al

server e gli restituisce infine le corrette informazioni. I link vengono

gestiti con lo scopo di mantenere l’integrita delle informazioni tra le

folder del server e gli archivi, senza incorrere in problemi di “dangling

link”. Il cuore del sistema Aquarelle consiste nel proveddere una

connessione tra gli user client, gli “archive servers” e le “structured

folders”. Aquarelle si basa su un sistema di link server distribuito.

CritLink

Il sistema CritLink [Pin97], implementato da Ka Ping Yee, e un

proxy universale, grazie al quale ogni utente della rete puo aggiungere

annotazioni a qualunque pagina della rete stessa. La gestione delle

annotazioni avviene mediante un sistema di memorizzazione esterna.

Le pagine originali, infatti, sono caricate da qualunque server Web;

il proxy, in seconda fase, arricchisce tali pagine con i commenti degli

utenti registrati restituendo al browser la pagina arrichita con le

informazioni aggiunte.


Goate

Goate [AM02] e un proxy che supporta XLink e permette

l’inserimento di link ad alto livello all’interno di documenti HTML,

dando la possibilita di visualizzare tali link tramite browser. Tutti i

documenti richiesti passano attraverso il proxy che ha il compito di

alterare il documento e renderlo compatibile con il linguaggio HTML,

interpretabile dal browser. Goate mostra come possa essere utilizzata

una relazione unidirezionale tra le risorse per un piu complesso

sistema di linking. Lo scopo di Goate e quello di portare un sistema di

linking ad un alto livello di compatibilita con tutti i browser tramite

una semplice soluzione proxy. Se il ruolo del proxy fosse svolto dal

server si rischierebbe di avere un sistema dipendente dal server Web,

similmente se fosse svolto dal client. Sebbene l’iniziale scopo fosse

quello di estendere i browser con il supporto di XLink, il progetto

voleva poi andare oltre e si proiettava verso lo studio di possibili

implementazioni per l’inserimento di XLink anche in altri linguaggi,

come il C o il Java.

Microcosm

Il sistema Microcosm [DFH92], sviluppato presso l’Universita di

Southampton agli inizi degli anni novanta, offre gia la funzionalita

di creare collegamenti ipertestuali tra informazioni gestite da

applicazioni esterne al sistema stesso. Il sistema puo essere visto

come un ambiente a “ombrello” che permette all’utente di creare

link ipertestuali da un documento, aperto da un’applicazione, verso

un documento aperto in un’altra e, vista la sua flessibilita, e

stato utilizzato in diversi campi, da quello educativo a quello

di gestione di archivi di grandi dimensioni. Microcosm consiste

in una serie di processi autonomi che comunicano tra loro

mediante scambio di messaggi: le informazioni sui collegamenti sono

memorizzate esternamente alle risorse in appositi database (linkbase)

che mantengono informazioni riguardo all’ancora di partenza (se

presente) e a quella di destinazione, piu una serie di informazioni utili

per la descrizione del collegamento. Questo sistema e particolarmente


interessante dato che permette di avere dei diversi set di link per

la stessa risorsa, e di definire collegamenti memorizzati su supporti

read-only come CD-Rom e video disc. I link vengono riapplicati ad

ogni richiesta ed esiste un ben definito meccanismo di paternita delle

singole modifiche. Tale caratteristica, derivata da Xanadu, mira ad

unificare il processo di lettura e di personalizzazione di documenti

ipertestuali.

Open HyperMedia Protocol

Open HyperMedia Protocol [MMD00] e un meccanismo che

permette di esprimere link in maniera indipendente dal dominio

di appartenenza delle risorse. Il framework e definito FOHM,

Fundamental Open Hypertext Model, e propone un modello comune

di dati ed un’insieme di operazioni applicabili a tutti i domini. Tenere

le informazioni riguardanti i link separate dal documento permette

di definire strutture di linking molto potenti e anche multidirezionali.

FOHM estrapola la struttura degli ipertesti appartenenti a differenti

domini ipertestuali (“navigational”, “spatial”, “taxonomic”), senza il

bisogno di utilizzare applicazioni esterne aggiuntive per interpretare

la struttura del link. Il sistema, riconducendosi sempre allo stabilito

range di domini, e gia in grado di riconoscere alcune importanti

proprieta del link. Alternativamente vengono definiti nuovi domini,

sufficientemente generici, per memorizzare le strutture richieste dai

correnti domini e presumibilmente anche dai futuri domini. Nel

tentativo di individuare le caratteristiche comuni tra i domini, il

sistema minimizza anche i costi di esecuzione.

WebVise

Il sistema WebVise [GSO99] e un sistema che cerca di estendere

l’attuale modello ipertestuale con l’utilizzo di un “hypermedia

service” che e una sorta di “middleware” tra le varie applicazioni

che girano tra le workstation degli utenti ed i server. Il Webvise

Client e integrato con Internet Explorer e permette di creare link

ed annotazioni tra frammenti di pagine HTML senza utilizzare tag


HTML, e di condividere i link cosı definiti. Le strutture create

vengono poi memorizzate in linkbase esterne. Il proxy interroga

il WebVise server per ogni documento richiesto tramite il browser

con lo scopo di trovare potenziali strutture esterne da inserire nel

documento.

WebWriter

Il WebWriter II Editor [CCB97] e una diretta manipolazione di

un editor HTML collocato all’interno di un Web browser ed utilizza

entrambe tecnologie server-side e client-side allo scopo di acquisire

vantaggi da entrambe le architetture. L’editor WebWriter e realizzato

mediante un’applicazione CGI scritta in C++. L’interfaccia

utilizzata e basata su frame HTML ed include frame individuali per

la preview dei documenti. Supporta la costruzione di semplici ed

interattive applicazioni Web senza il bisogno di conoscere HTML

o programmazione CGI. Oltre all’editor, il Web Writer include il

“WebWriter Page Generator”, un’applicazione CGI che consente di

creare nuove pagine Web. Ogni volta che l’editor viene richiamato,

Web Writer genera una pagina che contiene un tag nascosto per

memorizzare le informazioni relative allo stato corrente della sessione

di editing. Questo elemento e necessario per permettere al CGI di

ristabilire lo stato di tutte le strutture dati che riguardano la fasi di

editing dando l’illusione che il programma sia sempre in esecuzione

per eseguire le modifiche richieste dall’utente.

XLinkProxy

XLinkProxy [CFR02] e un progetto sviluppato all’Universita di

Bologna con lo scopo di applicare lo standard XLink del W3C ai

browser esistenti, fornendovi un supporto per l’inserimento di link

esterni. XLinkProxy e basato sull’utilizzo di un non trasparent-proxy,

cioe un proxy a cui e permesso di modificare le risorse che passano

per il proxy stesso. Il non trasparent-proxy si occupa dell’inserimento

dei link esterni memorizzati su delle linkbase presenti sul server su

tutti i documenti di natura HTML o XML e provvede a mandare


il documento modificato al client. Pero per tutte le altre risorse di

natura diversa da HTML o XML, XLinkProxy si comporta come un

trasparent-proxy e questo fattore rappresenta uno dei limiti di questo

progetto.

2.4.1 Vantaggi delle soluzioni proxy

Nei paragrafi precedenti, abbiamo visto come i proxy vengono

utilizzati, oltre che per motivi di caching e di controllo per l’accesso

ad Internet, anche per alterare il contenuto della risorsa ricevuta dal

server. L’utilizzo di un server proxy e infatti un elemento ricorrente

per quei sistemi che hanno lo scopo di modificare i contenuti di pagine

Web.

Analizziamo di seguito i vantaggi dei proxy che hanno portato questi

sistemi alla scelta di tale approccio:

• le tecnologie server-side sono piu avanzate rispetto alle

tecnologie client-side, sono scalabili, multi-platform ed

indipendenti dal browser.

• la modifica del documento da restituire al client viene effettuata

in maniera piu veloce rispetto alle applicazioni client-side (e

sufficiente interrogare il server per verificare se ci sono delle

informazioni da associare alla risorsa richiesta dall’utente). Il

carico di lavoro per il browser e minimo dal momento che esso si

limita a ricevere degli ordinari documenti HTML (l’inserimento

delle informazioni esterne viene effettuato completamente sul

proxy).

• la modifica del documento e completamente trasparente per

l’utente, dal momento che nessun indizio viene fornito del

passaggio intermedio compiuto dal proxy. Per esempio, nel caso

di inserimento di link esterni, la pagina finale viene consegnata

solo dopo aver aggiunto i link e, l’utente riceve un documento

HTML dove i nuovi link sono indistinguibili da quelli originali.

• client differenti possono essere configurati per consultare lo

stesso proxy, cosı che il sistema di modifica dei documenti


esterni diviene completamente portabile ed indipendente dal

browser.

L’ultimo punto non e completamente vero dal momento che, per

esempio, l’interfaccia di XLinkProxy e supportata solo da Internet

Explorer e porta molti sistemi ad abbandonare la scelta di una

soluzione basata su questa architettura.

2.4.2 Svantaggi delle soluzioni proxy

Di seguito vengono mostrati alcuni limiti delle soluzioni basate

sull’utilizzo di un server proxy:

• anche se l’inserimento delle modifiche sulle pagine viene

compiuta dal proxy, la definizione di quali debbano essere le

modifiche necessita comunque di un’interfaccia utente rendendo

cosı il sistema dipendente da tecnologie client-side (come

XLinkProxy). Tra le soluzioni proposte, sono stati utilizzati

dei frame che hanno il compito di monitorare e comunicare

con la finestra principale, ma questo porta a due importanti

questioni: la gestione dell’URL e i problemi di sicurezza. Il

primo punto e un problema in quanto e in disaccordo con uno

delle linee guida del web riguardo la corrispondenza univoca tra

la risorsa e ed il suo relativo URL: utilizzando dei frame invece,

molte risorse vengono raggruppate sotto un’unico URL quello

del frameset. L’inconsistenza tra l’URL presente nella barra

degli indirizzi e quello della risorsa richiesta porta inoltre ad una

serie di difficolta per quanto riguarda la gestione dei bookmark

o la ricerca delle informazione. Poi, per quanto riguarda i

problemi inevitabili di sicurezza va detto che essi dipendono

dalla comunicazione tra i frame; oltretutto il significato dei

bottoni “Back” e “Forward” puo venir spesso confuso e non

interpretabile dal browser.

• quando viene caricato nel browser un documento locale il proxy

non viene contattato e non riesce, dunque, a svolgere la sua

funzione.

2.5. SOLUZIONI BASATE SULL’ ARCHITETTURA CLIENT 21

• interponendo un proxy tra un browser e un server, e necessario

un numero doppio di connessioni per ogni risorsa richiesta dal

client. Chiaramente questo fattore rallenta i tempi di riposta

verso il client con il rischio che si verifichino timeout e problemi

di latenza.

• un proxy, che agisce come agente intermediario per la modifica

dei contenuti, non riesce a svolgere la sua funzione in quelle

situazioni in cui e presente un altro proxy con funzionalita di

firewall. La presenza di un firewall impedirebbe al client di

ricevere la versione modificata del documento dal proxy. Il

problema potrebbe essere risolto a livello di infrastrutture, con

una gestione esplicita delle rete di connessioni, convincendo

i manager di altri proxy a stabilire la giusta catena di

comunicazione che permetterebbe ad ogni proxy di assolvere le

proprie funzioni. Tale soluzione e pero di difficile realizzazione

dal momento che, solitamente, i firewall hanno proprio il

compito di proteggere le grandi organizzazioni dei grandi paesi,

e le trattative per un accordo potrebbero diventare difficili.

• il proxy non ha un diretto controllo sulle pagine caricate, non

ha accesso al DOM, quindi ogni volta che deve effettuare una

modifica deve compiere un’operazione di parsing su tutto il

documento per cercare il punto esatto da modificare. Tale

operazione non rende dunque semplice l’operazione di modifica

del documento.

2.5 Soluzioni basate sull’ architettura

client

Nei prossimi paragrafi vedremo come molte ricerche si sono basate

su un’architettura client, integrata con il browser, per superare i limiti

del proxy.


Amaya

Amaya [Ama96] e un progetto open source, scritto in Visual C++

v6.0 e nato nel 1996, con supporto ai principali standard del W3C.

Amaya e un browser che supporta il protocollo HTTP v1.1 e ospita

al suo interno un editor che produce codice HTML v4.01. Supporta

inoltre: XHTML, MATHML (per navigare ed editare le pagine che

contengono espressioni matematiche) e CSS. Amaya non e un vero

e proprio browser, ma un editor di pagine Web WYSIWYG. Amaya

incorpora con se entrambe le funzioni: editor e browser (cercando

di mettere in pratica una delle intenzioni di Tim Berners-Lee). Con

Amaya e possibile navigare il World Wide Web e modificare al volo

le pagine che si incontrano, salvarne e visualizzarne la struttura in

modo semplicissimo. Amaya e progettato per coloro che vogliono

scrivere codice compatibile con le specifiche ufficiali del W3C, di

conseguenza e anche un ottimo strumento per la divulgazione degli

standard del Web. Seppure uno strumento formidabile per la

progettazione di pagine Web, Amaya e un editor il cui uso e

circoscritto a pochissimi sviluppatori e non solo per la mancanza di

supporto commerciale. Amaya rimane, anche nelle ultime versioni,

un software di difficile utilizzo, a cio si aggiungono anche i vari errori

nell’esecuzione di alcuni comandi che spesso provocano perdita del

lavoro ed interruzioni varie. In conclusione, Amaya e considerato

un’ottimo strumento per chi vuole semplicemente scrivere o testare il

proprio lavoro, ma potrebbe rendere la vita molto difficile a chi invece

vorrebbe utilizzarlo come strumento base per costruire siti Web.

Annotea

Annotea [Koi01] e un sistema per le annotazioni condiviso che

sfrutta le esistenti tecnologie come RDF, XPointer [DDG02], XLink

a HTTP per permettere di associare ad ogni documento Web i

loro propri commenti o bookmarks. Per annotazioni si intendono

commenti, note, spiegazioni ed altri tipi di riferimenti esterni che

possono effettivamente essere attaccati al documento senza il bisogno

di modificarlo. Similmente anche i bookmark possono essere attaccati


al documento per aiutare ad organizzare in categorie, per aiutare

a trovare il materiale relativo e poter utilizzare un bookmark che

filtra il materiale. Le annotazioni sono esterne alle pagine originali

e possono venir memorizzate in server prestabiliti. I client di

Annotea, richiedono le annotazioni espresse in sintassi RDF dai server

e le mostrano di fianco al documento non modificato. La prima

implementazione client di Annotea e Amaya, l’editor browser del

W3C, ma cio non implica che di estenderne la funzionalita anche

ad altri browser.

Annozilla

Annozilla [Ann02] e un sistema che permette di creare annotazioni

sulle pagine Web come definito dal progetto Annotea del W3C. L’idea

e quella di memorizzare le annotazioni in formato RDF su un server,

utilizzando la sintassi XPointer per identificare su quali regioni del

documento creare le annotazioni. L’intenzione di Annozilla e quella di

sfruttare le potenzialita del browser Mozilla per creare le annotazioni.

Il progetto Annozilla e ancora in fase di sviluppo per aggiungere

nuove funzionalita, incluso un supporto per un sistema distribuito

mediante l’utilizzo di piu server.

Hunter Gatherer

Hunter Gatherer [MSW02] e un tool integrato nel browser che

provvede una semplice interfaccia per selezionare dei frammenti

dalle pagine a cui si ha accesso, per memorizzare i frammenti

di questi documenti e per manipolare la collezione di queste

informazioni. Nessun contenuto viene copiato nelle collezioni che

sono solo composte di riferimenti ai frammenti originali attraverso

un meccanismo chiamato “Aggregated URLs”. Hunter Gatherer

non e un’applicazione stand-alone integrata sul browser ma e basata

sull’utilizzo di un server proxy; ogni volta che il client effettua una

richiesta la pagina viene processata server-side per convertirla dal

formato HTML ad XHTML. Una volta che la pagina ha acquisito

questa struttura, l’applicazione utilizza il Document Object Model

dell’albero XML del documento per ritrovare la locazione di un

particolare frammento selezionato dall’utente. Il sistema utilizza due

metodi per definire gli elementi che appartengono alla selezione: il

primo si basa sull’individuazione dei nomi degli elementi XHTML

corrispondenti ai tag HTML compresi nella selezione (ad esempio un

 o un <TD>); il secondo metodo e basato sull’utilizzo di XPath

per identificare le entita dentro gli elementi compresi nella selezione

(ad esempio: l’utente puo selezionare l’ultima occorrenza di una

particolare parte di testo all’interno di un nodo P). Dal momento che

le collezioni delle informazioni vengono memorizzate nei loro relativi

URL, esse possono essere facilmente condivisibili e modificabili.

Turquoise

Turquoise [MM97] e un browser intelligente che contiene un editor

WYSIWYG per il World Wide Web per permettere agli utenti

di creare pagine dinamiche senza il bisogno di conoscere linguaggi

di scripting. Turquoise propone un approccio alternativo grazie

all’utilizzo di euristiche che permettono di creare gli script “per

dimostrazione”. L’utente dimostra uno script navigando alla risorsa

desiderata ed usando “cut-and-paste” per costruire un esempio della

nuova pagina che intende creare. Dato questo singolo esempio, il

sistema genera uno script che rigenera la pagina automaticamente,

andando a reperire le informazioni piu recenti dai documenti originali.

Turquoise e composto di un “pattern matcher” che utilizza delle

“template” per rintracciare e ricostruire dai frammenti dei documenti

HTML selezionati le parti significative per l’utente.

Web Browser Intelligence

Web Browser Intelligence [BM98] e un sistema che agisce

come intermediario sulla workstation dell’utente per osservare

le azioni degli utenti, offrire attivamente assistenza, modificare

documenti Web, ed aggiungere nuove funzionalita. Esso provvede

un’architettura che si posiziona nello stream di comunicazione tra il

Web browser ed l’origin server. WBI e un proxy che intercetta http


stream per l’osservazione e l’alterazione. In un WBI interagiscono

tre tipi di agent che manipolano lo stream request-response:

• un MONITOR che riceve una copia dell’intera transazione

request-response ma senza alterarla;

• un EDITOR AGENT che intercetta lo stream di comunicazione,

riceve l’informazione, modifica il contenuto e poi consegna la

versione modificata del documento richiesto;

• un GENERATORE che converte una richiesta in una risposta; e

un semplice programma che parsa la richiesta di un appropriato

Web server, riceve la risposta e la ripassa indietro al browser

(svolgendo il lavoro di un proxy HTTP).

Un WBI sostanzialmente, monitora l’attivita di un particolare utente,

classificando le pagine accedute, effettuando una ricerca sul Web di

pagine relative alla pagina che l’utente ha richiesto ed aggiungendo

successivamente link alle pagine accedute in modo tale da suggerire

all’utente quali sono le pagine inerenti lo stesso argomento ricercato.

Piu precisamente viene abiliato un monitor ogni volta che una

pagina contenente testo viene richiesta. Il monitor estrae le

keyword associate alla risorsa, memorizzando la sequenza di URL

visitati dall’utente. Un secondo agent effettua delle keyword query,

restituendo la lista delle pagine che l’utente ha precedentemente

visualizzato e informando l’utente quando tali informazioni sono

disponibili. Infine, l’utente puo scegliere se visualizzare la lista di

pagine correlate che possono venir esaminate. L’esperienza suggerisce

che spesso gli utenti richiedono la stessa sequenza di URL molte

volte ed, utilizzando WBI, e possibile velocizzare le sue operazioni

compiute abitualmente. La normale interazione con l’utente viene

mantenuta, ma nuove funzionalita vengono aggiunte.

Yawas

Yawas [DV00] e un altro sistema per aggiungere annotazioni; e

un prototipo sviluppato all’Universita di Savoia, che studia come le

annotazioni possano essere usate per migliorare i correnti bookmark.


L’approccio usato si basa sull’utilizzo di eventi interni al DOM senza

cambiare il markup della pagina. Yawas usa file locali per conservare

e ritrovare le annotazioni. I file di annotazione locali possono essere

spediti ad altri utenti solo via e-mail o copiati in altro modo. Il

sistema utilizza come client Internet Explorer.

Xspect

Xspect [CHB03] e un sistema molto recente basato su XSLT e

Javascript. Xspect ha due implementazioni, una server-side ed una

client-side. Entrambe le implementazioni forniscono un’interfaccia

per la creazione di annotazioni. Xspect utilizza XLink e, oltre a

supportare la navigazione sugli hypermedia, fornisce un’interfaccia

per guidare l’utente durante la navigazione e provvedere un sistema

di authoring per le annotazioni. Xspect fornisce un’interfaccia utente

per la navigazione e la visualizzazione delle linkbase piuttosto che

per la loro creazione ed il “surfing monitoring” come fanno Goate e

XLinkProxy.

XStandard

Xstandard [Sca04] e un plug-in ActiveX sviluppato per essere

integrato nel browser o per sistemi operativi di gestione di contenuti

basati su sistemi Windows. Il sistema crea un’area WYSIWYG

nella quale gli utenti possono gestire contenuti in qualsiasi lingua.

XStandard e il primo prodotto commerciale disponibile come editor

WYSIWYG che genera codice valido XHTML 1.1 senza elementi

(tag) deprecati. XHTML 1.1 e l’ultima raccomandazione del W3C

disponibile per la creazione di contenuti ed e significante in quanto

limita il ruolo degli elementi nella marcatura per la definizione

della struttura ed utilizza solamente fogli di stile a cascata (CSS)

per la formattazione. Il risultato e una netta “pulizia” del codice

con separazione dei dati dalla formattazione il che e essenziale

per il riutilizzo dei contenuti per sistemi diversi dai normali PC

Desktop e per le applicazioni legate all’accessibilta. Utilizzando

XStandard si riducono le procedure di “pulizia” del codice utilizzate


per purificare il codice e rendere i contenuti accessibili, abbassando

quindi i costi di manutenzione e di pubblicazione. Questo modo di

procedere incrementa la velocita di creazione di contenuti, riduce

la possibilita di errori di formattazione ed aiuta a mantenere un

layout costante. Gli utenti commerciali possono inoltre applicare

degli elementi personalizzati a parole, a frasi o oggetti (come le

immagini), offrendo infinite opportunita di arricchire la semantica dei

propri dati. XStandard fornisce un’anteprima di visualizzazione, in

emulazione Screen Reader, che rende visibili i contenuti prima della

pubblicazione, velocizzando il ciclo di pubblicazione e riducendo i

costi.

2.5.1 Vantaggi delle soluzioni client

Le soluzioni client-side hanno i seguenti vantaggi:

• avendo accesso al DOM l’applicazione client puo facilmente

manipolare il contenuto di qualsiasi tipo di documento, non

solo HTML e XML.

• le applicazioni client-side di solito necessitano di pochi passi

per l’installazione e la configurazione;

• le applicazioni client possono incorporare al loro interno un

editor tramite il quale e possibile creare e modificare in modo

veloce il contenuto del sito Web direttamente dal browser,

evitando che l’utente incorra in cadute di attenzione dovute

al passaggio di applicazioni esterne;

• un’architettura client browser assicura brevi tempi di risposta

per l’interazione;

• le architetture client hanno semplici interfacce.

2.5.2 Svantaggi delle soluzioni client

Tuttavia anche le soluzioni client-side presentano alcuni limiti:

• sono dipendenti dal browser per il quale sono state progettate;


• impiegano di tempi piu lunghi per la modifica del DOM;

• la loro installazione (applicazioni sul browser) potrebbe

minacciare alcune politiche di sicurezza del sistema: di solito

viene richiesta l’installazione di plug-in che interagiscono con il

sistema stesso.

2.6 Meccanismi di estensione del browser

Alcuni dei sistemi studiati per rendere il processo di navigazione

piu consono alle esigenze dell’utente sono stati realizzati mediante

dei meccanismi di estensione del browser. Molti browser, infatti,

sono predisposti per l’aggiunta di alcuni oggetti che possono essere

utilizzati per la visualizzazione di alcune informazioni e per creare una

forma di interazione con l’utente durante il processo di navigazione.

Questi oggetti possono essere rappresentati da toolbar, barre verticali

o orizzontali e consistono in aree adiacenti la finestra principale del

browser. Essi vengono piu comunemente visualizzati come pannelli

verticali sul lato sinistro della finestra principale del browser ma

anche orizzontalmente. Alcune barre verticali standard, chiamate piu

comunemente “sidebar” sono ad esempio “Favorities” e “Search”.

Analizziamo di seguito alcuni dei meccanismi di estensione del

browser piu diffusi oggi in commercio ed i servizi che essi intendono

offrire all’utente per garantirgli un ambiente personalizzato.

2.6.1 Toolbar: navigare, monitorare e conoscerei siti Web

Oggi giorno tutti i piu importanti siti Web producono la propria

toolbar personalizzata tanto che sicuramente la sua presenza e

diventata anche un fattore di competizione. Piu che una moda,

tuttavia, la sua diffusione e dovuta sicuramente alla sua utilita.

Le toolbar permettono di accedere ai contenuti da qualsiasi parte

del Web e soprattutto in maniera integrata alle pagine che si stanno

visitando. Le toolbar sono degli strumenti messi a disposizione dai

motori di ricerca e oltre a fornire comodamente l’accesso diretto alle

2.6. MECCANISMI DI ESTENSIONE DEL BROWSER 29

ricerche dal browser, mettono a disposizione una serie di utility che

offrono all’utente numerosi vantaggi per la ricerca e la navigazione

sul Web.

Analizziamo di seguito alcune tra le toolbar attualmente piu

utilizzate:

AltaVista toolbar La toolbar di Altavista [Alt04], progettata per

Internet Explorer come mostrato in figura 2.1, include dei servizi

come:

Figura 2.1: Altavista toolbar

• Ricerca nel Web: nella toolbar e presente un menu a discesa

contenente tutte le opzioni di ricerca disponibili di AltaVista

accanto alla casella di ricerca. Dopo aver inserito la richiesta,

e possibile cercare nell’indice indicato attualmente, o anche

selezionare un altro indice dal menu. La selezione della ricerca e

chiamata “adesiva”, nel senso che vengono sempre visualizzate

le ricerche in base all’ultimo indice selezionato, fin quando un

altro indice non viene indicato. La ricerca include anche una

ricerca per immagini.

• Evidenza: questo servizio mette in evidenza i termini della

casella di ricerca, laddove appaiono nella pagina attuale.

• Traduzione: nella toolbar e presente un pulsante chiamato

“Babel Fish” che permette di tradurre parole inserite nella

casella di ricerca, testi selezionati da una pagina Web o anche

pagine Web intere.

• Blocco dei popup: i siti Web spesso usano degli script Java per

caricare gli annunci pubblicitari mentre l’utente sta navigando

in una pagina. Questi script, una volta caricati, aprono

delle finestra popup, generalmente mentre si sta navigando o


quando si esce dalla pagina. Il blocco popup della toolbar di

Altavista permette di disattivare la maggior parte di questi

script, impedendo la comparsa delle finestre popup. Il blocco

popup e attivato per default, ma queste impostazioni possono

essere modificate dalla pagina di impostazioni della toolbar.

• Ultima ricerca: questo pulsante riporta all’ultima ricerca

effettuata, mostrando l’ultima pagina dei risultati che e stata

generata.

Alexa toolbar La toolbar di Alexa [Ale04], progettata per il

browser Internet Explorer come mostrato in figura 2.2, e una delle piu

Figura 2.2: Alexa toolbar

utilizzate tra quelle in circolazione sul Web. Ospita al suo interno

il motore di ricerca Google e fornisce informazioni molto utili sul

sito che si sta visualizzando, senza interrompere il Web browsing.

Fornisce anche un lista di link siti “correlati” a quello in cui ci si trova,

ovvero una lista dei siti piu visitati dagli altri visitatori dello stesso

sito. Inoltre e anche disponibile “Whois”, un servizio che permette

di vedere a chi e intestato il dominio del sito. Sono anche disponibili

informazioni dati sul traffico e servizi di condivisione delle opinioni

riguardo i siti tra gli utenti.

Arianna toolbar

La toolbar di Arianna [Ari04], progettata per il browser Internet

Explorer come mostrato in figura 2.3, permette di effettuare delle

Figura 2.3: Arianna toolbar

ricerche offrendo una vasta quantita di possibilita. Tra i servizi


che offre ve ne sono alcuni particolarmente interessanti come

“Community”, mediante il quale e possibile partecipare a forum o

creare il proprio “Moblog”. Altri servizi utili sono, per esempio,

quelli che permettono di avere un accesso diretto alla propria casella

di posta e ai newsgroup, o di ricercare numeri di telefono ed altre

informazioni ad essi relative.

Google toolbar La toolbar di Google [Goo04], progettata per il

browser Internet Explorer come mostrato in figura 2.4, offre numerose

Figura 2.4: Google toolbar

opzioni per rendere la navigazione nel Web piu piacevole e produttiva.

La Google toolbar consente non solo di effettuare ricerche dirette

all’interno di Google, ma effettua anche il calcolo del “Page Rank”

che viene associato al sito che si sta visualizzando. Il “Page Rank”

equivale all’importanza che Google assegna alla pagina, in base ad un

calcolo automatico che tiene conto della struttura di collegamenti del

Web e molte altre variabili. L’algoritmo del “Page Rank” puo essere

utilizzato per creare “visioni personalizzate” del Web, definite in base

alle preferenze dell’utente. La presenza di questo servizio rappresenta

un fattore di distinzione rispetto alle altre toolbar offerte dagli altri

motori di ricerca. La Google toolbar permette di:

• poter utilizzare Google per eseguire ricerche sul Web da

qualunque sito;

• eliminare annunci popup;

• limitare la ricerca delle pagine ad un paese specifico;

• eseguire la ricerca solo all’interno delle pagine di un sito;

• evidenziare i termini di ricerca nella pagina;


• personalizzare il layout della toolbar.

Nell’interfaccia della toolbar e presente un menu a tendina che da

accesso ad alcuni utili servizi. Tra questi e interessante notare che

e presente anche una voce riguardante lo spazio di Google aperto

agli autori di Weblog (blog), un luogo in cui e possibile creare

pubblicazioni personali online gratuitamente. Inoltre la Google

toolbar si aggiorna automaticamente appena e disponibile una nuova

versione.

Groowe toolbar La Groowe toolbar [Gro04], progettata per il

browser Internet Explorer come mostrato in figura 2.5, permette

Figura 2.5: Groowe toolbar

all’utente di utilizzare molti motori di ricerca contemporaneamente:

Google, AltaVista, Yahoo, MSN Search, e AllTheWeb. Inoltre

permette di attivare delle ricerche in determinate categorie o

directory, rendendo il processo di ricerca piu semplice e veloce.

PrefBar toolbar La PrefBar [Pre04], progettata per il browser

Mozilla come mostrato in figura 2.6, rappresenta un’evoluzione della

Preference Bar di Mozilla che era stata disegnata per dare all’utente

piu controllo sulle pagine visualizzate e permettergli di utilizzare quel

browser con grande facilita ed efficienza. La PrefBar offre in piu,

tramite standard checkboxes, la possibilita di attivare e disattivare

Javascript, user agent spoofing, Web links, abilitare e disabilitare i

cookies.


Figura 2.6: PrefBar toolbar

Teoma toolbar La Teoma toolbar [Teo04], progettata per il

browser Internet Explorer come mostrato in figura 2.7, oltre al motore

di ricerca offre la possibilita di di utilizzare un Dictionary per trovare

facilmente il significato delle parole quando se ne avesse bisogno, di

evidenziare i termini di ricerca ogni volta che essi appaiono nella

pagina e inviare via-mail ad un altro utente la pagina visualizzata.

Figura 2.7: Teoma toolbar

UltraBar toolbar UltraBar [Ult04], mostrata in figura 2.8, e un

prodotto studiato per semplificare le attivita di tutti coloro che

hanno bisogno di utilizzare il Web frequentemente a scopo di ricerca.

UltraBar permette di selezionare da un apposito menu i termini piu

frequentemente utilizzati o di aggiungerne altri per le future ricerche.

Questa toolbar puo essere personalizzata al fine di rendere le ricerche

agevoli ed immediate e comprende molte caratteristiche comuni alle

altre toolbar presenti in commercio.

Figura 2.8: Ultrabar toolbar


2.7 Conclusioni

In questo capitolo e stata presa in esame l’evoluzione del

modello ipertestuale nel tempo fino ai sistemi attuali. E stato

sottolineato come molti sistemi, il World Wide Web piuttosto che

una evoluzione abbia subito un involuzione, rispetto al progetto

originale. Si e cercato di delineare, quindi, gli elementi che mancano

a questo modello di ipertesto e le soluzioni proposte per superare tali

limiti. L’attenzione e stata focalizzata sull’importanza di rendere

il processo di navigazione dell’utente un’esperienza completamente

soddisfacente le proprie esigenze. Tuttavia i sistemi presentati finora,

non sembrano ancora essere riusciti a raggiungere completamente

questo obiettivo.

Capitolo 3

La sidebar ISAWiki

Sebbene le potenzialita del World Wide Web siano davvero

notevoli, il modello ipertestuale sul quale esso si basa presenta ancora

alcune carenze. In particolare, i browser Web offrono un ambiente in

cui e ancora troppo rigida la distinzione tra il ruolo del lettore e quello

dell’autore. Infatti se da un lato, il lettore puo utilizzare semplici e

gratuiti tool ma solo per leggere i documenti esplicitamente forniti

dagli scrittori senza poter creare dei nuovi contenuti, link o versioni

personalizzate delle pagine Web, dall’altro, l’autore deve avere a

disposizione un vasto numero di tecnologie e tool spesso complessi

e costosi per poter pubblicare i propri documenti.

In questo capitolo verra illustrato un framework progettato con lo

scopo di mostrare come sia possibile incrementare le funzionalita

del Web, utilizzando gli standard attuali e senza rivoluzionarne

l’architettura corrente.

3.1 Introduzione

Prima di analizzare il progetto realizzato nel corso di questa tesi

e necessario fornire una visione del contesto nel quale tale progetto

si colloca.

Il motivo principale che ha portato alla nascita di questa tesi e

stato quello di fornire un supporto al server realizzato nell’ambito del

progetto ISAWiki, tramite il quale l’utente puo utilizzare al meglio ed

in una maniera ancora piu semplice tutte le funzionalita ed i servizi

35

36 CAPITOLO 3. LA SIDEBAR ISAWIKI

che il server ISAWiki [Fan03] offre.

Di seguito viene fornita una descrizione del progetto ISAWiki da cui

la tesi e nata.

3.2 Il progetto ISAWiki

Il progetto ISAWiki, nasce dall’esigenza di permettere agli utenti

di utilizzare gli strumenti a loro piu familiari per produrre delle

pagine per il Web. Fornendo questa possibilita all’utente, oltre

a semplificare il lavoro di creazione di siti, si permette anche di

pubblicare i documenti gia nell’apposito formato per il Web, dal

momento che in questo modo la pubblicazione e possibile in maniera

automatica.

Il progetto ISAWiki nasce dal congiungimento di due progetti: ISA,

un progetto avviato nel 2003 dal professor Fabio Vitali, ed il Wiki

Wiki Web (comunemente chiamato wiki), nato nel 1994 da un’idea

di Ward Cunninghan. ISAWiki e un Content Management System

(CMS) derivato dal progetto ISA, in cui sono state integrate le

caratteristiche del Wiki Wiki Web. Di seguito, vengono spiegati

i sistemi dai quali il progetto si e evoluto al fine di comprendere

meglio le esigenze e le scelte fondamentali che hanno portato alla

realizzazione di questo progetto.

3.2.1 Content Management System

I sistemi denominati “Content Management System” (CMS) sono

stati la principale fonte di ispirazione per la realizzazione del progetto

ISAWiki.

Con il termine CMS non si indica un prodotto ben definito, ne

una particolare tecnologia, ma un vasto numero di processi che

riguardano la gestione di contenuti non solo relativi al Web; tuttavia,

i CMS forniscono l’automazione dei processi tipici di creazione

delle pagine Web. Lo scopo principale di un CMS e l’integrazione

dei processi di creazione, composizione, controllo, pubblicazione,

3.2. IL PROGETTO ISAWIKI 37

revisione e archiviazione dei documenti, piu eventuali servizi avanzati

che differiscono nelle varie implementazioni.

L’utilizzo di tali sistemi implica pero la presenza di utenti esperti

nelle varie fasi di creazioni di contenuti, di realizzazione dei layout

di presentazione e nella fase di assemblaggio del contenuto e del

layout. Infatti, i CMS sono adatti per la gestione di pagine Web

molto complesse e richiedono conoscenze avanzate, sia per la loro

installazione, sia per la loro configurazione. I Content Management

System dispongono di diverse funzionalita utili ad ottenere questo

scopo, ma difficilmente uno stesso software le integra tutte. Infatti,

poiche esistono innumerevoli tipi di contenuti, le aziende produttrici

offrono CMS con caratteristiche differenti, spesso con funzionalita

peculiari e specializzate per un particolare ambito di applicazione.

Le problematiche tecniche relative all’automatizzazione dei processi

di gestione e diffusione dei contenuti sono spesso legate alla necessita

di unire il contributo di differenti autori, che lavorano in maniera

sincrona o asincrona sui medesimi contenuti, condividendo alcune

risorse. Si rammenti infatti che il Web e stato inizialmente

progettato per consentire ad un gruppo di scienziati di utilizzare

le reti informatiche per collaborare tra loro, attraverso lo scambio

di documenti, la discussione, il coordinamento delle attivita, la

creazione e la pubblicazione dei contenuti. In altre parole, esso fu

ideato proprio per essere un supporto tecnico al lavoro di gruppo tra

le persone, anche geograficamente distanti.

La diffusione dei calcolatori e successivamente delle reti ha portato

ad un incremento notevole nella condivisione delle informazioni ed il

Web ne e divenuto in breve tempo, attraverso la rete Internet, uno

dei principali veicoli di diffusione.

E da questa necessita che sono nati i sistemi collaborativi (come il

Wiki Wiki Web di cui si parlera in seguito), che consentono di gestire

gruppi di persone che lavorano condividendo documenti e risorse.

In realta, la necessita di disporre di sistemi di collaborazione era

gia presente al momento dei primi sviluppi del Web. Seguendo

questa esigenza, nacquero dei sistemi piu o meno evoluti di scambio

di informazione tra gruppi di persone, quali: posta elettronica,


mailing-list e newsgroup, shared access, interactive Pages. Uno dei

piu significativi vantaggi derivanti dall’utilizzo di un moderno sistema

di condivisione e la possibilita di creare e gestire i documenti tramite

editor di semplice utilizzo, solitamente fruibili via Web.

Per potenziare le funzionalita del protocollo HTTP 1.1 e stata

realizzata un’estensione, nota con il nome di WebDav (Web

Distributed Authoring and Versioning) [CFG99]; essa consente di

inglobare meccanismi di collaborazione e condivisione delle risorse

basati, oltre che sul testo, anche su altri tipi di formato. Esso

rappresenta un utile tool per il Web authoring ma non e user-oriented;

inoltre, non provvede metodi per creare pagine linkate ma solo

meccanismi per memorizzarle e richiederle.

3.2.2 Immediate Site Activator

ISA (Immediate Site Activator) e un’applicazione server-side,

progettata per consentire di produrre pagine Web complesse senza

che l’utente necessiti di alcuna conoscenza tecnica particolare. ISA

puo essere definito come un CMS (Content Management System),

cioe un software costruito per l’automatizzazione e l’integrazione

dei processi di creazione, composizione, controllo, pubblicazione,

revisione e archiviazione delle informazioni. L’utilizzo dei normali

CMS e pero indicato per la creazione di siti molto complessi e richiede

conoscenze avanzate, sia per la loro installazione che per la loro

configurazione. Cio impone all’utente la necessita di apprendere

l’utilizzo e le funzionalita di tali strumenti, che sono spesso complessi,

poco “user friendly” e di utilizzo tutt’altro che immediato. Inoltre,

nella maggior parte dei casi, colui che realizza il layout e limitato dalle

notevoli rigidita del sistema. La forza di ISA e quella di permettere

all’utente di utilizzare gli strumenti che preferisce nell’ambito di un

vasto numero di programmi commerciali molto diffusi (per esempio

e possibile realizzare il layout con Adobe Photoshop, MacroMedia

Fireworks e scrivere i contenuti con Microsoft Word). Al momento

della richiesta del documento, l’applicazione si occupera di ricostruire

la pagina finale senza che l’utente necessiti di altre operazioni.


Inoltre non e necessaria alcuna conoscenza per l’installazione e la

configurazione del server. Utilizzando ISA viene quindi modificato

il processo di produzione delle pagine Web. Tale processo e infatti

solitamente composto dalle seguenti fasi:

• Produzione del contenuto: autori esperti scrivono e strutturano

il contenuto utilizzando editor standard;

• Creazione del layout : esperti di grafica preparano layout

generici, utilizzando strumenti professionali come Adobe

Photoshop o Macromedia Fireworks;

• Fusione delle due componenti : esperti di tecnologie Web

fondono le due parti nei documenti finali, con strumenti

professionali come GoLive, Dreamweaver o FrontPage.

Mentre con i normali CMS la prima fase fa uso di editor standard

forniti dai CMS stessi e le ultime due fasi devono essere eseguite

da persone esperte nell’utilizzo di strumenti adatti, utilizzando ISA

questo processo diventa piu semplice. Infatti, il contenuto viene

creato dall’utente utilizzando un programma specifico per scrivere dei

documenti di contenuto, come Microsoft Word, il layout viene creato

da persone esperte di grafica, ma la fusione delle due componeneti

viene creata da persone esperte di grafica utilizzando il motore

implementato in ISA. L’applicazione ISA realizza tale integrazione

tramite l’utilizzo di un foglio di stile XSLT. Pertanto i principali

vantaggi nella scelta del sistema ISA sono:

• minore necessita di conoscenze tecniche specifiche;

• possibilita di utilizzare strumenti molto diffusi e di uso comune;

• semplicita di utilizzo, congiunta a notevole flessibilita.

Pertanto l’autore si preoccupa solo della redazione del documento

con le informazioni che desidera pubblicare, e puo trascurare

completamente gli aspetti grafici della presentazione. Questi ultimi

possono essere suddivisi in due tipologie: “decorativi” e “semantici”.

Gli aspetti “decorativi” rappresentano gli aspetti prettamente grafici


propri del layout ed indipendenti dal contenuto (sfondi, immagini

esterne, bottoni, font, colori ecc.). Gli elementi “semantici ” sono

invece quelli utilizzati per enfatizzare alcune parti del discorso

(caratteri in corsivo o grassetto) o necessari per illustrarle o

esemplificarle (immagini o tabelle). Tale distinzione si riflette nella

separazione tra lo stile del documento e il suo contenuto. E necessario

che l’autore disponga del pieno controllo degli aspetti semantici, ed

e per questa ragione che il motore di ISA conserva questi elementi

esattamente come vengono inseriti in Microsoft Word.

3.2.3 Wiki Wiki Web

L’enorme aumento del numero degli utenti del World Wide

Web ha portato ad un incremento notevole della condivisione delle

informazioni e ad una collaborazione tra diversi utenti del Web.

Il Wiki Wiki Web, piu comunemente chiamato wiki, e uno dei

sistemi collaborativi di ultima nascita e di sicuro successo. L’idea

su cui si basa tale sistema e molto semplice. Esso permette,

tramite l’utilizzo dei browser maggiormente diffusi di visualizzare e

di editare documenti, facendo uso di un linguaggio molto semplice.

Tale linguaggio viene espresso in base ad un nuovo formato: il

formato wiki. Esso eredita alcune funzionalita di base dell’HTML,

pur rimanendo molto piu elementare rispetto ad esso e permette di

creare semplici pagine Web utilizzando un markup molto intuitivo che

riproduce gia di per se gli aspetti grafici della formattazione. In tale

sistema, naturalmente, l’aspetto grafico non ha grande importanza

ma viene privilegiato il contenuto. Un wiki puo essere definito

come una “collezione espandibile di pagine Web collegate fra loro,

cioe un sistema ipertestuale per la memorizzazione e la modifica di

informazioni, in pratica un database dove ciascuna pagina e editabile

da ogni utente che ha a disposizione un browser”. L’essenza del wiki

puo essere riassunta dai seguenti punti:

• e un ambiente collaborativo e completamente libero;

• e un ambiente democratico, in cui ogni utente ha esattamente


le stesse possibilita degli altri, e dove non esistono sistemi di

autenticazione;

• permette di modificare e creare contenuti usando solo un

semplice browser;

• fornisce un meccanismo intuitivo per creare link tra le varie

pagine e controlla automaticamente l’esistenza del documento

collegato;

• invita l’utente a partecipare in maniera assidua e attiva,

dandogli la possibilita di contribuire all’evoluzione del sito

stesso.

Ogni pagina contiene un collegamento per mezzo del quale e possibile

editarne il contenuto, che viene posto all’interno di una textarea

HTML, nella quale e possibile scrivere il contenuto in formato wiki o

HTML.

Il maggiore beneficio risultante dall’impiego del formato wiki consiste

nella notevole semplicita di utilizzo. Gli utenti possono creare e

modificare pagine Web pur non avendo alcuna conoscenza tecnica,

neppure di HTML. La filosofia alla base del formato dati wiki,

infatti, e quella di rappresentare il documento come se l’utente

stesse scrivendo su di un foglio di carta: la sintassi da utilizzare per

realizzare le formattazioni e autodescrittiva e riproduce graficamente

l’effetto della formattazione stessa.

Tuttavia il principale svantaggio del mondo collaborativo e la poverta

delle interfacce per l’utente. Poverta che, d’altra parte, permette ai

sistemi collaborativi di essere piu semplici e piu accessibili ai vari

membri.

3.2.4 ISAWiki

ISAWiki e un’applicazione client-server che nasce dall’integrazione

e dall’ampliamento delle proprieta di ISA e dei wiki, rappresentando

un’evoluzione dei sistemi fino ad ora descritti. Piu precisamente,

il progetto ISAWiki intende inglobare ed estendere le principali


funzionalita di entrambe le suddette categorie, ed inoltre rispondere

ad altri requisiti dettati dalla necessita di rendere l’applicazione

di semplice installazione e configurazione, e portabile su piu

piattaforme.

ISAWiki si propone di essere uno strumento collaborativo che

permette la condivisione di documenti attraverso il Web e, allo stesso

tempo, la creazione di siti anche complessi. Il sistema offre una serie

di servizi disponibili sia sul client che sul server. I servizi localizzabili

sul server sono:

• Memorizzazione: ogni volta che un documento, sia esso locale

o remoto, viene salvato sul server, viene memorizzato in una

apposita directory e viene generato un file per ogni versione del

documento. Ogni versione e caratterizzata da alcune proprieta:

numero di versione, nome dell’autore, formato e permessi di

accesso in scrittura ed in lettura.

• Conversione: ogni documento viene memorizzato in uno

specifico formato. Il modulo di conversione e in grado di

trasformare ogni documento da un qualsiasi formato ad un

altro qualsiasi formato facendo uso di un formato generico nel

quale ogni documento di tipo testuale puo venire mappato.

Attualmente i formati gia supportati sono: HTML, XML, HTM

(HTML prodotto da MS Word), doc e wiki.

• Presentazione: quando un documento viene richiesto in

formato HTML, vi viene applicato un layout tra quelli presenti

sul server, quello scelto dall’utente o quello di default.

• Versionamento: e possibile mantenere tutti i delta che

determinano i cambiamenti di un documento. Visto che

le diverse versioni possono essere in diversi formati, la

determinazione di tali delta viene fatta convertendo prima

le versioni nel formato generale. I delta possono poi venire

utilizzati per creare versioni compatte di lunghi alberi di

versione o per visualizzare le differenze tra una o piu versioni

susseguenti.

3.3. LO SCOPO DEL PROGETTO 43

• Supporto nell’editazione: quando un utente che possiede i

permessi di lettura e scrittura chiede di poter creare o editare

un documento, l’applicazione provvede a presentare un form

HTML, che puo essere vuoto nel caso in cui il documento non

esista, o contenere il testo del documento nel caso in cui questo

sia gia presente sul server.

• Motore di ricerca: permette di ottenere la lista dei documenti

che soddisfano almeno una volta i criteri richiesti. Per ogni

risultato viene mostrato il contesto cioe una porzione del

documento nel quale si e verificato il soddisfacimento dei criteri

di ricerca.

• Recent Changes: questo servizio consente di conoscere

rapidamente quali siano i documenti modificati recentemente.

• Configurazione e setup utente: l’utente puo settare diverse

opzioni per il server (ad esempio puo definire il layout di default

da utilizzare per la presentazione). E inoltre possibile definire

le impostazioni di accesso ai documenti locali.

Il client e composto da una sidebar preinstallata sul browser

dell’utente. La parte client, poiche e stata sviluppata nel corso di

questa tesi, viene descritta dettagliatamente nei paragrafi seguenti.

3.3 Lo scopo del progetto

L’obiettivo principale del progetto e la realizzazione di un

framework per dimostrare come sia possibile, semplicemente

mediante tecnologie client-side, offrire un sistema di modifica dei

contenuti Web direttamente dal browser e senza l’utilizzo di un server

proxy.

Per raggiungere questo obiettivo e stata sviluppata un’estensione

del browser per arricchirlo di alcune funzionalita. I maggiori

browser esistenti della corrente generazione possono essere estesi

con oggetti indipendenti come toolbar, sidebar, menu ecc. Il

framework, realizzato nell’ambito di questa tesi, e rappresentato


da una sidebar, cioe una sezione verticale che risiede all’interno

della finestra principale del browser. A causa delle differenze

nell’implementazione di questi oggetti tra i principali browser

esistenti e stato necessario concentrarsi, nell’ambito di questa tesi,

su uno in particolare: Microsoft Internet Explorer. Implementazioni

di questo stesso progetto sono gia in via di sviluppo per il browser

Mozilla. Comunque, anche se le implementazioni di questi oggetti

sono diverse a seconda dei browser, i protocolli che gestiscono le

comunicazioni con le altre applicazioni relative al progetto ISAWiki,

ed il server che permette la memorizzazione degli XLink, sono

fondamentalmente le stesse anche tra browser differenti.

3.4 La sidebar ISAWiki: una soluzione

client-side

La sidebar e l’interfaccia client del progetto ISAWiki. La

sidebar mette a disposizione una serie di tecnologie e tool che

permettono all’utente tramite un serie di interfacce, di personalizzare

direttamente dal browser i contenuti delle pagine Web; essa e

attivabile dall’apposita voce di menu di Internet Explorer, come

mostrato in figura 3.1. L’integrazione di queste funzionalita

Figura 3.1: Apertura della sidebar

all’interno del browser offre un ambiente dal quale l’utente puo avere

3.4. LA SIDEBAR ISAWIKI: UNA SOLUZIONE CLIENT-SIDE45

un semplice accesso alle informazioni di cui ha bisogno e condividere

le informazioni con gli altri utenti, senza la necessita di disporre

di particolari permessi in scrittura. La sidebar, oltre ad attivare

una serie di servizi client-side, sviluppati nell’ambito di altre tesi

da altri membri del progetto ISAWiki, sviluppa anche delle proprie

funzionalita.

La funzione principale della sidebar e quella di fungere da monitor

per qualsiasi operazione che l’utente chieda di compiere utilizzando

il browser durante la sua normale navigazione. Quello che la sidebar

vuole offrire e un ambiente integrato con il browser che permetta di:

• gestire gli eventi che accadono nella finestra principale, tenendo

continuamente aggiornato l’utente, ogni volta che una nuova

operazione e stata compiuta;

• poter accedere e modificare il contenuto della pagina che

l’utente sta visualizzando;

• attivare un editor WYSIWYG specifico per l’editazione dei

contenuti dei documenti Web;

• utilizzare delle linkbase esterne per la memorizzazione di link

su ogni pagina durante il browsing, anche su quelle su cui non

si hanno permessi di modifica;

• pubblicare sul Web i propri documenti, siano essi documenti

nuovi o personalizzati tramite l’editor;

• poter rivisualizzare le proprie pagine personalizzate ad una

successiva visita dello stesso URL;

• condividere tra piu utenti le pagine modificate ed avere accesso

alle varie versioni create di un documento.

Per offrire queste funzionalita, la sidebar ha il vantaggio di utilizzare

sempre lo stesso gestore degli eventi e di utilizzare solo tecnologie

client-side. Infatti, non viene infatti utilizzato nessun agente

intermediario tra il client ed il server. Le applicazioni server-side

vengono utilizzate per effettuare le operazioni di modifica dei


documenti, come sistemi di memorizzazione e gestione delle risorse

esterne: il server ISAWiki contiene le versioni dei documenti e il

server XLink contiene le linkbase esterne. La sidebar e un agente che

funge da mediatore tra applicazioni diverse in quanto deve gestire la:

• comunicazione con la finestra del browser;

• comunicazione con l’editor;

• comunicazione con il server ISAWiki;

• comunicazione con il server XLink.

E possibile, in qualsiasi momento, disabilitare il meccanismo di

“callback”, tramite il quale il monitor chiama il gestore degli eventi

lasciando l’utente in grado di continuare il processo di navigazione

senza utilizzare i servizi della sidebar.

3.5 Comunicazione con la finestra del

browser

Poiche la sidebar e un oggetto completamente indipendente dalla

finestra principale del browser, e stato necessario studiare un sistema

che permettesse di poter stabilire una comunicazione con la finestra

principale di Internet Explorer. Tale sistema doveva essere in grado

di poter accedere ad una serie di informazioni relative al documento

richiesto dall’utente tramite URL, indipendentemente dal dominio al

quale tale URL apparteneva, superando problemi di comunicazione,

interazione e sicurezza. Dopo una fase di ricerca, la soluzione

proposta, per superare questo problema e stata quella di realizzare la

sidebar come un’estensione del browser. In questo modo la sidebar,

sebbene sia un oggetto indipendente, risiedendo direttamente dentro

il browser, e in grado di comunicare con esso. Per gestire poi la

comunicazione con la finestra principale del browser e stato realizzato

un monitor che rappresenta il “cuore” della sidebar. Esso viene usato

per:

3.6. COMUNICAZIONE CON L’EDITOR 47

• notificare al client ogni evento che avviene nella finestra

principale del browser;

• riuscire ad intercettare l’URL non appena il documento viene

richiesto al browser e avere un completo accesso all’oggetto

Document Object Model del documento caricato nel browser;

• avere un completo controllo sulla navigazione dell’utente

mostrando all’utente le proprie pagine modificate.

Il monitor ha il compito di selezionare un event handler per ogni

determinato evento, ed attivarlo.

Il gestore degli eventi riceve la notifica dal browser stesso ogni volta

che un nuovo URL viene richiesto, prima ancora che venga eseguito il

download del documento, e ogni volta che il download del documento

e stato eseguito. In realta, il monitor riceve la notifica anche di

altri eventi relativi ad ogni cambiamento dello stato del documento

mentre viene caricato, ma nel contesto di questo progetto non e stata

avvertita la necessita di gestirli.

3.6 Comunicazione con l’editor

Il sistema ISAWiki offre un ambiente integrato con il browser

tramite il quale e possibile modificare le pagine Web senza il bisogno

di utilizzare programmi specifici per l’editazione e poi preoccuparsi di

studiare il modo per pubblicare i documenti creati, con il bisogno di

convertirli nell’apposito formato per il Web. A questo scopo e stato

sviluppato da un altro componente del progetto ISAWiki un editor

[Ors03] HTML specifico per creare dei documenti gia con l’apposito

formato per il Web e per modificarli.

La caratteristica piu importante di questo sistema di editazione e

quella di dare all’utente la possibilita di editare direttamente in place

i contenuti delle pagine Web senza modificare lo stile ed il layout delle

pagine. In questo modo, l’utente ha subito il riscontro di come le sue

operazioni modificano il documento senza il bisogno di utilizzare altri

tool esterni ma adoperando solamente il browser.


La comunicazione tra la sidebar e l’editor avviene quando l’utente

seleziona il bottone “New” o quando seleziona il bottone “Edit”,

entrambi i quali sono presenti sulla sidebar. Questi comandi

provocano l’apertura dell’editor direttamente sulla finestra del

browser. L’editor e rappresentato da una piccola toolbar contenente

al suo interno una serie di funzionalita per modificare i documenti.

Per offrire questo ambiente di editazione integrato con il browser,

inizialmente si era pensato che la sidebar dovesse compiere

un’“iniezione” dell’editor all’interno del DOM del documento, come

se l’editor facesse gia parte del documento stesso e, una volta

attivato, andasse a modificare il DOM all’interno del quale risiedeva,

ma successivamente e stata studiata una nuova soluzione. La

soluzione proposta, nell’ambito di questa tesi, prevede una completa

integrazione dell’editor all’interno della sidebar. In questo modo

l’editor viene semplicemente richiamato dalla sidebar in fase di

editazione, senza necessita di modificare ulteriormente il DOM della

pagina originale, inserendo degli script al suo interno. L’architettura

scelta prevede che l’editor operi sullo stesso DOM a cui la sidebar ha

accesso. Tale soluzione ha risolto anche problemi di comunicazione

tra window appartenti a domini diversi: la window dei documenti

visualizzati nel browser, che possono appartenere a qualsiasi dominio,

la window dell’editor e quella della sidebar.

3.6.1 Attivazione dell’editor

Un’aspetto importante del progetto ISAWiki e decidere quali parti

del documento devono essere considerate editabili; infatti, piuttosto

che permettere l’editazione della pagina Web completa, il progetto

ISAWiki segue il principio di mantenere viva la separazione tra le

aree di “contenuto” da quelle puramente ornamentali, stilistiche o di

navigazione.

Poiche l’editor del progetto ISAWiki agisce sul contenuto del

documento, e importante attivare un meccanismo per differenziare

le parti di contenuto dalle parti presentazionali della pagina. In

particolare, ogni volta che viene effettuata la richiesta di editazione


di un documento, tramite il bottone “Edit”, la sidebar attiva

un processo di analisi della pagina chiamato Extraction of Layout

Information via Structural Analysis [VCa03], che si basa su delle

euristiche sviluppate da un altro membro del progetto ISAWiki.

Questa analisi si propone di individuare il ruolo dei vari componenti

della pagina all’interno della stessa. Il risultato di questa analisi

permette di identificare quali elementi riguardano il contenuto e quali

lo stile. La sidebar riceve il risultato di tale analisi, si preoccupa di

rendere editabili gli elementi segnalati, ed evidenzia graficamente le

zone editabili in modo che vengano identificate dall’utente.

L’editor viene attivato sia quando un utente intende creare un nuovo

documento sia quando intende editarne uno gia esistente nella rete

con lo scopo di modificarlo.

3.6.2 Editazione di un nuovo documento

Dalla sidebar e possibile scegliere di creare un nuovo documento,

selezionando il bottone “New”.

Il nuovo documento viene creato a partire da un layout fornito

dal server. Dal momento che le aree per il contenuto vengono

separate da quelle presentazionali al momento della creazione del

layout stesso, per editare un nuovo documento non e necessario

attivare il meccanismo di analisi della pagina. Le zone destinate

al contenuto sono gli elementi “fvblock” del layout di ISA. L’editor

agisce solamente in queste zone editabili, evidenziate con dei bordi di

colore rosso, come mostrato nella figura 3.2. Durante la creazione di

un nuovo documento i bottoni “New” ed “Edit” vengono disabilitati.

3.6.3 Editazione di una pagina Web

Dalla sidebar e possibile richiedere l’editazione di una pagina Web

selezionando il bottone “Edit”.

L’editazione di una pagina Web, a differenza dell’editazione di un

nuovo documento, necessita del meccanismo di analisi della pagina.

Questa analisi e un processo abbastanza complesso dal momento


Figura 3.2: Editazione di un nuovo documento

che la ricerca delle parti di contenuto viene effettuta su DOM di

documenti HTML anche mal formati. Le zone editabili potranno

non esistere affatto in una pagina senza contenuto, potranno essere

molteplici o addirittura consistere in tutto il corpo del documento

nel caso in cui il documento sia completamente testuale.

Quando viene editata una pagina Web, la sidebar compie un passo

ulteriore: richiama una funzionalita implementata dall’editor per

conferire alle zone editabili, indicate dal meccanismo elISA, la stessa

struttura supportata dall’editor. Successivamente la sidebar procede

con l’attivazione e l’apertura della finestra dell’editor. Il risultato

dell’attivazione dell’editor, nel caso dell’editazione di una pagina

Web, e mostrato in figura 3.3, nella quale le zone editabili sono

evidenziate con dei bordi di colore rosso. Durante l’editazione il

bottone “Edit” viene disabilitato.


Figura 3.3: La sidebar e l’editor ISAWiki

3.6.4 Chiusura dell’editor

Dal momento che l’editor e rappresentato da una finestra sempre

attiva sul browser, la sua chiusura puo avvenire in momenti

molteplici, a seconda delle azioni compiute dall’utente, in particolare

quando:

• l’utente richiede di salvare il documento selezionando il bottone

“Save”: in questo caso la sidebar apre la finestra di salvataggio,

contenente dei campi di testo mediante i quali e possibile

specificare alcune informazioni da associare al documento.

• l’utente richiede di creare un nuovo documento selezionando il


bottone “New”: in questo caso la sidebar apre una finestra di

dialogo chiedendo semplicemente all’utente se desidera salvare

i cambiamenti prima di creare un nuovo documento. In caso

di risposta affermativa, il salvataggio viene effettuato senza

richiedere nuovamente all’utente di specificare le informazioni

da associare alla versione del documento (cioe senza aprire

nuovamente la finestra di salvataggio) ma utilizzando le

informazioni gia associate ad esso.

• l’utente richiede un nuovo URL: anche in questo caso la

sidebar apre la stessa finestra indicata nel punto precedente,

effettuando il salvataggio solo se richiesto dall’utente e

procedendo a caricare il documento richiesto dalla barra degli

indirizzi.

• l’utente chiude appositamente la finestra dell’editor: in questo

caso, si apre una finestra differente da quella indicata nei punti

precedenti. Tramite questa interfaccia, selezionando “Cancel”

viene semplicemente data all’utente la possibilita di annullare

l’operazione di chiusura dell’editor e di continuare l’editazione.

La gestione della chiusura dell’editor segue sempre i punti sopra

indicati ma nel caso in cui l’utente stia editando un nuovo documento,

invece che uno gia esistente, e stato scelto nell’ambito di questa

tesi, di effettuare l’operazione di salvataggio solo se il nuovo layout

subisce effettivamente un’operazione di modifica, altrimenti l’utente

viene rimandato all’home page del progetto ISAWiki, interpretando

il gesto come se l’utente intendesse semplicemente chiudere l’editor e

continuare la sua navigazione.

3.7 Comunicazione con il server ISAWiki

Selezionando “ISAWiki Bar” dall’apposito menu viene abilitata la

comunicazione con il server ISAWiki, offrendo all’utente la possibilita

di compiere, oltre che in maniera piu semplice i servizi offerti dal

server ISAWiki, anche alcune operazioni aggiuntive.

3.7. COMUNICAZIONE CON IL SERVER ISAWIKI 53

3.7.1 Richiesta di un nuovo documento

Uno dei momenti in cui la sidebar comunica con il server e

durante il processo di creazione di nuovi documenti in quanto il server

ISAWiki offre la possibilita di associare un layout al documento al

fine di creare una pagina Web completa. Quando l’utente seleziona

il bottone “New”, la sidebar apre una finestra di dialogo contenente

al suo interno un menu a tendina dal quale e possibile selezionare il

layout desiderato che verra applicato al contenuto della nuova pagina

Web. Per permettere all’utente di effettuare una scelta che soddisfi

sicuramente le sue esigenze, la sidebar richiede al server la lista delle

“Preview” disponibili, corrispondenti ai layout presenti sul server.

L’utente puo semplicemente scegliere, da questa interfaccia, il layout

preferito, come mostrato in figura 3.4. A questo punto la sidebar

Figura 3.4: Interfaccia per la scelta dei layout


chiede al server il layout scelto dall’utente, carica il layout nella

finestra del browser, evidenzia le parti dove l’utente puo aggiungere

il contenuto ed attiva l’editor che andra a modificare il DOM del

documento corrispondenti a queste aree.

3.7.2 Richiesta di un salvataggio

Dopo aver creato o modificato la propria pagina Web, l’utente

ha la possibilita di salvare le modifiche effettuate. In questa fase,

l’utente puo specificare una serie di metainformazioni da associare al

documento da salvare quali:

• il nome;

• l’autore;

• la lista degli utenti che hanno i permessi in lettura;

• la lista degli utenti che hanno i permessi in scrittura;

• il layout da associare al documento da salvare.

L’utente puo inserire queste metainformazioni tramite un’apposita

finestra di salvataggio, come mostrato in figura 3.5.

Il server si occupa di salvare il documento nell’apposita directory e di

modificare i dati relativi alla nuova versione del documento appena

creata.

Tramite la sidebar viene fornita la funzionalita aggiuntiva rispetto

ai servizi offerti solo lato server di poter modificare le proprieta

delle versioni intermedie, quali la rinomina e il cambio dei permessi

in lettura e scrittura, eliminando la necessita di creare una nuova

versione ed essere obbligati a ridefinirli.

3.7.3 Richiesta della lista delle versioni

Mentre l’utente sta navigando, nel caso in cui esistano delle

versioni salvate sul server della pagina richiesta dalla barra degli

indirizzi, la sidebar visualizza la lista delle versioni tramite un


Figura 3.5: Interfaccia per il salvataggio di un documento

apposito menu a tendina. Dato il numero infinito di versioni che

puo essere creato per ogni documento, sul menu viene indicata

solo l’ultima versione e le relative versioni “padre” fino alla prima

versione, come mostrato in figura 3.6. Se esistono altre versioni

oltre a quelle mostrate nel menu, e sempre possibile visualizzarne

la lista completa selezionando, sempre dal menu, la voce “more...”,

tramite la quale viene mostrata una rappresentazione grafica della

lista completa delle versioni sotto forma di albero; in questo modo,

oltre ad avere una chiara visione della genealogia del documento,

l’utente puo anche accedere alle versioni non mostrate nell’apposito

menu a tendina.

3.7.4 Richiesta di un particolare formato

Poiche il server ISAWiki ospita al suo interno un motore

di conversione [Nan03] che permette la trasformazione di un

documento in diversi formati, dalla sidebar e possibile utilizzare

questa funzionalita per richiedere la visualizzazione di una particolare

versione di un documento in un particolare formato. Tuttavia,

poiche e prevista solo l’editazione di documenti in formato HTML,

se viene richiesta l’editazione di un formato diverso da questo, la

sidebar provvede ad aprire l’editor sul rispettivo formato HTML

del documento richiesto. La richiesta del documento in un formato


Figura 3.6: Lista delle versioni

diverso da HTML e supportata solo per i documenti “interni” al

server, cioe quei documenti il cui URL appartiene allo stesso dominio

del server.

3.7.5 Richiesta della pagina personalizzata

Dopo aver creato, modificato e salvato un nuovo documento,

l’utente puo visualizzare la pagina personalizzata richiedendola

tramite URL. La comunicazione con il server ISAWiki avviene ogni

volta che un nuovo URL viene richiesto dall’utente. Intercettando

questo evento, la sidebar avvia un processo indipendente che agisce

parallelamente al normale download del documento. Questo processo


si occupa di interrogare il server ISAWiki per verificare se esiste

qualche versione della risorsa richiesta salvata precedentemente su

di esso. E’ stata scelta questa soluzione di esecuzione parallela,

proprio per rendere il sistema piu usabile da parte dell’utente, cioe

per evitare che possibili ritardi nella risposta del server o qualsiasi

altro fattore di rallentamento nella rete, possano mettere l’utente

in attesa della visualizzazione della pagina e rallentare cosı il suo

processo naturale di navigazione. Il server ISAWiki, nel caso in cui

disponga di almeno una versione del documento richiesto, interroga

l’origin server per verificare se su questo e stata eseguita qualche

modifica o aggiornamento successivamente al momento in cui tale

documento e stato personalizzato dall’utente. La risposta del server

viene analizzata dalla sidebar. Se tale documento non e presente sul

server la sidebar rimarra “silent”, altrimenti si preoccupera di far

visualizzare all’utente sempre la versione piu recente del documento

corrispondente all’URL richiesto, come mostrato nella figura 3.7. Se

Figura 3.7: Visualizzazione della pagina personalizzata


la versione piu recente e quella sul server ISAWiki, dalla sidebar

sara sempre possibile visualizzare quali sono le altre versioni del

documento e richiedere di avere accesso di nuovo ad una particolare

versione per avere eventualmente la possibilita di modificarle di

nuovo. In caso contrario dalla sidebar sara sempre possibile richiedere

la visualizzazione della pagina originale, tramite la voce “origin

server” presente nel menu a tendina.

3.8 Comunicazione con il server XLink

Selezionando dal menu presente sulla sidebar la voce “XLinkExplo

rer Bar”, e possibile accedere all’interfaccia che permette all’utente

di definire dei link multidirezionali e multidestinazione, poi visibili

anche da altri utenti, su qualunque documento pubblicato sul Web.

Le funzionalita client-side offerte dal sistema si basano sull’utilizzo

di un server esterno, che si occupa della memorizzazione degli XLink

in apposite linkbase e della restituzione di un insieme di link esterni

associati ad un particolare URL.

Analizziamo ora il set di funzionalita fornite dal sistema all’utente.

Sulla sidebar sono presenti due voci di menu distinte: una che

si occupa della gestione delle “Linkbase”, e l’altra della gestione

dell’“XLink”. Accedendo ad ognuna di queste e possibile utilizzare

delle funzionalita specifiche.

3.8.1 Creazione di una linkbase

Una linkbase e essenzialmente un file XML, risiedente sul server

XLink ed esterna all’aplicazione client, che contiene una lista

di unita di linking e di informazioni che permettono il corretto

funzionamento del sistema. Selezionando dal menu presente sulla

sidebar la voce “Create Linkbase” e possibile creare una linkbase,

che puo essere condivisa tra piu utenti. Per rendere possibile questa

operazione, la sidebar apre una finestra di dialogo contenente dei

campi di testo, come mostrato nella figura 3.8, tramite i quali e

possibile specificare il nome della linkbase, l’autore della linkbase

3.8. COMUNICAZIONE CON IL SERVER XLINK 59

Figura 3.8: Interfaccia per la creazione di una linkbase

ed un eventuale descrizione da associare alla linkbase per una piu

significativa organizzazione dei link.

3.8.2 Cancellazione di una linkbase

Selezionando dal menu presente sulla sidebar la voce “Delete

Linkbase” e possibile cancellare una linkbase esterna dalla lista delle

linkbase presenti sul server. L’operazione avviene sempre tramite una

finestra di dialogo, dalla quale l’utente puo selezionare il nome della

linkbase da eliminare e di conseguenza di tutti i link in essa definiti.

3.8.3 Creazione di un link

La fase di definizione di un nuovo link inizia selezionando un

frammento del testo presente nel documento ed attivando la voce “Set

StartPoint DestinationPoint” da un “context menu” appositamente

realizzato per la definizione degli XLink, come mostrato nella

figura 3.9. Per ogni ancora selezionata e possibile scegliere il

ruolo dell’ancora all’interno del link, cioe se il frammento della

parte selezionata dovra rappresentare un punto di partenza o di

destinazione in fase di attraversamento del link stesso. L’utente

puo effettuare questa scelta semplicemente selezionando quali devono

essere le ancore di partenza tra quelle elencate nella tabella presente

nella sidebar. Le altre, per esclusione, diventeranno automaticamente

delle destinazioni per il link.


Figura 3.9: Interfaccia per la creazione di un link

Definizione degli XPointer

Per poter identificare la posizione in cui le ancore debbano essere

collocate, lo standard XLink prevede l’utilizzo di una sintassi in

grado di specificare qualsiasi parte (o sottoparte) di un documento

XML. Questa sintassi e definita dallo standard W3C XPointer.

La sintassi offre un meccanismo di definizione di frammenti di un

documento molto potente e supporta sia tecniche di conteggio sia

meccanismi di ricerca. Gli XPointer possono essere utilizzati nella

parte fragment di un URL per definire una locazione all’interno

della risorsa identificata dall’URL. L’utilizzo di XPointer e di vitale

importanza per la realizzazione dei link e diventa pertanto necessario

per il corretto funzionamento del sistema. Per quanto riguarda la

forma di XPointer utilizzata in questo progetto si rimanda il lettore

al capitolo quattro.


Preview di un link

Selezionando dal menu presente sulla sidebar la voce “Preview

Link” e possibile richiedere la visualizzazione della preview di un link

appena creato. Selezionando questa voce viene aperta una finestra

che mostra il file XML dell’XLink creato secondo lo standard XLink

del W3C.

3.8.4 Salvataggio di un link

L’operazione di salvataggio di un link con tutte le relative

informazioni, puo avvenire sia selezionando l’item “Save Link”

dal menu relativo alla gestione dell’XLink, sia direttamente

dall’interfaccia della sidebar, selezionando il bottone “Save”. In

entrambi i casi il salvataggio avviene sulla linkbase corrente, cioe

sulla linkbase attiva sul menu a tendina, contenente la lista della

linkbase, presente sulla sidebar.

Le informazioni riguardo gli XLink creati, tramite questo sistema

di memorizzazione esterna, saranno poi rese disponibili dal server

quando verranno richieste al momento dell’inserimento dei link nel

documento.

3.8.5 Inserimento di un link

Ogni volta che un documento viene caricato, se il monitor e

abilitato, l’applicazione client interroga il server XLink che effettua

una ricerca all’interno delle linkbase di tutti quegli XLink il cui valore

dell’attributo “from” degli elementi “locator” (secondo lo standard

del W3C), ha come valore lo stesso URL del documento richiesto.

In fase di inserimento delle ancore, vengono risolti alcuni problemi al

fine di rendere consistente il processo di definizione dei link:

• conteggio del numero di ancore da inserire all’interno della

stessa risorsa;

• gestione di eventuali sovrapposizioni delle ancore;

• gestione di eventuali link innestati.


Figura 3.10: Menu visibile in fase di visualizzazione del link

E in questo momento che l’applicazione client cerca di estendere

la debolezza del modello HTML, andando ad aggiungere dei link

multidestinazione all’interno di una pagina Web su cui non si hanno

permessi in scrittura.

Quando l’applicazione client provvede all’inserimento di un link, si

occupa anche di generare un menu dinamico che diventera visibile

nel momento in cui l’utente tentera di attraversare il link definito

mediante questo framework, come mostrato in figura 3.10. Tale menu

contiene al suo interno diversi item: il titolo del link, il titolo di tutte

le altre aventuali destinazioni e le voci “Edit Link” e “Remove Link”

che saranno utilizzate dall’utente rispettivamente per l’editazione di

un link e per la sua rimozione. Nel caso in cui il titolo del link

non e stato definito, sul menu apparira la voce “No Title”. In fase

di generazione dei menu, l’applicazione verifica anche la presenza di

eventuali elementi inline gia presenti nel documento. In questo caso

le voci “Edit Link” e “Remove Link” saranno disabilitate.

3.8.6 Editazione di un link

Selezionando l’item “Edit Link” dal menu che appare quando si

vuole attraversare un link, e possibile sia modificare gli archi che

costituiscono il link, sia modificarne le proprieta di attraversamento.

Tutti le informazioni riguardo il link editato sono visibili sulla sidebar.

Ogni ancora corrisponde ad un elemento locator definito dallo

standard XLink del W3C. Per ogni locator viene indicato se questo

e un punto di partenza oppure e una destinazione. L’utente puo

definire nuovi archi, modificare quelli gia esistenti, oppure rimuoverne

3.9. IL FRAMEWORK 63

alcuni, tramite l’eliminazione di alcune locator. Per ogni locator e

possibile utilizzare il “context menu”, appositamente realizzato, dal

quale e possibile, selezionando la voce “EditLocator..”, modificare le

informazioni associate al locator. L’utente puo modificare il locator

tramite un interfaccia in cui sono presenti: il titolo del link a cui

il locator appartiene, la label che identifica il locator, l’URL della

risorsa che identifica il locator, la regola di attraversamento dell’arco

e la lista degli altri locator che costituiscono l’XLink. Sono selezionati

quei locator che rappresentano una destinazione rispetto al locator

corrente. Per ognuno di questi locator e possibile modificare le

proprieta “Show”(che definisce come debba essere visualizzato il link)

e “Actuate” (che ha la funzione di definire il momento in cui il locator

debba venire attivato).

3.8.7 Rimozione di un link

Selezionando l’item “Remove Link” dal menu che appare quando

si vuole attraversare un link, il link verra rimosso dalla relativa

linkbase e l’applicazione client provvede ad aggiornare la pagina.

3.9 Il framework

I concetti descritti fino a questo momento mostrano come sia

effettivamente possibile realizzare il sistema progettato. Nella figura

3.11 e possibile vedere il sistema nel suo complesso. La sidebar,

monitorando il processo di navigazione mantiene sempre aggiornato

il DOM del documento caricato nella finestra principale tramite

tecnologie client-side. In particolare, il client ogni volta che un nuovo

URL viene richiesto:

• inizia a caricare la risorsa dall’origin server;

• interroga il server ISAWiki chiedendo se esistono delle versioni

personalizzate della risorsa richiesta. Se esiste almeno una

versione, il server ISAWiki controlla il tempo dell’ultima

modifica del documento richiesto dall’utente sull’origin server


Figura 3.11: Il framework

e lo comunica al client. Se il documento sull’origin server ha

subito delle modifiche dopo che la pagina e stata personalizzata

dall’utente, il client lascia che venga visualizzata la pagina

originale, altrimenti si preoccupa di fornire all’utente la pagina

personalizzata, mostrando in questo modo sempre la versione

piu recente del documento richiesto tramite URL;

• interroga il server XLink per controllare se esistono dei link

associati a quel documento. Nel caso in cui essi siano presenti,

il server XLink risponde con la lista dei link da associare al

documento e il client modifica il DOM HTML del documento

in modo opportuno.

L’integrazione di queste funzionalita all’interno del browser ha il

vantaggio di offrire un ambiente integrato che consente all’utente di

accedere ai contenuti e di editare direttamente in place le pagine Web,

utilizzando il browser, senza l’intervento di un server proxy.

In questo capitolo l’attenzione e stata focalizzata principalmente

sulle scelte progettuali del sistema; sono state inoltre discusse le

singole parti che lo compongono e la loro integrazione. Nel capitolo

successivo verranno descritti tutti i dettagli implementativi e le

problematiche sorte durante la fase di realizzazione.

Capitolo 4

Implementazione delprogetto

4.1 Introduzione

Dopo aver analizzato la struttura e i princıpi sui quali il progetto

si basa, in questo capitolo vengono riportati i dettagli relativi

all’implementazione, concentrandosi sugli aspetti piu importanti.

Poiche il framework, realizzato nel corso di questo lavoro, e

costituito da varie parti integrate tra loro per offrire un ambiente

di modifica e personalizzazione dei contenuti Web, il capitolo

analizza una ad una le varie parti. Viene fornita una spiegazione

completa dell’architettura e per ogni funzionalita viene data una

descrizione degli strumenti, degli algoritmi e dei protocolli usati per

la realizzazione. Nella sezione conclusiva vengono evidenziati infine i

limiti implementativi di questa versione.

4.2 Architettura del sistema

Il sistema realizzato si basa su un’architettura client, ed e

costituito fondamentalmente da due parti: la prima e un’applicazione

che si occupa della comunicazione con la finestra principale del

browser, la seconda e costituita da una serie di script che si

occupano della comunicazione con l’editor, con il server ISAWiki e

con il server XLink. Le due parti sono fortemente dipendenti l’una

dall’altra. Non e possibile utilizzare l’editor, il server ISAWiki ed

65

66 CAPITOLO 4. IMPLEMENTAZIONE DEL PROGETTO

il server XLink, direttamente dal browser senza la comunicazione

con la finestra principale e nello stesso tempo, la comunicazione

con la finestra principale fine a se stessa non avrebbe senso di

esistere. L’applicazione fornisce l’interfaccia attraverso la quale

queste stesse funzionalita client possono essere attivate direttamente

dal browser. Ai fini di una migliore comprensione del sistema, e

importante puntualizzare qual e sul nucleo del funzionamento del

sistema e come le parti interagiscono all’interno dell’applicazione. La

sidebar comunica con la finestra principale del browser, riuscendo ad

intercettare gli eventi ed accedendo al DOM del documento caricato;

essa e rappresentata da un’interfaccia HTML e da una serie di script

Javascript che le permettono di comunicare con l’editor, con il server

ISAWiki ed il server XLink. Nel corso del capitolo viene analizzato

ogni singolo modulo del sistema.

4.3 Tecnologie utilizzate e requisiti per

il funzionamento

L’applicazione e stata realizzata mediante l’implementazione

di una Dynamic Link Libraries (DLL) scritta in Visual C++

6.0 per il browser Microsoft Internet Explorer. Essa consiste

nell’implementazione di un Explorer Bar. L’applicazione ha

un’interfaccia che, oltre a permettere la comunicazione con la finestra

principale di Internet Explorer, offre anche una serie di funzionalita

realizzate sfruttando tecnologie client-side attraverso il linguaggio

Javascript con l’ausilio delle librerie offerte dal parser Microsoft

MSXML 4.0.

Di seguito vengono indicati i programmi richiesti per poter utilizzare

tutte le funzionalita offerte dal sistema:

• versione 5.5 di Microsoft Internet Explorer;

• parser MSXML 4.0;

• server ISAWiki installato su un Web server;

• server XLink installato su un Web server.

4.4. CONFIGURAZIONE DEL SISTEMA 67

I requisiti per l’installazione il server ISAWiki ed il server XLink, non

sono argomento di questa tesi.

4.4 Configurazione del sistema

Il sistema, implementato nel corso di questa tesi, e costituito

da una directory Sidebar contenente al suo interno un’applicazione

Sidebar.dll piu una serie di directory quante sono le funzionalita

offerte dal sistema. Vediamo nel dettaglio quali sono le directory

presenti all’interno della directory Sidebar :

• sISAWiki : rappresenta la directory contenente l’interfaccia

della sidebar per il sistema ISAWiki piu una serie di script

Javascript e file in formato HTML che implementano le varie

funzionalita per il sistema ISAWiki;

• sXLink : rappresenta la directory contenente l’interfaccia della

sidebar per il sistema XLink piu una serie di script Javascript

e file in formato HTML che implementano le varie funzionalita

per il sistema XLink;

• editor : rappresenta la directory contenente gli script dell’editor

per il sistema ISAWiki;

• elISA: rappresenta la directory contenente gli script ed i fogli di

stile XSL per il sistema di Extraction of Layout Information via

Structural Analysis utilizzato all’interno del sistema ISAWiki.

Sidebar.dll e l’applicazione all’interno della quale e stato

implementato l’oggetto Explorer Bar e il monitor. L’applicazione

e stata implementata in maniera da essere indipendente dalle risorse

HTML che possono venir caricate all’interno della finestra della

sidebar. Inizialmente viene caricata la sidebar per il sistema ISAWiki,

in seguito da un apposito menu e possibile selezionare e caricare la

sidebar per il sistema XLink. Ciascuna interfaccia e rappresentata

da un file HTML e un serie di script Javascript. Le due interfacce

condividono solo il monitor implementato in C++.


Dopo la fase di installazione/registrazione della dll, l’applicazione

provvedera ad aggiungere una voce alla lista delle Explorer Bar

gia registrate nel browser. L’utente puo cosı attivare la sidebar

selezionandola dal sotto menu Explorer Bar di “View” menu presente

in Internet Explorer. L’applicazione e registrata con il nome

“ISAWiki”.

4.4.1 Brevi accenni alla tecnologia COM

Il seguente paragrafo non vuole fornire una descrizione completa

della tecnologia COM, ma solo introdurre il contesto su cui la

parte relativa l’implementazione della dll si basa. Il fine e quello

di spiegare alcuni concetti che rendano possibile la comprensione

dell’implementazione, e poter indirizzare eventuali altri studi che

proseguiranno questa ricerca.

COM e l’acronimo di Component Object Model ed e la proposta

di Microsoft per sviluppare ed utilizzare componenti. COM e

soprattutto una specifica che indica in che modo vanno costruiti

vari componenti dinamicamente intercambiabili. I componenti COM

sono costuiti da un codice eseguibile distribuito sotto forma di

dll, o sotto forma di file eseguibile (.exe), entrambi per Win32,

e si collegano in modo dinamico. In COM un oggetto puo

supportare molte interfacce. I controlli ActiveX, che si basano

su COM, supportano una serie di specifiche interfacce, la maggior

parte delle quali standard. Per permettere ad un componente di

supportare un’interfaccia e necessario implementare ogni funzione

dell’interfaccia. Per questo motivo la Microsoft ha sviluppato dei

tool e delle classi che semplificano questa operazione: la Microsoft

Foundation Class (MFC) e soprattutto le Active Template Library

(ATL). Le Active Template Library, conosciute come “parametrized

classes”, sono una collezione di template incluse in Visual C++ a

partire dalla versione 4.0.

Un oggetto COM e il suo client devono avere un modo comune

per descrivere un’interfaccia, devono cioe definire i metodi che

l’interfaccia contiene e i relativi parametri. COM mette a

4.4. CONFIGURAZIONE DEL SISTEMA 69

disposizione un modo standard per farlo tramite l’utilizzo di un

Interface Definition Language (IDL). Questo linguaggio permette

di definire completamente un’interfaccia supportata da un’oggetto.

COM distingue nettamente l’interfaccia dalla sua implementazione.

Per permettere la comunicazione tra il componente COM e

l’applicazione client, viene utilizzato il metodo dell’Automation

(OLE). L’Automation non e separata da COM, ma e costruita su di

esso. Un server Automation e un componente COM che implementa

l’interfaccia standard IDispatch. L’Automazione rende possibile

l’interazione tra controlli e contenitori. Un controller Automation

e un client COM che comunica con il server Automation attraverso

la sua interfaccia IDispatch. Il client non richiama direttamente le

funzioni implementate dal server, ma utilizza le funzioni membro

dell’interfaccia IDispatch per richiamare indirettamente le funzioni

del componente. I controlli ActiveX esportano una serie di

proprieta e metodi, attraverso questa speciale interfaccia, che sono

accessibili dalle applicazioni client. La tecnologia ActiveX si basa

principalmente sull’OLE Automation e su COM, che consente

di risolvere tutti i problemi riguardanti l’integrazione tra piu

oggetti, permettendo l’inserzione in una pagina HTML di oggetti

di diverso tipo, come componenti OLE. Un interfaccia COM viene

implementata utilizzando una vtable, cioe una tabella di puntatori.

Di conseguenza per invocare un metodo di queste interfacce e

necessario che un client attraversi la catena di tutti i puntatori inclusi

nella tabella. L’interfaccia standard di COM, IDispatch, semplifica

questo processo e diversamente dalle altre interfacce include un

metodo chiamato Invoke(), che viene invocato dall’applicazione

client per richiamare un qualunque altro metodo dell’oggetto. I

metodi che possono essere invocati sono definiti in una dispatch

interface, chiamata comunemente dispinterface o interfaccia disp.

Una dispinterface, non e altro che un gruppo di metodi che possono

essere invocati usando IDispatch::Invoke() ai quali viene assegnato

un identificativo univoco chiamato dispatch identifier (DISPID). Il

DISPID identifica una funzione, ma non e univoco, se non in una

specifica implementazione di IDispatch. Il metodo Invoke() viene


invocato per ogni istanza di documento caricato nel browser Internet

Explorer. Esso permette all’applicazione client di interfacciarsi con

gli eventi che vengono gestiti in base al DISPID.

Di seguito sara descritto come l’Explorer Bar utilizza le tecnologie

brevemente spiegate in questo paragrafo.

4.5 Realizzazione dell’oggetto Explorer

Bar

L’applicazione e stata realizzata mediante l’utilizzo delle Active

Template Library. La realizzazione dell’oggetto Explorer Bar

provvede l’implementazione e la registrazione di un band object. I

band object sono oggetti COM che esistono dentro un container.

Con il termine container vengono indicate le window che contengono

gli ActiveX. Il container dipende specificatamente dal tipo al quale

il band object appartiene. In questo caso il container e Internet

Explorer. I band object sono sono caratterizzati dal modo in cui

sono registrati e dall’interfaccia che essi espongono. La registrazione

dei componenti si basa sulla possibilita di identificarli univocamente.

I band object devono essere registrati secondo il loro appropriato

component category. La categoria determina il tipo di oggetto ed

il suo container. La Vertical Explorer Bar richiede una registrazione

di tipo CATID InfoBand. L’interfaccia e composta da una sezione

che risiede all’interno della finestra del browser.

L’Explorer Bar e stata implementata seguendo le specifiche

fornite da Microsoft Internet Explorer, pertanto la descrizione

dettagliata e completa dell’implementazione puo essere trovata in

[MSDN04a][MSDN04c]. Nei prossimi paragrafi, viene fornita una

descrizione di come e in quali punti si e riusciti ad integrare,

all’interno dell’oggetto Explorer Bar, le funzionalita relative questo

progetto.

4.6. COMUNICAZIONE CON LA FINESTRA DEL BROWSER71

4.6 Comunicazione con la finestra del

browser

La comunicazione con la finestra principale del browser e resa

possibile dal fatto che l’applicazione ospita al suo interno il Web

Browser Control che e il principale componente usato da Internet

Explorer e rappresenta un potente tool per aggiungere funzionalita

di “Internet browsing” e per accedere al DHTML Object Model di

Microsoft Internet Explorer. Il Web Browser Control e presente

nell’applicazione sotto forma di un DHTML control ed e definito

mediante l’utilizzo delle librerie ATL. L’inserimento di un DHTML

control comporta la creazione di una risorsa HTML (che rappresenta

il file HTML della sidebar) e di un interfaccia (User Interface) che

permette la comunicazione dalla risorsa HTML creata verso il codice

C++. La risorsa HTML puo chiamare alcuni metodi, implementati

nel codice C++, tramite questa User Interface, accedendovi mediante

l’oggetto "window.external" del linguaggio Javascript. Tuttavia

per realizzare le funzionalita richieste in questa tesi, e stato necessario

studiare ed utilizzare soprattutto la comunicazione dal codice C++

al codice Javascript. Questa comunicazione ha permesso di reperire

alcune informazioni e accedere ad alcune strutture che, altrimenti,

non sarebbe stato possibile recuperare utilizzando semplicemente

Javascript. Le informazioni di cui l’applicazione ha bisogno sono

infatti presenti nella struttura disparams gestita dalla funzione

Invoke(). L’Explorer Bar prima si registra al browser con lo scopo di

ricevere una notifica degli eventi relativi al download del documento,

successivamente, ogni nuova istanza di Internet Explorer lancera

un’istanza di questo oggetto ActiveX, accedendo all’interfaccia DOM

di qualsiasi documento successivamente caricato.

La notifica degli eventi e l’accesso al DOM del documento avviene

mediante il metodo Invoke() dell’interfaccia IDispatch. Tale metodo

viene invocato ogni volta che un documento viene richiesto al browser

Internet Explorer. Tale metodo utilizza un’istruzione case per

ogni DISPID associato al Web Browser Control. Ogni DISPID e

relativo ad un evento del documento. Quando l’evento avviene,


un’ apposita funzione Javascript viene invocata dal codice C++ per

gestire l’evento. Gli eventi BeforeNavigate e DocumentComplete sono

gli unici eventi gestiti in quanto ritenuti piu importanti ai fini di

questo sistema di modifica dei documenti.

4.6.1 Oggetto IWebBrowser2

IWebBrowser2 e l’interfaccia tramite la quale l’applicazione

Sidebar.dll puo controllare e ricevere notifica degli eventi

che accadono nella finestra principale. Ad ogni istanza di

Internet Explorer, l’applicazione lancia un’istanza di IWebBrowser2.

Attraverso quest’interfaccia e possibile monitorare l’attivita del

browser e compiere determinate operazioni sul documento caricato

nella finestra principale del browser. IWebBrowser2 contiene utili

metodi, proprieta ed eventi che permettono all’applicazione di

accedere all’oggetto DOM del documento caricato nella finestra

principale. Il puntatore a quest’interfaccia, usato all’interno

dell’applicazione, e definito da pWB.

4.6.2 Meccanismo di callback

Il meccanismo di callback e il procedimento mediante il quale, al

verificarsi di un evento, notificato dal metodo Invoke(), l’applicazione

invoca l’apposito gestore dell’evento, rappresentato da una funzione

Javascript presente all’interno della risorsa HTML della sidebar. Il

procedimento e possibile poiche l’applicazione, ospitando un Web

Browser Control, riesce a richiamare una funzione script presente

all’interno di una pagina Web. Visto che i gestori degli eventi

hanno bisogno di alcune informazioni a cui non e possibile accedere

tramite Javascript, l’applicazione in C++ deve fornire loro queste

informazioni mediante il passaggio di alcuni parametri dal codice

C++ al codice Javascript. Per poter effettuare questa operazione e

necessario:

• reperire il puntatore (m spBrowser) al DOM della risorsa

HTML della sidebar per poter invocare una sua apposita

funzione;

4.6. COMUNICAZIONE CON LA FINESTRA DEL BROWSER73

• invocare il metodo IDispatch::GetIDsOfNames(), per accedere

ad una tabella di nomi di funzioni e recuperare l’id della

funzione script da eseguire;

• invocare il metodo InvokeHelper() per eseguire la funzione

passandogli le opportune informazioni necessarie per poter

gestire l’evento.

Il sistema e organizzato in modo che, per ogni evento, venga sempre

chiamata la funzione Javascript CallBack() che prende in input il

nome dell’evento e restituisce il nome dell’event handler alla funzione

implementata nel codice C++. La funzione CallBack() recupera

queste informazioni dalla struttura struct event, mediante la quale

viene mantenuta l’associazione tra il nome dell’evento e il nome del

rispettivo gestore. A questo punto dal codice C++ viene invocato

l’event handler passandogli gli oppurtuni parametri di cui ha bisogno

per gestire l’evento.

4.6.3 Evento BeforeNavigate

In realta, l’uso di BeforeNavigate e deprecato poiche dalla

versione 4.0 di Internet Explorer la Microsoft ha introdotto il termine

BeforeNavigate2 per indicare lo stesso evento; fino a questo momento

e stato utilizzato il vecchio termine solo per dare piu importanza

al significato dell’evento in se, ma da questo punto in poi il nome

dell’evento verra indicato con il suo nome preciso.

Quando si verifica l’evento BeforeNavigate2, l’applicazione chiama

l’apposito gestore dell’evento. Le funzioni che vengono invocate sono

le funzioni changeUrl() e ReadUrl(). Tutte e due le funzioni prendono

in input url BeforeNavigate2 che rappresenta l’URL del documento

richiesto dall’utente. La funzione changeUrl() e stata implementata

per cambiare direttamente l’URL del documento richiesto, nel caso in

cui venga richiesta l’editazione di un documento per mezzo dell’editor

testuale. L’utilita di questa funzione sara chiarita piu avanti nei

paragrafi relativi l’editazione.

La funzione ReadUrl() e invece fondamentale per quanto riguarda


il ruolo della sidebar all’interno del progetto ISAWiki. Non appena

un nuovo URL viene richiesto, invece di attendere che il documento

venga restituito dall’origin server, la sidebar inizia a richiedere

al server ISAWiki se esistono versioni salvate riguardo l’URL

richiesto, tramite la funzione get last version(), e nel frattempo

lascia avvenire il normale download del documento. Per “simulare”

l’esecuzione di un thread indipendente la funzione get last version()

viene richiamata mediante il metodo "setTimeout()" fornito

dal linguaggio Javascript. Tale metodo attiva un processo

quasi indipendente, dal momento che il linguaggio Javascript

non e un linguaggio multithreading; tuttavia, usando il metodo

"setTimeout()" viene permesso alla sidebar di effettuare la richiesta

al server, senza bloccare il normale flusso dell’applicazione, in pratica,

senza interrompere il processo di navigazione dell’utente. Invece,

quando il tipo di documento richiesto e un documento “interno”

al server ISAWiki, la funzione get last version() non viene chiamata

tramite il metodo "setTimeout()". Un documento viene considerato

“interno” se non esiste una corrispondente versione con lo stesso nome

presente sulla rete (ad esempio: per un documento che si chiama

“tesi.html” l’unica versione esistente e quella sul server ISAWiki). La

funzione get last version() verra descritta nella sezione riguardante la

comunicazione verso il server ISAWiki.

4.6.4 Evento DocumentComplete

Quando si verifica l’evento DocumentComplete, l’applicazione

chiama l’apposito gestore dell’evento rappresentato dalla funzione

DocumentComplete(). La funzione prende in input ie che rappresenta

l’oggetto Microsoft Internet Explorer corrispondente all’interfaccia

IWebBrowser2. Utilizzando questo oggetto e possibile accedere

ai suoi metodi ed alle sue proprieta, in particolare: Document

corrisponde al Document Object Model, parentWindow rappresenta

l’oggetto window della finestra principale, LocationURL rappresenta

l’URL del documento richiesto ed il metodo Navigate() permette

di dirigere la navigazione verso una determinata risorsa. Tali

4.7. CONTROLLI DELLA SIDEBAR 75

informazioni sono memorizzate in variabili globali. Il Document

Object Model viene memorizzato nella variabile IEdocument ; tale

oggetto corrisponde all’oggetto document di Javascript, ma in piu

mette a disposizione dei metodi e delle proprieta aggiuntive ereditate

dall’interfaccia IWebBrowser2.

Nel caso in cui il documento contenga dei frame, la variabile

IEdocument contiene un’istanza per ogni DOM di ciascun frame.

4.7 Controlli della sidebar

Sebbene le funzionalita offerte dalla sidebar, prese singolarmente

siano di semplice implementazione, tuttavia la gestione dell’aggiorna-

mento costante delle informazioni presenti sulla sidebar e del monitor

e stato un processo leggermente piu delicato.

Dal momento che il “ritmo” di funzionamento della sidebar viene

scandito dagli eventi che accadono nella finestra principale, legati

al download del documento, e di conseguenza dagli event handler

che vengono richiamati, e stato necessario, per quanto riguarda la

realizzazione della sidebar ISAWiki, utilizzare alcune variabili globali

booleane per mantenere lo stato del controllo ad ogni operazione

richiesta. La maggior parte di queste variabili sono state introdotte

per gestire la chiusura della toolbar dell’editor.

Di seguito vengono spiegate quali sono quelle piu importanti ed in

quali punti del programma sono state utilizzate ai fini di una migliore

comprensione dei dettagli implementativi:

• change format : utilizzata per non eseguire nuovamente

l’interrogazione al server della lista delle versioni nel caso in

cui viene semplicemente richiesto un altro formato;

• change version: utilizzata per non eseguire nuovamente

l’interrogazione al server della lista delle versioni nel caso in

cui viene semplicemente richiesto un altra versione;

• controlled : utilizzata per non eseguire nuovamente l’interrogazione

al server dopo che la pagina personalizzata viene caricata al

posto della versione presente sull’origin server;


• cntrl : utilizzata nella comunicazione con il codice C++ per

gestire la presenza di frame nel documento, sincronizzando

gli eventi BeforeNavigate2 e DocumentComplete. Infatti, nel

caso di un documento con frame, al verificarsi dell’evento

BeforeNavigate2 il programma C++ non e in grado di

distinguere l’URL del frameset da quello dei singoli frame.

Per questo motivo, quando viene letto l’URL del frameset

(e il primo ad essere letto), la variabile cntrl viene settata

al valore “1”, impedendo di chiamare ulteriormente l’handler

dell’evento BeforeNavigate2 anche per i singoli frame. Al

verificarsi dell’evento DocumentComplete invece, la sidebar,

riuscendo a distinguere tra le istanze del frameset e quelle

dei singoli frame (tramite la proprieta IEwindow.top), quando

avviene il download del frameset, riassegna alla variabile cntrl

il valore “0”. In questo modo il processo di lettura dell’URL

avviene correttamente, poiche al download del frameset, che si

verifica per ultimo, la sidebar riassegna alla variabile cntrl il

valore originale, rendendo possibile continuare a leggere l’URL

dei documenti successivi;

• ed : utilizzata per controllare l’apertura e la chiusura dell’editor;

• edit layout : utilizzata per indicare se si sta effettuando

l’editazione su un documento memorizzato sul server che ha

una propria struttura di layout gia definita;

• iw url : indica se l’URL corrente appartiene al dominio del

server ISAWiki, ed in tale caso assume valore “true”. Serve

per identificare il tipo di documento richiesto, distinguendolo

da un documento presente sull’origin server;

• list ver : utilizzata per indicare se un documento ha delle

versioni associate presenti sul server;


4.8 Comunicazione con l’editor

Per quanto riguarda la comunicazione con l’editor, la soluzione

proposta e gia stata accennata nel capitolo precedente, ma in questo

paragrafo sara spiegata nel dettaglio descrivendo anche come e stata

implementata.

L’editor e costituito da alcuni file Javascript inclusi nel HTML

della sidebar ed esso manipola il DOM del documento usando

l’oggetto IEdocument visto dalla sidebar. In questo modo l’editor

riesce ad accedere al documento caricato nella finestra principale.

Inoltre, nel caso in cui un documento contenga dei frame, l’editor

ha accesso anche ai singoli frame, indipendentemente dal dominio

del documento, ma in questo caso e stato necessario risolvere un

problema di accesso alle window dei singoli frame. Infatti, sebbene

la sidebar, riesca ad accedere ad ogni possibile istanza del DOM di

ogni frame, la stessa cosa non avviene per l’oggetto window. Al

verificarsi di qualche evento (come "onclick" per esempio), l’editor

non riusciva a riconoscere in quale window l’evento avveniva, non

potendo utilizzare la proprieta "window.event.srcElement". Per

risolvere questo problema, tramite la funzione ricorsiva add my id()

viene assegnato un attributo frameId ad ogni frame presente

nel documento. In questo modo l’editor, tramite la funzione

set active element() e in grado di ritrovare il frame attivo ogni

volta che si verifica l’evento "onclick", sfruttando ora la proprieta

"activeElement" di Javascript che basa la ricerca del frame attivo

sull’utilizzo dell’oggetto document invece che window. Il frame puo

dunque essere identificato dal frameId, precedentemente inserito.

4.8.1 Attivazione dell’editor

L’editor viene attivato mediante la funzione Edit(). Esistono

due modi per rendere editabile un documento, a secondo del tipo

di documento da editare: tramite la funzione EditLayout() oppure

tramite la funzione EditOriginServer(). L’editazione di una pagina

HTML e resa possibile utilizzando la proprieta "contentEditable"

disponibile dalla versione 5.5 del browser Microsoft Internet Explorer.

Le parti del documento da editare vengono inserite all’interno di

elementi .

L’attivazione dell’editor prevede le seguenti fasi:

• analisi della pagina;

• trasformazione di determinati elementi in elementi editabili;

• apertura dell’editor.

Analisi della pagina

Per determinare quali sono gli elementi da rendere editabili

all’interno del documento, viene attivato il meccanismo di analisi

della pagina, di cui si e parlato nel capitolo precedente. Il

meccanismo di analisi della pagina viene attivato invocando la

funzione elISAstart(). Questa funzione, prende in input il DOM

del documento da analizzare e restituisce un array costituito da

due elementi. Per poter effettuare tale analisi, il meccanismo

elISA ha bisogno di trasformare il DOM del documento originale

in un DOM ben formato secondo le regole XML. Tale DOM viene

memorizzato nella prima posizione della struttura restituita dalla

funzione elISAstart() alla sidebar. Nella seconda posizione invece,

la funzione elISAstart() memorizza una struttura che permette alla

sidebar, in fase di scansione del documento, di identificare quali

sono gli elementi da rendere editabili. La struttura restituita dal

meccanismo elISA e memorizzato nella variabile elISA list. Tale

struttura e un array bidimensionale in cui per ogni elemento vengono

memorizzate le seguenti informazioni:

• numero identificativo del nodo all’interno del documento: in

fase di analisi il meccanismo setta un attributo "N" per

identificare in modo univoco ogni elemento di tipo nodo

all’interno del DOM;

• nome del tag del nodo di cui alcuni figli devono essere resi

editabili;

• indice del primo figlio del nodo che deve essere reso editabile;

• indice dell’ultimo figlio del nodo che deve essere reso editabile.

Gli ultimi due punti permettono di identificare il range di nodi che

devono essere resi editabili.

Trasformazione di determinati elementi in elementi editabili

Di seguito viene mostrato un esempio di come viene utilizzata la

struttura elISA list :

[10, TD, 3, 5]

[10, TD, 8, 13]

L’esempio indica che, prima e necessario identificare l’elemento:

<TD N="10">

Successivamente i suoi figli, dal terzo al quinto (estremi compresi),

devono essere inseriti all’interno di un elemento di questo tipo:

.

Tale elemento SPAN deve essere poi inserito nella terza posizione,

rispetto alla “collection” dei figli del nodo TD, mentre i figli 3, 4 e

5 del nodo TD sono ora all’interno del nodo SPAN e non piu diretti

figli di TD. Lo stesso algoritmo viene utilizzato per rendere editabili

dall’ottavo al tredicesimo figlio come indicato nella struttura, tenendo

presente pero che l’inserimento dello SPAN precedente ha modificato

la lista dei figli del nodo TD. Tale algoritmo e implementato nella

funzione insertSpan cE().

Prima di poter considerare gli elementi indicati dal meccanismo

elISA effettivamente editabili, viene compiuta un’altra operazione

dalla sidebar, cioe quella di richiamare una funzionalita dell’editor

mediante la quale viene attivato un processo di conversione degli

elementi in un formato supportato dall’editor. Quest’ultima fase

viene sempre compiuta entro la stessa scansione del documento e

viene attivata mediante la funzione converti().

Apertura dell’editor

L’editor ISAWiki e rappresentato da una toolbar che consente

all’utente di utilizzare alcune funzionalita. L’editor viene attivato

richiamando le funzioni initEditor() e eventEditor(). Queste funzioni

sono implementate all’interno degli script Javascript dell’editor, ma

al fine di una migliore comprensione del funzionamento del sistema,

mi limito a spiegare che la prima delle due funzioni provvede

all’apertura ed al caricamento dell’editor e la seconda associa agli

eventi del documento (ad esempio "onclick", "onkeypress") i

rispettivi handler. E per questo motivo che se all’interno di un

documento sono presenti dei frame, la sidebar richiama la funzione

initEditor() una sola volta su tutto il documento, e la funzione

eventEditor() su ogni frame.

4.8.2 Editazione di un documento del server

ISAWiki

Un documento salvato sul server ISAWiki ha associato uno dei

layout del server, scelto dall’utente. L’editazione di questo tipo di

documenti avviene tramite la funzione EditLayout().

L’identificazione delle zone editabili e molto semplice dal momento

che sfrutta il principio su cui si basa il sistema stesso della separazione

tra il layout ed il contenuto insita nella struttura del documento di

ISAWiki. I documenti salvati sul server, infatti, contengono degli

elementi di tipo DIV con attributo "type" con valore "fvblock"

creati appositamente per contenere le parti di contenuto della pagina.

Dunque, la funzione EditLayout(), si limita ad inserire gli elementi

 all’interno di questi specifici

DIV, in modo tale da rendere tutto il loro contenuto editabile, a meno

di alcuni elementi DIV con attributo "id" con valore "userMenu"

o "adminMenu", creati appositamente dal sistema per scopi diversi

dall’editazione.

4.8.3 Editazione di un documento dell’originserver

L’editazione di un documento presente nella rete e stata

implementata nella funzione EditOriginServer().

L’algoritmo eseguito da questa funzione e esattamente quello

descritto nel paragrafo 4.8.1. Una volta effettuato il salvataggio


sul server, al documento viene associato uno dei layout di ISAWiki

e, ad una successiva rieditazione, le zone editabili saranno quelle

corrispondenti alle zone "fvblock".

4.8.4 Chiusura dell’editor

Ogni volta che la window dell’editor viene chiusa, viene provocato

l’evento "onunload" e viene sempre richiamata la funzione closeIt()

ad esso associata.

Tale funzione, dopo aver effettuato opportuni controlli, richiama la

funzione closeIt editor() solo nel caso in cui la window dell’editor

viene esplicitamente chiusa dall’utente. Nei casi in cui, invece,

l’utente richiede di effettuare altre operazioni senza aver prima

provveduto a chiudere l’editor, e la sidebar che si preoccupa

di gestire la chiusura dell’editor, permettendo poi all’utente di

continuare a svolgere le operazioni richieste. Ogni volta che l’editor

viene aperto viene mantenuto un riferimento alla sua window, che

viene memorizzato nella variabile ed. Tale variabile e dunque

sufficiente per indicare se l’editor e aperto o meno, anche se e

stato necessario introdurre altre variabili per controllare le varie

situazioni in cui l’editor viene chiuso. La funzione closeIt editor()

utilizza un’istruzione case per distinguere il caso in cui (“new”)

l’editor e stato aperto per creare un nuovo documento, dal caso in

cui (“document”) l’editor e stato aperto dall’utente per modificare

una versione del documento precedentemente salvata sul server o

una pagina Web presente nella rete. In entrambi i casi, viene

aperta la finestra di dialogo “closeEditor1.html”, assumendo dei

comportamenti diversi a seconda del verificarsi di uno dei due casi

precedenti. Mediante la finestra di dialogo l’utente puo scegliere di:

• salvare le modifiche al documento: nel caso della creazione di

un nuovo documento, viene attivata la fase di salvataggio, solo

nel caso in cui vengano apportate delle modifiche al layout,

aggiungendo del contenuto, altrimenti, in ambito di questa tesi

e stato ritenuto non significativo permettere anche il salvataggio

di layout vuoti, dal momento che essi sono gia disponibili sul


server (la funzione title new() e stata implementata a questo

scopo). Invece, quando viene editata una versione precedente

o un documento dalla rete, viene richiamata la funzione

Save(), che provvede al salvataggio e alla visualizzazione del

documento appena salvato, mediante la maschera della finestra

di salvataggio;

• non salvare le modifiche al documento: nel caso della

creazione di un nuovo documento, viene richiamata la funzione

DefaultPage(), che rimanda l’utente all’home page principale

del progetto ISAWiki. In questo modo vengono riattivati i

bottoni della sidebar e viene permesso all’utente di continuare

la sua navigazione. Nel caso di editazione di una versione

precedente o di un documento della rete viene richiamata

la funzione NotSave() che provvede invece a ricaricare il

documento, senza salvare le modifiche;

• annullare l’operazione di chiusura dell’editor: viene richiamata

la funzione reload editor(), implementata dall’editor, che

provvede a riaprire l’editor ed a riportarlo allo stato precedente

la sua chiusura.

Nei casi in cui l’operazione della chiusura dell’editor non venga

effettuata esplicitamente dall’utente, ma e la sidebar che si preoccupa

di provvedere alla sua chiusura, la funzione closeIt editor() non viene

richiamata. Sono state implementate altre funzioni a tal proposito

che tengono sempre conto del tipo di documento che l’utente stava

editando, un nuovo documento, oppure un documento esistente.

Di seguito vengono indicate le diverse operazioni che l’utente puo

compiere dopo aver richiesto la creazione di un documento:

• chiedere esplicitamente di salvare il documento mediante

l’apposito bottone: in questo caso il documento viene salvato

mediante la funzione Save() e subito rivisualizzato;

• chiedere un nuovo URL dalla barra degli indirizzi: in questo

caso nella funzione ReadUrl(), tramite il valore della variabile

open ed new, verra chiamata la funzione closeIt hidden() che

provvedera a chiudere l’editor e a richiedere all’utente se intende

o meno salvare il documento creato precedentemente, tramite la

finestra di dialogo “closeEditor2.html”. In caso di salvataggio

il documento modificato non viene visualizzato nella finestra

principale, all’interno della quale viene invece caricato il nuovo

documento.

Nel caso in cui invece l’utente stava editando un documento gia

esistente, l’utente, oltre che compiere le due azioni descritte nei punti

precedenti, puo anche eseguire le seguenti operazioni:

• chiedere di creare un nuovo documento;

• chiedere, dall’apposito menu a discesa (nel caso in cui questa

funzionalita sia supportata dal server per il tipo di documento

corrente), la visualizzazione del documento in un altro formato;

• chiedere, dall’apposito menu a discesa, la visualizzazione di

un’altra versione del documento.

Anche in questi casi, la sidebar presenta la stessa finestra di dialogo

descritta precedentemente, comportandosi poi in modo diverso a

seconda dei casi descritti: salvare e caricare un nuovo documento

oppure salvare, visualizzare il documento salvato e poi aprire la

finestra per la scelta del layout.

4.8.5 Salvataggio di un documento

Prima di effettuare il salvataggio di un documento creato con

l’editor sul server ISAWiki, vengono rimossi alcuni elementi e

attributi introdotti in fase di editazione, dalla sidebar dal meccanismo

elISA e dall’editor. Per poter effettuare questa operazione, la sidebar

effettua una scansione di tutto il documento ed in particolare,

mediante la funzione remove ed layout() vengono eliminati i seguenti

elementi e attributi che hanno attivato il processo di editazione:

• elemento : introdotto dalla

sidebar per poter conferire l’editabilita ai nodi;


• attributo "N": introdotto dal meccanismo elISA per identificare

quali sono i nodi editabili.

Mediante la funzione remove ed elements(), invece, vengono eliminati

gli elementi introdotti dall’editor per poter manipolare il contenuto

degli SPAN editabili. La funzione remove ed elements() viene

richiamata solo all’interno degli SPAN editabili. L’editor introduce

alcuni elementi solo nella creazione e modifica degli elementi di tipo

“table”e “record” (la descrizione di questo tipo di oggetti non e

ambito di questa tesi). Gli elementi introdotti in queste due strutture

sono ulteriori SPAN con l’attributo "contentEditable" settato a

“true” o a “false” a seconda dei casi per effettuare l’editazione degli

oggetti di tipo “table” e degli oggetti di tipo “record”.

All’interno delle celle di entrambi queste due strutture, viene

inoltre richiamata la funzione update tag name() che si preoccupa

di conferire al contentuto di tipo testuale delle celle un formato

accettabile dal motore di conversione del server ISAWiki.

4.9 Comunicazione con il server ISAWiki

La comunicazione con il server ISAWiki permette di utilizzare

molti servizi del server.

4.9.1 Richiesta di un nuovo documento

Quando l’utente vuole creare un nuovo documento, viene richiesta

al server la lista dei layout disponibili, tramite la funzione NewDoc(),

mediante una GET con la seguente sintassi:

http://serverISAWiki/isawiki.php?Styles

indicando con “serverISAWiki” il dominio dove il server ISAWiki

(“isawiki.php”) risiede. L’output della richiesta e un documento in

formato XML contenente la lista dei nomi dei layout.

Tramite la finestra di dialogo fornita dal file “Layouts.html” viene

fatta una richiesta al server delle preview dei layout disponibili. La


richiesta viene effettuata nella funzione view layout().

La sintassi utilizzata per questo tipo di richiesta e del seguente tipo:

http://serverISAWiki/ files/Styles/Preview/nomeLayout pre

view.formato

Dal momento che la visualizzazione delle preview e una funzionalita

nuova offerta dalla sidebar, si e stabilito, sviluppando questo

progetto, che il nome della preview associata al layout e costituito dal

nome del layout e dalla parola "preview", separati dal carattere " ".

Per il momento le preview sono disponibili solo in formato “bmp”

ma sicuramente il sistema verra esteso per supportare anche altri

formati.

Una volta selezionato un layout dall’utente, la visualizzazione del

layout avviene mediante una richiesta al server del tipo seguente:

http://serverISAWiki/EMPTYDOC/nomeLayout

La presenza del termine "EMPTYDOC", indica all’applicazione che

si desidera creare un documento vuoto. L’applicazione provvede

dunque alla visualizzazione del layout richiesto mediante il metodo

Navigate() dell’oggetto IWebBrowser2. La sidebar riconosce,

tramite la funzione parseUrl() che il documento caricato e un

layout del server, pertanto non compie nessuna azione nell’evento

BeforeNavigate2 ma provvede solo a rendere editabile il layout

dopo che esso e stato caricato cioe al verificarsi dell’evento

DocumentComplete.

4.9.2 Richiesta di un salvataggio

La richiesta di salvataggio di un documento viene implementata

mediante la funzione Save(). Il salvataggio viene effettuato mediante

un POST HTTP al server ISAWiki, tramite un form HTML di

tipo “hidden”. Il campo "action" del form e dato dall’URL del

documento stesso.


Il form deve contenere la variabile POST Editor che viene utilizzata

dal server per ricevere la richiesta via POST HTTP e compiere

il servizio di salvataggio di un documento. Inoltre il form deve

contenere le seguenti variabili:

• POST Editor docname: rappresenta il nome del documento da

salvare;

• POST Editor author : contiene l’autore della modifica, nel caso

in cui non sia specificato il server considera come autore del

documento il possessore del file system;

• POST Editor readperm: rappresenta la lista degli utenti che

potranno accedere in lettura al documento. E formata da un

elenco di nomi separati da una virgola;

• POST Editor writeperm: rappresenta la lista degli utenti che

potranno accedere in scrittura al documento. E formata da un

elenco di nomi separati da una virgola;

• POST Editor content : rappresenta il contenuto del documento

in formato HTML;

• POST version number : rappresenta il numero della versione a

partire dal quale deve essere calcolato il numero della nuova

versione da creare;

• POST Editor layout : indica il nome del layout con il quale

viene salvato il documento.

I valori di queste variabili sono tutti modificabili mediante la

mascherina di salvataggio che viene mostrata all’utente, ad eccezione

naturalmente del campo POST version number che viene utilizzato

dal server per calcolare il numero corretto della versione da creare.

Esso e dato dal numero di versione che l’utente sta correntemente

visualizzando.

Le informazioni mostrate all’utente nella mascherina di salvataggio

vengono recuperate dalla sidebar dal file XML contenente le

informazioni riguardo la corrente versione del documento richiesto.


Nel caso in cui l’utente non stia modificando una versione gia

esistente ma stia salvando un nuovo documento, tali campi saranno

vuoti e l’utente puo provvedere ad inserirne di nuove. La funzione

Save() utilizza un’istruzione case per distinguere i casi nei quali

il documento appena salvato deve subito essere visualizzato nella

finestra principale, dagli altri nei quali il documento appena salvato

non viene rivisualizzato all’utente. Nel primo caso, la funzione

Save() provvede ad aprire la finestra di dialogo “SaveInfo.html”

contenente la mascherina delle informazioni. I valori delle variabili

relative alle informazioni per il salvataggio vengono spediti al server

mediante la funzione Save post r(). Il documento salvato viene

visualizzato nella window principale il cui valore dell’attributo

"name" e “browser window”. In questo caso il server risponde

con la visualizzazione del documento appena salvato. Nel secondo

caso invece, i dati vengono spediti al server mediante la funzione

Save Post h(). Cosı facendo viene permesso all’utente di effettuare

il salvataggio e di continuare la sua navigazione o effettuare altre

operazioni (come ad esempio la creazione di un nuovo documento).

4.9.3 Richiesta della lista delle versioni

Non appena un nuovo URL viene richiesto dall’utente, la sidebar,

tramite la funzione parseUrl() controlla il tipo di URL richiesto

dall’utente. Dal tipo di URL e possibile riconoscere la provenienza

del documento. Il documento puo essere stato creato direttamente

all’interno di ISAWiki oppure modificando un documento dalla rete.

In questo secondo caso esiste nella rete un documento con lo stesso

nome di quello salvato sul server. Nel primo caso, la variabile globale

iw url viene settata a “true”. Nel secondo caso, invece, la sidebar

interroga il server ISAWiki, tramite la funzione get last version(),

richiamata mediante il metodo "setTimeout()" di DHTML. La

funzione get last version() interroga il server ISAWiki mediante la

seguente sintassi:

http://serverISAWiki/isawiki.php?doc req=documento.html

&Versions

La risposta ricevuta dal server e in formato XML, ed e del seguente

tipo:

<?xml version="1.0" ?>

<versions file="file/tesi.html" id="405444257f198"

author="Roberta Zeppilli">

<last version="1.0" />

<readPerm value="Roberta Zeppilli, Angelo Di Iorio" />

<writePerm value="Roberta Zeppilli" />

<version date="Sun, 8 Mar 2004 12:38:13 +0100"

format="html" version="1.0" author="Roberta Zeppilli"

p="3" q="1">



p="4" q="1" />



p="7" q="2" />

</version>

</versions>

Solo il nodo <version> contiene dati specifici di una versione, gli

altri contengono informazioni globali al documento. Le proprieta

globali del documento sono rappresentate dai valori dei seguenti

attributi:

• file (del nodo <versions>): rappresenta il nome del

documento;

• id (del nodo <versions>): rappresenta l’identificativo

univoco associato al documento;

• author (del nodo <versions>): rappresenta l’autore della

prima versione;

• version(del nodo <last>): rappresenta il numero della

versione settata come predefinita;

• value (del nodo <lastPerm>): rappresenta la lista di coloro

che hanno permessi di lettura;

• value (del nodo <writePerm>): rappresenta la lista di coloro

che hanno permessi di scrittura.

La sidebar recupera tali informazioni mediante la funzione

file Versions(). Semplicemente leggendo il valore dell’attributo file

del nodo <versions> e possibile verificare se sul server esiste qualche

versione del documento richiesto dall’utente. Se tale attributo ha

valore uguale al vuoto significa che il server ISAWiki non ha nessuna

versione del documento, altrimenti da questo valore e possibile

estrapolare, oltre che il nome, anche il tipo del documento. Una

volta ricavate queste informazioni, viene settata la variabile list ver

al valore “true” se il documento ha versioni associate, al valore

“false” altrimenti. Le informazioni riguardo il nome ed il tipo del

documento vengono memorizzate in un’apposita struttura info file.

In particolare i campi di questa struttura contengono:

• info file[0]: valore originale dell’attributo "file";

• info file[1]: il tipo di documento;

• info file[2]: il nome del documento;

• info file[3]: il nome del documento senza formato;

• info file[4]: il formato del documento richiesto.

Per quanto riguarda il tipo di documento, il server ISAWiki indica

di tipo “file” quei documenti creati internamente al sistema e

risiedenti nel deposito “file” del sistema. Invece il server tratta

come di tipo “http” quei documenti ottenuti modificando qualche

documento dalla rete, ed il nome del protocollo usato (“http”)

appare nel nome del documento stesso. Nel caso in cui esistano

versioni sul server del documento richiesto, viene costruita la


lista delle versioni che verra visualizzata in un apposito menu a

tendina, tramite la funzione update sel versions(). La funzione

permette solo la visualizzazione di un sottoinsieme dei numeri delle

versioni dei documenti. La visualizzazione dell’albero completo

delle versioni e realizzata mediante l’applicazione di un foglio di

stile XSL al file XML delle versioni. Quando viene richiesta

una particolare versione, nell’URL appare tale numero di versione,

in quanto l’URL termina con un " " seguito dal numero della

versione del documento richiesto. L’assenza di tale informazione

nell’URL, indica che la versione richiesta e l’ultima versione del

documento. La funzione get version format() si preoccupa di reperire

tali informazioni dall’URL.

4.9.4 Richiesta di un particolare formato

L’utente puo selezionare dall’apposito menu a tendina il formato

richiesto e l’applicazione mediante la funzione convert() che effettua

una richiesta di tipo GET al server. E il server poi che si occupa

di eseguire la conversione nel formato richiesto dall’utente. La

richiesta rispetta il numero di versione che l’utente sta attualmente

visualizzando e viene effettuata mediante la seguente sintassi:

http://serverISAWiki/documento.formato versione

Nel caso in cui il numero di versione non venga specificato verra

visualizzata l’ultima versione creata del documento.

Editazione di un particolare formato

In fase di editazione, quando viene richiamata la funzione Edit(),

viene controllato che il formato del documento di cui e stata richiesta

l’editazione. Infatti, poiche l’editor presente nella sidebar e un editor

di pagine HTML, se viene richiesta l’editazione di un documento

in un formato diverso dall’HTML, la sidebar provvede a caricare

il rispettivo formato HTML, tramite la funzione convertToHtml()

e dopo che il download del formato HTML e stato completato la

sidebar provvede a caricare l’editor.

4.9.5 Richiesta della pagina personalizzata

Ogni volta che un nuovo documento viene richiesto, la sidebar ha

il compito di mostrare all’utente sempre l’ultima versione. La ricerca

dell’ultima versione viene effettuata solo per i documenti presenti

nella rete, per verificare se esiste una versione piu recente rispetto

alla pagina personalizzata salvata dall’utente. Per individuare tale

informazione e necessario accedere alle proprieta specificate per ogni

nodo <version>. Oltre agli attributi classici del nodo relativo

ad una versione puo essere presente anche un attributo ulteriore

"extern" con valore “true”, come nell’esempio seguente:

<version date="Sun, 8 Mar 2004 12:10:05 GMT" format="html"

version="1.1" author="Unknown" extern="true" />

In questo caso, la sidebar carica la pagina dall’origin server, al posto

di quella personalizzata. Nel caso contrario, la sidebar provvede

a visualizzare l’ultima tra le pagine personalizzate dall’utente,

mediante la funzione rewrite content(). Tale controllo viene

implementato nella funzione req versions() che ha il compito anche

di aggiungere al menu a tendina delle versioni anche il collegamento

alla pagina sull’orgin server. In questo modo, quando avviene

l’evento DocumentComplete, la sidebar aggiorna il display mostrando

all’utente la versione piu recente del documento personalizzato,

oppure rimane inattiva nel caso in cui non esistano versioni di quel

documento salvate sul server. Dal momento che la comunicazione

client-server inizia all’evento BeforeNavigate2, se questa e molto

veloce e se non si verificano ritardi, la sidebar e gia in grado di fornire

l’ultima versione senza aggiornamenti del display.


4.10 Comunicazione con il server XLink

Il progetto realizzato fornisce un’interfaccia tramite la quale

e possibile creare link multipartenza e link multidestinazione. E

possibile accedere a tale interfaccia selezionando dal menu “Open”

presente nella sidebar la voce “XLinkExplorer Bar”. L’interfaccia

e rappresentata dal file “sidebar xlink.html”. All’interno di questa

risorsa HTML, sono inclusi una serie di script Javascript mediante

i quali sono state implementate le funzionalita del sistema che

utilizzano un determinato protocollo di comunicazione con il server

XLink.

La sidebar per la creazione degli XLink, utilizza la stessa applicazione

per la gestione degli eventi che accadono nella finestra principale della

sidebar ISAWiki. Per questo motivo, dal momento che i princıpi di

funzionamento sono sostanzialmente gli stessi tra le due sidebar, si

e cercato di riutilizzare il piu possibile i nomi di alcune variabili

globali, di alcune strutture e degli event handler attribuendo loro

precisamente lo stesso significato attribuito per la sidebar ISAWiki,

proprio per mantenere il sistema coerente e consistente.

4.10.1 Il server XLink

L’applicazione client utilizza un server esterno per la memorizzazio

ne degli XLink e la gestione delle linkbase, denominato

“XLinkserver”. XLinkserver [Mon04] e stato implementato mediante

il linguaggio PERL ed e rappresentato dal modulo “xlinkserver.pl”

risiedente in una directory del Web-server.

Il server XLink permette la gestione di una o piu linkbase.

Il modulo e costituito dai seguenti componenti:

• lo script che costituisce il server vero e proprio (“xlinkserver.pl”);

• le linkbase vere e proprie, in formato XML;

• la linkbase-list, una lista in formato XML di tutte le linkbase

gestite dal server.

Il server ha solo la funzionalita di gestire il “database” degli XLink,

ed e l’applicazione client che si occupa della modificare del DOM del

documento. -

4.10.2 Protocollo di comunicazione client-server

XLink

Il protocollo di comunicazione con il server XLink si basa

sull’utilizzo di query-string mediante le quali vengono specificati il

tipo di operazioni da eseguire ed i parametri dati in input.

La sidebar effettua le seguenti operazioni che sono gestite dal server

e che vengono specificate nella query-string tramite il optype:

• append : permette di aggiungere un link ad una linkbase o di

aggiornarne uno precedentemente inserito;

• query : restituisce tutti gli XLink contenuti in una certa

linkbase relativi ad un determinato URL;

• remove: elimina dalla linkbase un XLink specifico;

• getlink : restituisce un dato XLink selezionandolo tramite il suo

identificativo;

• newlb: crea una nuova linkbase vuota;

• remlb: rimuove dal server una determinata linkbase;

• getlb: restituisce una data linkbase dal server selezionato;

• linkbase: restituisce la lista delle linkbase.

La sintassi utilizzata per la comunicazione verso il server e la

seguente:

http://../xlinkserver.pl?<query-string>

Il client deve specificare, tramite <query-string>, il tipo di

operazione da eseguire.


4.10.3 Lista delle linkbase

Il sistema non prevede l’esistenza di una linkbase unica, ma

puo memorizzarne un numero arbitrario. La “linkbaselist” e un

documento XML che mantiene un’entrata (elemento linkbase) per

ogni linkbase memorizzata. La linkbaselist viene creata e gestita

automaticamente dal server. La linkbaselist ha un attributo nextId

che identifica la linkbaselist univocamente.

4.10.4 Creazione di una linkbase

La linkbase e un file XML identificato da un attributo lbref che

identifica l’id della linkbase e coincide con l’attributo id del nodo

linkbase all’interno della linkbaselist.

La creazione di una linkbase avviene mediante una richiesta al server.

La query-string utilizzata segue la seguente sintassi:

optype=newlb&name=lbname&author=authorname

dove "lbname" e "authorname" indicano rispettivamente il nome

della linkbase specificato dall’utente e l’autore della linkbase da

creare.

Richiesta del client

Il client deve fornire i seguenti parametri attraverso la

query-string da inviare al server, nel caso della creazione della

linkbase:

• newlb: valore da specificare per la querystring optype per

indicare al server il tipo di operazione da eseguire;

• name: nome mnemonico della linkbase (parametro obbligatorio);

• author : autore della linkbase (parametro obbligatorio);

• desc: descrizione della linkbase (parametro facoltativo).


La creazione della linkbase, viene effettuata mediante la funzione

CreateLinkBase(). Questa funzione, provvede ad aprire la finestra di

dialogo “CreateLinkBase.html”, tramite la quale vengono recuperate

le informazioni dall’utente; successivamente viene effettuato l’invio

dei dati al server tramite query-string, mediante la funzione

postXML().

Risposta del server

Il server risponde con un documento XML, contenente la linkbase

vuota aggiunta; l’attributo lbref di tale linkbase rappresenta il

linkbaseId con cui il client potra successivamente referenziare la

linkbase. Il documento viene arricchito di un attributo context con

valore newlb.

Il client, nella funzione postXML(), controlla che l’operazione di

creazione della linkbase venga effettuata correttamente.

4.10.5 Cancellazione di una linkbase

La cancellazione di una linkbase avviene mediante una richiesta

al server utilizzando la seguente sintassi:

optype=rmlb&linkbaseId=Idlinkbase

dove "Idlinkbase" indica l’identificativo della linkbase da eliminare.



query-string da inviare al server:

• rmlb: valore per la query-string optype mediante il quale viene

specificata la richiesta di rimozione di una linkbase;

• linkbaseId : valore relativo il numero della linkbaseId da

eliminare.

Il client effettua la cancellazione della linkbase mediante la funzione

DeleteLinkbase(). Questa funzione, provvede ad aprire la finestra di


dialogo “DeleteLinkBase.html”, tramite la quale vengono recuperate

le informazioni dall’utente per poter effettuare la cancellazione;

successivamente viene effettuato l’invio dei dati al server tramite

query-string, mediante la funzione postXML().

Risposta del server

Il server risponde con un documento XML, contenente la linkbase

rimossa. Viene aggiunto un attributo context con valore rmlb.

Il client verifica, mediante la risposta del server, che l’operazione

di cancellazione della linkbase e stata eseguita correttamente,

verificando che il valore dell’attributo context, sia diverso da

“invalidLinkbase”.

4.10.6 Definizione di un XPointer

L’implementazione di un sistema basato sull’utilizzo di XLink

necessita di un sistema di puntamento per definire una qualunque

locazione (un nodo, un punto o un range) che identifichi in maniera

efficace un qualsiasi frammento di documento. Tale sistema sistema

viene poi utilizzato per identificare nuovamente in maniera esatta la

posizione del frammento su cui deve essere inserita l’unita di linking.

XPointer e il linguaggio proposto dal W3C ideato appositamente

a questo scopo. Tuttavia XPointer, al contrario di XLink, non e

ancora una Recomandation, per questo motivo, non esistono ancora

implementazioni complete. Inoltre per il browser Internet Explorer,

non sono disponibili delle librerie che permettano di generare degli

XPointer, a partire da dei frammenti di un documento HTML.

Nel progetto XLinkProxy, il suo ideatore Federico Folli, aveva gia

implementato delle librerie che cercassero il piu possibile di sfruttare

tutte le potenzialita offerte riguardo le specifiche proposte dal W3C.

Tuttavia il progetto XLinkProxy, lavorando su documenti XML,

rende piu semplice la definizione di XPointer secondo le specifiche

del W3C. Nell’ambito di questa tesi, si vuole offrire la possibilita di

poter manipolare qualsiasi tipo di documento, anche mal formato,

utilizzando un sistema di definizione degli XPointer efficace per


definire delle possibili unita di linking. Tuttavia, dal momento che

uno degli scopi di questa tesi e quello di offrire un ambiente di

linking distribuito, si e preferito concentrare le energie su questa

problematica, piuttosto che sviluppare una libreria full-compliant con

le specifiche del W3C. La sintassi di XPointer e molto potente e

supporta sia tecniche di conteggio sia meccanismi di ricerca, per cui

e estremamente adatta a questo scopo. Il prototipo implementato in

questa tesi, quindi, cerca di sfruttare al massimo tutta la potenza del

linguaggio XPointer ma utilizza una sintassi molto semplificata.

Il calcolo degli XPointer

Tra le possibili forme di XPointer definite dal W3C, il progetto

realizzato nell’ambito di questo lavoro, ne utilizza uno in particolare

in quanto e quello considerato abbastanza espressivo per definire le

locazioni dove inserire l’XLink all’interno di documenti HTML, anche

mal formati. La forma di XPointer utilizzata e la forma string-range,

che permette di indentificare un intervallo all’interno di un particolare

nodo o insiemi di nodi. Questa funzione ha la seguente sintassi

secondo le specifiche del W3C:

string-range(location-set, string, number?, number? )

il parametro location-set indica i nodi da analizzare, string permette

di specificare la stringa da ricercare ed il terzo ed il quarto parametro

vengono utilizzati per identificare gli estremi degli intervalli.

In particolare: string-range identifica il range calcolando la locazione

di una data stringa letterale all’interno di un testo o di qualche

nodo. Il terzo argomento indica la posizione del primo carattere nella

stringa risultante, relativamente all’inizio del match della stringa nel

documento. Il valore di default e “1”, e fa in modo che il range

inizi immediatamente prima del primo carattere della stringa da

identificare. Il quarto argomento indica il numero di caratteri nel

range: il valore di default e “1” che estende il range alla fine della

stringa con cui fare match.


Dal momento che il browser Internet Explorer non e provvisto di una

libreria che permetta di definizione degli XPointer, e stato necessario

implementare alcune funzioni per poter utilizzare lo standard XLink.

Di seguito viene mostrato un esempio della forma di XPointer

utilizzata nell’ambito di questa tesi:

#xpointer(/html[1]/body[1]/p[3], "", 10, 7)

l’esempio indica che l’ancora del link e localizzata nel terzo nodo p

figlio del nodo body, figlio a sua volta della radice. Inoltre il terzo ed il

quarto parametro forniscono un’identificazione precisa del frammento

di documento che deve essere inserito all’interno di un’ancora del

link. Il range di definizione, in questo caso, inizia al decimo punto

dall’inizio della stringa contenuta all’interno del nodo p ed e lungo

sette caratteri.

Le funzioni relative la generazione dello XPointer sono:

• getXpath(): una funzione ricorsiva che dato il nodo padre della

selezione restituisce l’XPath dalla radice al nodo dato in input;

• getXpointer(): una funzione che prende in input il range della

selezione e restituisce il punto di inizio della selezione e la

lunghezza della selezione.

l’XPointer completo viene poi costruito a partire dall’URL del

documento corrente con l’aggiunta dell’XPointer calcolato mediante

le funzioni precedenti.

4.10.7 Creazione di un XLink

L’utente puo iniziare la fase di creazione di un nuovo XLink

selezionando dall’apposito menu la voce “NewLink”. Questa

operazione attiva la chiamata alla funzione NewLink(), mediante la

quale, vengono eliminati dalla tabella presente sulla sidebar, tutte le

ancore precedentemente inserite. Viene inoltre compiuta una fase di

inizializzazione di alcune strutture da utilizzare per la gestione degli


XLink.

Prima di costruire l’XLink sotto forma di documento XML, viene

richiamata la funzione buildArcList() mediante la quale viene

costruita la lista degli archi dopo aver definito quali sono le ancore

di partenza e quali quelle di destinazione. La generazione dell’XLink

avviene mediante l’implementazioni delle seguenti funzioni:

• XLinkExt(): funzione che costruisce l’elemento extended in

formato XML, contenente la lista degli elementi locator e degli

elementi arc. Per ogni elemento extended vengono settati i

seguenti attributi: type, role, title. Il valore dell’attributo type e

necessariamente “extended” per gli elementi extended e locator

per gli elementi di tipo locator ;

• XLinkArc(): funzione che costruisce la lista degli elementi di

tipo arc in formato XML. Per ogni arco vengono settati i

seguenti attributi: type, arcrole, title, show, actuate, from, to;

• XLinkAppend(): funzione che costruisce l’XLink da spedire al

server.

Il documento XML non e altro che una mini-linkbase, senza attributi

nextId e lbref dalla quale saranno estratti i nodi extended (e relativi

figli) e saranno appesi nella linkbase identificata dal parametro

linkbaseId. Il server inserisce nella linkbase specificata tramite

query-string tutti i nodi contenuti nella linkbase passata tramite

POST. I nodi extended posso avere valorizzato un attributo id,

in tal caso l’elemento extended non viene inserito nella linkbase

ma sovrascrive l’elemento extended contenuto nella linkbase avente

quel determinato id. Qualora l’elemento extended non abbia

l’Id valorizzato il sistema si preoccupa di generarne uno univoco

all’interno della linkbase specificata e procedere ad appendere il link

alla linkbase.

Preview di un XLink

Quando l’utente seleziona dall’apposito menu la voce “PreviewLink”,

il client chiama la funzione PreviewLink(). Tale funzione genera un


XLink, a partire dalla lista degli archi e visualizza l’XLink mediante

la finestra di dialogo “PreviewLink.html”.

4.10.8 Salvataggio di un XLink

L’inserimento di un XLink creato nella linkbase indicata avviene

mediante una richiesta al server utilizzando la seguente sintassi:

optype=append&linkbaseId=Idlinkbase

dove "Idlinkbase" indica l’id della linkbase dove inserire l’XLink.



query-string da inviare al server:

• append : valore per la query-string optype mediante il quale

viene specificato la richiesta di inserimento di un link;

• linkbaseID : valore relativo il numero della linkbase sulla quale

effettuare l’operazione di “append”;

• XLink: il link da inserire essere passati tramite http POST

sotto forma di documento XML.

Risposta del server

Il server, oltre a modificare la linkbase inserendo il link spedito

tramite POST HTTP, ritorna un documento XML, contenente i

soli link aggiunti (un sottoinsieme della linkbase contente i soli

nodi extended aggiunti o sovrascritti). La linkbase ritornata viene

arricchita di un attributo “context=append ” per comunicare al client

a che tipo di richiesta e relativa la risposta ricevuta dal server.

4.10.9 Inserimento di un XLink

L’inserimento dei link esterni nel documento prevede le seguenti

fasi:


• interrogazione delle linkbase;

• creazione della lista dei link;

• inserimento delle ancore.

Quando il client recupera la risorsa dall’origin server, effettua

delle interrogazione al server XLink per verificare se sulle linkbase ci

sono dei link relativi la risorsa richiesta.

Il client invia la richiesta al server secondo la seguente sintassi:

optype=query&linkbaseId=Idlinkbase&url=startUrl

dove "Idlinkbase" indica l’identificativo della linkbase su cui

effettuare la query e "startUrl" indica l’URL per il quale vengono

ricercati i link da inserire al suo interno.


L’interrogazione al server XLink viene effettuata mediante la

funzione query(). Per ogni arco il valore dell’attributo “from” e

uguale all’URL richiesto dall’utente viene

Risposta del server

Il server risponde con un documento XML contenente i soli

link aggiunti (un sottoinsieme della linkbase contenente i soli nodi

extended aggiunti o sovrascritti). La linkbase ritornata viene

arricchita di un attributo “context” con valore “append” per

comunicare al client a che tipo di richiesta e relativa la risposta del

server.

Inserimento delle ancore

La fase dell’inserimento delle ancore prevede la trasformazione

dell’informazione memorizzata sugli XLink in un link o in un insieme

di link che siano interpretabili dal browser. E necessario pertanto,

prima costruire la lista dei link da inserite e memorizzarli in delle

strurre apposite. La lista dei link viene costruita a partire dalla


funzione CreateListLinks(). Successivamente viene chiamata la

funzione getXptr(), per pettere di ritrovvare il frammento della risrsa

definito mediante l’utilizzo di Xpointer().

La mancanza di librerie per la manipolazione degli Xpointer e

stata avvertita anche in questa fase. Infatti e stato necessario

implementare la funzione getRange() che dato l’XPointer permette di

calcolare il range a cui fa riferimento. Dopo aver calcolato eventuali

sovrapposizioni delle ancore con la funzione IntersectRange(), si

procede con l’inserimento dei link nella risorsa mediante la funzione

InsertLink().

4.10.10 Editazione di un XLink

L’editazione di un link avviene mediante le funzione EditLink()

che permette di attivare l’editazione dei vari elementi locator che

costituiscono il link e anche di aggiungere altri elementi locator ai

link precedentemente definiti.

4.10.11 Rimozione di un XLink

Il client invia la richiesta al server per la rimozione di un Xlink

secondo la seguente sintassi:

optype=remove&linkbaseId=Idlinkbase&linkId=Idlink

dove "Idlinkbase" indica l’identificativo della linkbase da cui

rimuovere il link e "Idlink" indica l’identificativo del link da

rimuovere.


Oltre i dati nella query string relativi ad optype, lo script prende

in input:

• linkId : specifica l’id del link (nodo extended) da rimuovere/editare;

• linkbaseId : specifica l’id della linkbase che contiene il sopra

indicato link.

4.11. LIMITI IMPLEMENTATIVI 103

Risposta del server

Lo script ritorna in output un documento Xlink, sempre

sottoforma di linkbase con un attributo aggiuntivo “context=remove”,

contenente i nodi extended aventi l’Id specificato (nel caso di

REMOVE il server procedere anche alla rimozione del nodo dalla

linkbase). Nel caso in cui il linkId non venga trovato nella linkbase

specificata viene ritornata una linkbase vuota, che il client potra

interpretare come “linkId - non trovato”.

La rimozione di un XLink avviene mediante la funzione

RemoveLink() che provvede alla rimozione di un XLink e a ricaricare

il documento dall’origin server e provvede al calcolo degli XLink

ancora presenti nel documento.

4.11 Limiti implementativi

In questo paragrafo verranno discussi i limiti implementativi

riscontrati durante la fase di implementazione e test del sistema. Essi

possono essere cosı schematizzati:

• si potrebbe cercare di velocizzare il piu possibile la fase di

interrogazione del server ISAWiki, per evitare che l’utente si

trovi di fronte ad un aggiornamento del display quando viene

visualizzata la risorsa personalizzata invece che quella originale;

• la fase di inserimento e di editazione dei link multidestinazione

non e pienamente supportata. La mancanza di librerie

per la gestione degli XPointer per Internet Explorer e la

caratteristica di lavorare con documenti mal formati rendono

questa operazione particolarmente delicata e necessita dunque

di una revisione.

Capitolo 5

Conclusioni e sviluppi futuri

Sebbene il World Wide Web sia un sistema in continua evoluzione,

esso presenta ancora delle carenze che impediscono il pieno

sfruttamento delle proprie potenzialita e non permettono all’utente

di poter soddisfare ogni propria esigenza e/o necessita. L’enorme

quantita d’informazioni che passa attraverso il Web avrebbe bisogno

di essere gestita meglio, e questo porta a sviluppare negli utenti un

bisogno di condivisione. Molte ricerche si sono preposte l’obiettivo di

far fronte a questi limiti, tuttavia nessuna di esse e riuscita ad offrire

all’utente un sistema ipertestuale completo.

Si vuole fare in modo che l’utente utilizzi il Web non solo come

semplice mezzo di pubblicazione, ma anche come mezzo di gestione

ed organizzazione dei propri dati e documenti personali. Tuttavia

per dare forma a questa avanzata visione del Web, sarebbe sbagliato

pensare di realizzare ex-novo un sistema alternativo, da sostituire

a quello gia esistente: questa evoluzione e possibile semplicemente

sfruttando la corrente architettura del World Wide Web, i protocolli

ed i tool gia esistenti. In ragione di cio, questo lavoro e stato

realizzato aggiungendo semplicemente delle funzionalita al browser,

tramite semplici interfacce e senza ricorrere all’utilizzo di agenti

intermediari che potrebbero interferire con il naturale processo di

navigazione dell’utente.

Riteniamo che il prototipo proposto in questa dissertazione possa

essere largamente diffuso visto che puo essere utilizzato in modo

semplice e, quel che piu conta, non richiede all’utente conoscenze

105

106 CAPITOLO 5. CONCLUSIONI E SVILUPPI FUTURI

di strumenti che vadano al di la di quelle di base.

Durante lo svolgimento di questo lavoro sono venuti alla luce molti

aspetti che potrebbero essere sviluppati in futuro:

• sarebbe interessante poter integrare i sistemi di memorizzazione

esterna utilizzati per la modifica dei documenti, in modo

tale che il client possa avere accesso ad un unico server

per la gestione dei documenti e delle linkbase. Questo

sistema permetterebbe all’utente anche di creare dei link esterni

sulle varie versioni personalizzate offrendo al client un unica

interfaccia per la personalizzazione dei contenuti

• il sistema prevede l’utilizzo di un’applicazione monitor comune

alle interfacce presenti nella sidebar, mediante la quale, ogni

volta che si verifica un determinato evento, viene ricercato

e richiamato il suo apposito gestore. Il sistema andrebbe

riprogettato per fare in modo che la fase di registrazione degli

event handler avvenga solamente nella fase di inizializzazione

dell’applicazione. In questo modo, conoscendo gia quale

event handler richiamare, l’applicazione sarebbe piu veloce e

portabile per l’utilizzo di altri gestori degli eventi presenti in

altre eventuali interfacce della sidebar.

• attualmente, se la finestra della sidebar viene chiusa, la sidebar

continua a monitorare la navigazione solo entro la stessa istanza

di Internet Explorer. Dal momento che la sidebar, o le toolbar

in generale, occupano una porzione dello schermo rispetto

al contenuto della pagina, sarebbe necessario ridurre il piu

possibile lo spazio occupato da questi oggetti per aumentare

quello del contenuto della pagina vero e proprio. Una soluzione

potrebbe essere quella di fare in modo che la toolbar continui

a svolgere le sue funzionalita ma rimanendo nascosta per

aumentare lo spazio di visualizzazione della finestra del browser.

• per estendere le funzionalita di modifica dei documenti si

107

potrebbe inserire anche un meccanismo per creare delle

annotazioni sulle pagine.

• sarebbe interessante studiare un sistema tale per cui, tenendo

nota degli URL piu richiesti dall’utente, vengano aggiunti

del link sulla sidebar; una sorta di “generazione automatica

di bookmark” che possa essere utilizzata dall’utente per

avere accesso immediato alle informazioni utilizzate piu

frequentemente.

• attualmente, per la definizione delle ancore di partenza e di

destinazione dei link e stato realizzato un “context menu”

apposito che permette di gestire le parti di documento

selezionate. Sarebbe utile integrare questa funzionalita

all’interno del “context menu” di Internet Explorer proprio per

completare il processo di integrazione del sistema con il browser

stesso e poter utilizzare entrambi i menu contemporaneamente.

Considero il lavoro svolto molto interessante poiche il framework

realizzato potrebbe aiutare gli utenti a strutturare le proprie attivita

quotidiane ed a facilitare la navigazione, stimolando anche i meno

esperti ad avvicinarsi all’uso delle tecnologie informatiche. Inoltre,

ritengo che continuare questo trend di sviluppo di tool standard

usabili per tutti sia cruciale per un futuro progresso del Web.

108 CAPITOLO 5. CONCLUSIONI E SVILUPPI FUTURI

Bibliografia

[Alt04] “AltaVista toolbar”, 2004,http://www.altavista.com/toolbar/, ultima visita: 9 marzo 2004.

[Ale04] “Alexa toolbar”, 2004, http://www.alexatoolbar.com/,ultima visita: 9 marzo 2004.

[Ama96] “Amaya”, W3C, 1996, http://www.w3.org/Amaya/, ultimavisita: 9 marzo 2004.

[Ann02] “Annozilla (Annotea on Mozilla)”, W3C, 2002,http://annozilla.mozdev.org/, ultima visita: 9 marzo2004.

[Ari04] “Arianna toolbar”, 2004, http://arianna.libero.it/toolbar/,ultima visita: 9 marzo 2004.

[AM02] Ashman H., Martin D., “Goate: XLink and beyond”, in:Proceedings of the thirteenth ACM conference on Hypertextand Hypermedia, College Park, Maryland, USA, ACM, 2002,142-143.

[BFF99] Berners-Lee T., Fielding R., Frystyk H., Gettys J.,Leach P., Mogul J.C., Masinter L., “Hypertext TransferProtocol–HTTP/1.1”, Request for Comments 2616, 1999,http://www.ietf.org/rfc/rfc2626.txt.

[BKM97] Barrett R., Kellem C.D., Maglio P.P., “How to Personalizethe Web”, in: Proceedings of the SIGCHI conference onHuman factors in computing systems, Atlanta, Georgia,United States, ACM, 1997, 75-82.

[BM98] Barrett R., Maglio P.P., “Intermediaries: New Places forproducing and manipulating Web Content”, in: Proceedingsof the Seventh International World Wide Web Conference(WWW7), Brisbane, Australia, Elsevier, 1998.

[BPS04] Bray T., Paoli J., Sperberg-McQueen C. M., MalerE., Yergeau F., “World Wide Web Consortium:Exstensibile Markup Language (XML) 1.0 (Third

109

110 BIBLIOGRAFIA

Edition)”, W3C Recommendation 4 febbraio 2004,http://www.w3.org/TR/REC-xml.

[Bou99] Bouvin N.O., “Unifying strategies for Web Augmentation”,in: Proceedings of the tenth ACM Conference on Hypertextand Hypermedia: returning to our diverse roots, Darmstadt,Germany, ACM, 1999, 91-100.

[BVA97] Vitali F., Bieber M., Ashman H., Balasubramanian V.,Oinas-Kukkonen H., in: “Fourth Generation Hypermedia:Some Missing Links for the World Wide Web”, InternationalJournal of Human-Computer Studies, 47, Academic Press,1997, 31-65.

[Bus45] Bush V., “As We May Think”, The Atlantic Monthly,176(1), 1945, 101-108.

[CCB97] Crespo A., Chang B.W., Bier E.A.,“Responsive Interactionfor a Large Web Application: The Meteor ShowerArchitecture in the WebWriter II Editor”, in: Selected papersfrom the sixth international conference on World Wide Web,Santa Clara, California, United States, Elsevier SciencePublishers Ltd., 1997, 1507-1517.

[Cha02] Charalampos V.D., “The process of personalizing webcontent: techniques, workflow and evaluation”, 2002,http://citeseer.ist.psu.edu/538278.html.

[CHB03] Christen B.G., Hansen F.A., Bouvin N.O., “Xspect:bridging open hypermedia and XLink”, in: Proceedings ofthe twelfth international conference on World Wide Web,Budapest, Hungary, ACM, 2003, 490-499.

[CFG99] Carter S., Faizi A., Goland Y., Jensen D., WhiteheadE., “HTTP Extensions for Distributed Authoring- WEBDAV”, Request for Comments 2518, 1999,http://www.ietf.org/rfc/rfc2518.txt.

[CFR02] Vitali F., Ciancarini P., Folli F., Rossi D.,“XLinkProxy:external linkbases with XLink”, in: Proceedings of the2002 ACM symposium on Document Engineering, McLean,Virginia, USA, ACM, 2002, 57-65.

[CHM03] Carr L., Miles-Board T., Hall W., Kampa S., “SupportingManagement Reporting: a Writable Web Case Study”, in:Proceedings of the twelfth international conference on WorldWide Web, Budapest, Ungary, ACM, 2003, 234-243.

BIBLIOGRAFIA 111

[Cun02] Cunningham W., The Wiki Way: Collaboration and Sharingon the Internet, New York, Pearson Education, 2002.

[DFH92] Davis H.C., Fountain A.M., Hall W., Heath I.,“MICROCOSM: An Open Hypermedia Environmentfor Information Integration”, in: Hypertext: concepts,systems and applications, Cambrige University Press, 1992,298-311.

[DDG02] De Rose S., Daniel R., Grosso P., Maler E., Marsh J., WalshN.,, “XML Pointer Language (XPointer) ”, W3C WorkingDraft, 16 agosto 2002, http://www.w3.org/TR/xptr/.

[DMO01] De Rose S., Maler E., Orchard D., “XML Linking Language(XLink) Version 1.0”, W3C Recommendation, 27 giugno2001, http://www.w3.org/TR/xlink/.

[DMV04] Vitali F., Di Iorio A., Montemari G., “Beyond proxies:XLink support in the browser”, 2004, submitted forpubblication.

[DV00] Denoue L., Vignollet L., “An annotation tool for Webbrowsers and its applicaions to informal retrieval”, in:Actes de RIAO2000 Recherche d’information assistee parordinateur, Paris, France, 2000, 180-195.

[DV04] Di Iorio A., Vitali F., “Writing the Web”, in: Journal ofDigital Information, 2004, accepted for publication.

[DVV04] Vitali F., Di Iorio A., Ventura C.E., “Rule-based structuralanalysis of web pages”, 2004, submitted for publication.

[EP00] Etzioni O., Perkowitz M., “Towards Adaptive WebSites: Conceptual Framework and Case Study”, ArtificialIntelligence, 118(1-2), Elsevier Science Publishers Ltd.,2000, 245-275.

[Eng68] Engelbart D.C., “A Research Center for Augmenting HumanIntellect”, in: Proceedings of the Fall Joint ComputerConference (IFJC), 33, Arlington (VA), IEEE, 1968,395-410.

[EV03] Eirinaki M., Vazirgiannis M., “Web Mining for WebPersonalization”, in: ACM Transactions on InternetTechnology, 3(1), ACM, 2003, 1-27.

[Fan03] Fantini G., Editing Collaborativo: Architettura e Servizi,Tesi di Laurea in Informatica, Universita di Bologna, Isessione 2003.

112 BIBLIOGRAFIA

[Goo04] “Google toolbar”, 2004, http://toolbar.google.com/, ultimavisita: 9 marzo 2004.

[GSO99] Grønbæk K., Sloth L., Ørbæk P., “Webvise: Browserand proxy support for open Hypermedia structuringmechanisms on the World Wide Web”, in: Proceedings of theEighth International World Wide Web Conference, Boston,Toronto, Canada, Elsevier North-Holland, 1999, 1331-1345.

[Her03] Herder E., “Modeling User Navigation”, in: Proceedings ofthe 9th International Conference on User Modeling (UM2003), 2702, Johnstown, PA, USA, 2003, 417-419.

[HB04] “HotBot toolbar”, 2004, http://www.hotbot.com/tools/,ultima visita: 9 marzo 2004.

[Koi01] Koivunen M.R., “The Annotea Project”, in: Proceedingsof the tenth international conference on World Wide Web,Hong Kong, ACM, 2001, 623-632.

[MMD00] Millard D.E., Moreau L., Davis H.C., Siegfried R.,“FOHM:a Fundamental Open Hypertext Model for InvestigatingInteroperability between HyperText Domains”, in:Proceedings of the eleventh ACM on Hypertext andhypermedia, San Antonio, Texas, United States, ACM,2000, 93-102.

[Mon04] Montemari G., Progetto e implementazione di un sistemadi linking distribuito per Mozilla basato su XLink, Tesi diLaurea in Informatica, Universita di Bologna, III sessione2004.

[MM97] Miller R., Myers B.A.,Creating Dynamic World Wide WebPages By Demostration, Carnegie MellonUniversity Schoolof Computer Science, CMU-CS-97-131 e CMU-HCII-97-101,1997.

[MSDN04a] Microsoft Corp., “Adding Explorer Bars”, MS DeveloperNetwork, 2004, http://msdn.microsoft.com/library/workshop/browser/ext/tutorials/explorer.asp.

[MSDN04b] Microsoft Corp., “Explorer Bar Style Guide”, MS DeveloperNetwork, 2004, http://msdn.microsoft.com/library/workshop/browser/ext/overview/explorer bar style.asp.

[MSDN04c] Microsoft Corp., “Creating Custom Explorer Bars, ToolBands, and Desk Bands”, MS Developer Network, 2004,http://msdn.microsoft.com/library/enus/shellcc/platform/Shell/programmersguide/shell adv/bands.asp

BIBLIOGRAFIA 113

[MSW02] Modjeska D., Schraefel M.C., Wigdor D., Zhao S., Zhu Y.,“Hunter Gatherer: Interaction Support for the Creationand Management of Within-Web-Page Collections”, in:Proceedings of the eleventh international conference onWorld Wide Web, Honolulu, Hawai, USA, ACM, 2002,172-181.

[Nan03] Nanni P., Editing Collaborativo: Motore di Conversione,Tesi di Laurea in Informatica, Universita di Bologna, IIsessione 2003.

[Nel65] Nelson T.H., “A File Structure of the Complex, theChanging, and the Indeterminate”, in: Proceedings of the20th National ACM Conference, Cleveland (OH), ACM,1965, 84-100.

[Nel87] Nelson T.H., Literary Machines, Sausalito (CA), USA,Mindful Press, 1987.

[Nel99] Nelson T.H., “Xanalogical Structure, Needed Now Morethan Ever: Parallel Documents, Deep Links to Content,Deep Versioning, and Deep Re-Use”, in: ACM ComputingSurveys, 31(4), ACM Press, 1999, 1-33.

[Ors03] Orselli S., Editor strutturato per documenti HTMLintegrato in un Content Management System: Progetto edImplementazione, Tesi di Laurea in Informatica, Universitadi Bologna, III sessione 2003.

[Pre04] “Preference toolbar”, 2004, http://www.xulplanet.com/downloads/prefbar/, ultima visita: 9 marzo 2004.

[Pin97] Ping K.Y., “CritLink Mediator”, Foresight Institute,http://crit.org/, 1997.

[Rada91] Rada R., Hypertext: From Text to Expertext, McGraw HillPublishers, 1991.

[Ree01] Rees M.J.,“Evolving the Browser Towards a Standard UserInterface Architecture”, in: Third Australasian conferenceon User interfaces, Melbourne, Australian ComputerSociety, 7, 2002, 1-7.

[Riz97] Rizk A., Sutcliffe D., “Distributed Link Service in theAquarelle project”, in: Proceedings of the eighth ACMconference on Hypertext, Southampton, United Kingdom,ACM, 1997, 208-209.

[Sca04] Scano R., “XStandard”, 2004, http://xstandard.com, ultimavisita: 9 marzo 2004.

114 BIBLIOGRAFIA

[Teo04] “Teoma toolbar”, 2004, http://sp.ask.com/docs/teoma/toolbar/, ultima visita: 9 marzo 2004.

[Ult04] “UltraBar toolbar”, 2004, http://www.ultrabar.com/,ultima visita: 9 marzo 2004.

[VCa03] Ventura Campori E., Estrazione di informazioni di layoutattraverso analisi strutturale nelle pagina HTML, Tesi diLaurea in Informatica, Universita di Bologna, III sessione2003.

[Vit03] Vitali F., “Created sophisticated Web sites using well-knowninterfaces”, in: HCI International 2003 Conference, Creta(Grecia), 2003.

C:/Documents and Settings/robi ... - Tesi < Fabio's...

Documents

Transcript of C:/Documents and Settings/robi ... - Tesi < Fabio's...