Skip to topic | Skip to bottom
Home
TechWeb06
TechWeb06.HydraliskDocsr1.19 - 04 Jul 2006 - 13:44 - JacopoZingonitopic end

Start of topic | Skip to actions

Documentazione

DrillTeam | Relazione del progetto HYDRALISK

Il portale di libri Hydralisk è stato implementato seguendo le specifiche stabilite dai protocolli. Per lo scripting server-side abbiamo optato per il linguaggio di programmazione PHP (versione 5) mentre e' stato impiegato Javascript per la sezione Client-side. Il parsing e la creazione di documenti XML vengono eseguiti tramite DOM. Il portale interagisce con l'operato dei seguenti gruppi: Team 42 (DS, DF: Latek e XHTML), The Final Team (DF: XHTML), Lotus (DS), Turtlein Rulez (DS) e Findability for All (DF: XHTML).

1. Data Source

I due datasource sono di tipo storage: uno composto da 100 schede(approfondite) di genere fantasy, e l'altro da circa 25.000 schede di tutti i generi. Sono accessibili dai seguenti link:

1.1 Le schede

Ogni scheda e' stata definita in linguaggio XML e codificata in UTF-8 nel rispetto delle specifiche stabilite dal protocollo DS. Le schede sono state validate attraverso il RelaxNG fornito dalle specifiche.

1.2 La ricerca

Per effettuare una ricerca nel DS è stato deciso di implementare uno script in PHP5 che naviga all'interno di un indice (in formato XML) appositamente creato per tale scopo. Lo script di navigazione e' basato sulla libreria PHP simpleXML per velocizzare la ricerca date le notevoli dimensioni dell'indice.

1.3 L'elenco

L'indice su cui lo script di ricerca agisce, non e' altro che un elenco contenente le informazioni che abbiamo voluto indicizzare. Con questo sistema, una volta che lo script di ricerca ha terminato, avremo ottenuto anche un elenco benformato pronto per essere inviato in output. La gestione di piu' elenchi (quando ad esempio si interrogano diversi datasource) avviente tramite uno script che processa ogni elenco ricevuto aggiungendo un identificativo univoco per ogni voce in modo da poter distinguere il datasource di appartenenza.

1.4 La scheda

Ogni scheda viene identificata da un id che e' generato in modo tale da poter risalire al file fisico sull'harddisk. Semplicemente il datasource invocato, legge l'id che gli e' stato richiesto e quindi va a prendere la scheda corrispondente.

2. Data Formatter

I nostri dataformatter gestiscono correttamente il content model misto e la rimozione degli elementi duplicati che questo comporta. Gli URL per accedere sono:

I formatter sono strutturati in modo tale da permettere facili implementazioni di nuovi layout, grazie alle "API" di accesso generico, come per la formattazione del testo. In pratica e' presente un foglio di stile per ogni singola "sezione" del documento da formattare, in modo tale da poter gestire al meglio la formattazione completa e parziale dei documenti senza inutile duplicazione di codice.

3. Application Controller

3.1 Server-side

Si tratta di uno script PHP che riceve diversi parametri "di configurazione" da una richiesta GET. Questa configurazione viene poi parsata per capire cio' che e' stato richiesto, quindi vengono interrogate le parti interessate.

E' interessante notare che sebbene inizialmente era prevista la gestione di questi parametri tramite cookies, e' stata rimossa a causa di un'incompatibilita' dell'URL del portale con alcuni browser, che quindi non ricevevano i cookies. A questo punto e' nata una parte dell'application controller che si preoccupa di aggiornare i link generati nella pagina in modo che mantengano tutte le informazioni necessarie quali ad esempio skin e layout. Con questo sistema e' possibile quindi cambiare formatter, skin o layout mantenendo visualizzate le stesse informazioni.

Grazie alla politica object-oriented che permea l'intero progetto, e' possibile aggiungere e rimuovere nuove componenti senza troppi oneri.

3.2 Client-side

Questo application controller comprende diverse componenti, indipendenti tra di loro e per questo ancora una volta e' facile aggiungere o rimuovere funzionalita'.

E' interessante notare come questo application controller non sia alto che una trasposizione del codice PHP in JavaScript.

Anche qui infatti esistono delle classi (o meglio, degli oggetti) di gestione delle varie componenti, come i DataSource o il tasto back.

Tra le funzionalita' salienti di questo application controller, oltre al rispetto delle specifiche ovviamente, sono il box di attesa che viene visualizzato al momento del caricamento di pagine particolarmente onerose (come elenco e scheda) e la gestione corretta del tasto BACK con assieme un meccanismo di caching.

Le richieste che vengono fatte con ajax sono tutte asincrone eccezion fatta per quelle di inizializzazione che avvengono comunque una sola volta.

4. Application Logic

E' stato deciso di semplificare il piu' possibile questa componente (data la mole di lavoro e i tempi stretti) scegliendo di implementare l'ontologia come un file RDF (vedi sotto) e di navigarlo tramite una serie di file XSL. Partendo quindi dalla richiesta originale (scheda o elenco), si individuano quali risorse dell'ontologia contengano affermazioni sulla pagina richiesta e tramite queste vengono selezionati gli elementi che andranno poi a formare il menuContestuale. Inoltre viene modificato il contenuto stesso di scheda o elenco aggiungendo dei link a delle richieste attinenti al contesto.

5. Ontologia

Abbiamo deciso di implementare l'ontologia per il portale hydralisk tramite un file RDF (valido) arricchito da proprieta' ad hoc da noi definite. La scelta e' ricaduta sulla linearizzazione RDF in XML perche' questo standard ci offriva il vantaggio di usare dei costrutti ben definiti che ci hanno aiutato nella strutturazione dell'ontologia. Nella nostra ontologia sono presenti risorse riconducibili dei tipi ben precisi: Percorso, Autore, Ciclo, Libro, che tuttavia non sono stati effettivamente definiti con RDFS o OWL, vuoi perche' abbiamo ritenuto non necessario formalizzare classi e proprieta' con un linguaggio di schema (anche perche' e' una parte esclusivamente interna al nostro portale), sia perche' non c'e' la necessita di inferire ulteriori informazioni.
Ognuna di queste risorse e' caratterizzata da diverse proprieta' che fanno riferimento ad altre risorse, oppure contengono dei dati di tipo semplice (come degli URI esterni al nostro portale o delle brevi descrizioni testuali). Da notare come le proprieta' finalizzate ad esprimere collegamenti ad altre risorse dell'RDF sono strutturate in modo tale da ridurre al minimo le indirezioni e la ridondanza delle informazioni: puo' esserci o un elenco di riferimenti a risorse correlate dello stesso tipo, o un affermazione di "appartenenza" ad una singola altra risorsa.

to top


You are here: TechWeb06 > GruppiDelCorso > DrillTeam > HydraliskDocs

to top

Copyright © Fabio Vitali + TechWeb students 2006