Grafica, contenuti, semantica: un ambiente integrato per la costruzione di...

POLITECNICO DI TORINO

III Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica

Tesi di Laurea

Grafica, contenuti, semantica: un ambiente integrato per la costruzione di portali.

Relatore: prof. Fulvio Corno

Candidato: Alessandro Rocca

Novembre 2004

Sommario 1 INTRODUZIONE ...........................................................................................................................6

1.1 Ambito .....................................................................................................................................6 1.2 Obiettivi ...................................................................................................................................8 1.3 Stato avanzamento .................................................................................................................8

2 I SISTEMI DI CONTENT MANAGEMENT..............................................................................10

2.1 Definizione ............................................................................................................................10 2.2 Funzionalità...........................................................................................................................12 2.3 Gestione della semantica .....................................................................................................12

3 SEPARAZIONE DI PRESENTAZIONE E INFORMAZIONE .............................................14

3.1 Problematiche........................................................................................................................14 3.2 Possibili approcci ..................................................................................................................17 3.3 Metodologie e tecnologie.....................................................................................................19

3.3.1 Model 1 e Model 2 ..............................................................................................................19 3.3.2 Framework per lo sviluppo di applicazione web .................................................................21 3.3.3 eXtensible Stylesheet Language (XSL)...............................................................................21

3.4 La soluzione adottata ...........................................................................................................23 3.4.1 Elementi che compongono una pagina................................................................................23 3.4.2 Costruzione di una pagina attraverso l’editor ....................................................................26 3.4.3 Conclusioni .........................................................................................................................28

4 REQUISITI .....................................................................................................................................29

4.1 Requisiti funzionali ..............................................................................................................29 4.1.1 Amministrazione ................................................................................................................30 4.1.2 Gestione ..............................................................................................................................34 4.1.3 Editor ..................................................................................................................................44

4.2 Requisiti tecnici .....................................................................................................................47 4.2.1 Applicazione .......................................................................................................................47 4.2.2 Editor ..................................................................................................................................47 4.2.3 Persistenza..........................................................................................................................47 4.2.4 File system ..........................................................................................................................48

5 PROGETTO ...................................................................................................................................49

5.1 Architettura ...........................................................................................................................49 5.1.1 UI Tier ................................................................................................................................49 5.1.2 Business Logic Tier.............................................................................................................51 5.1.3 Data Tier.............................................................................................................................51

4 Introduzione

5.2 Implementazioni .................................................................................................................. 53 5.2.1 Modello dati ....................................................................................................................... 53 5.2.2 YAXP (Yet Another XML Parser) .................................................................................... 57 5.2.3 Remotizzazione del file system........................................................................................... 59 5.2.4 Compilatore........................................................................................................................ 61

6 CONCLUSIONE............................................................................................................................64

6.1 Risultati ottenuti................................................................................................................... 64 6.2 Possibili sviluppi ed evoluzioni......................................................................................... 65

6.2.1 Editor ................................................................................................................................. 65 6.2.2 Compilatore........................................................................................................................ 66 6.2.3 Persistenza ......................................................................................................................... 66

1 Introduzione • Contesto • Obiettivi • Stato avanzamento

Scopo di questa tesi è il progetto e la realizzazione di un sistema integrato di Content Management e di editing evoluto interamente web-based con la possibilità di gestire i contenuti nell’ottica del semantic web.

1.1 Ambito Un Content Management System, o più brevemente CMS, è un’applicazione

in grado di gestire l’intero ciclo di vita di un contenuto, inteso come elemento d’informazione in un ambito specifico, dalla sua creazione alla sua obsolescenza.

Un sistema di editing è l’insieme di strumenti e funzionalità messe a disposizione degli utenti che permettono non solo di creare e modificare le informazioni, ma anche di creare e modificare sia gli attributi visivi, creando la presentazione vera e propria del contenuto, sia i meta-dati che forniscono una presentazione ‘logica’ dello stesso.

Si dice che un’applicazione è web-based nel momento in cui l’insieme delle funzionalità o parte di esse sono accessibili attraverso il canale Internet normalmente attraverso un normale browser.

L’esigenza di possedere un sistema di Content Management in una redazione nasce in ambito Internet solo negli ultimi anni, da quando l’accesso al canale è diventato tanto diffuso da annullare il vantaggio commerciale di essere semplicemente ‘presente’ in rete. La prima conseguenza evidente è stato il maggior interesse verso l’offerta di contenuti ed una maggiore sofisticazione della presentazione degli stessi attraverso tecniche sempre più complesse di costruzione delle pagine e l’utilizzo di tecnologie proprietarie e non. Parallelamente sono nate delle nuove figure professionali, quali i web designer,

Introduzione 7

destinate a gestire la tecnologia disponibile. Infatti, mentre la gestione dei contenuti in redazione non si discosta molto dalle attività tradizionalmente espletate in un giornale o in televisione, rimane invece la dipendenza verso queste figure professionali che hanno la competenza tecnica per pubblicarli sul web.

La necessità di ridurre i costi ed abbassare il time to market, porta all’esigenza di avere strumenti semplici ed intuitivi che rendano le redazioni indipendenti quanto più possibile dai tecnici, abbreviando il workflow che porta alla loro pubblicazione. Lo scopo principale di questi sistemi è quindi favorire la cooperazione tra chi crea i contenuti e chi ne deve gestire la presentazione, cercando il più possibile di separare le aree di competenza. Attualmente nessuna grossa organizzazione può fare a meno di possedere un qualche tipo di CMS, per quanto essenziale, soprattutto quelle che fanno della presenza su Internet parte del loro core business.

Essendo in via di risoluzione le difficoltà appena citate, la sovrabbondanza di contenuti creati nel frattempo ha un livello di entropia tale che spesso questa inficia la facilità con cui è possibile accedervi. Eseguendo ricerche su argomenti generici sfruttando i migliori strumenti messi a disposizione sul web, è difficile districarsi tra tutte le informazioni che in realtà non hanno alcuna attinenza con quanto ricercato, arrivando paradossalmente a non trovare nulla di utile.

Diventa necessario poter catalogare le informazioni sia per quanto riguarda il pregresso sia per quanto concerne le attività in corso. Nel primo caso il ruolo principale è occupato dai motori di ricerca e dalle tecniche di catalogazione automatica delle informazioni, fornendo risultati molto vari. Il secondo caso è l’ambito in cui opera il Sematic Web che raccoglie standard, metodologie, tecnologie e strumenti in grado di creare delle basi di conoscenza ‘organizzate’ secondo delle strutture esplorabili da agenti (software) specializzati, in cui gli utenti possono ragionevolmente trovare informazioni maggiormente pertinenti alle loro esigenze.

Con gli strumenti adatti un utente sarebbe in grado di inserire nei contenuti quelle informazioni aggiuntive che collocano il contenuto nella ‘casella’ giusta.

8 Introduzione

1.2 Obiettivi Normalmente è necessario ricorrere a più strumenti per poter assolvere

tutte queste necessità e spesso sono strumenti sufficientemente settorializzati da essere poco fruibili ai più. Basti pensare agli editor di pagine web che spesso presuppongono una conoscenza più che superficiale del mark-up utilizzato. Oppure alle conoscenze e agli strumenti necessari alla realizzazione di applicazioni web dinamiche. Per non parlare degli strumenti di editing delle ontologie, che spesso presuppongono la capacità di avere una visione object-oriented del mondo circostante.

Pur non essendo possibile prescindere da alcune conoscenze di base su come si compone una pagina web o cosa voglia dire associare delle informazioni semantiche ad un contenuto, è possibile creare un ambiente in cui le attenzioni di ciascun attore possono focalizzarsi sulla propria attività in modalità WYSIWYG, anche per i content editor, separando la presentazione dall’informazione.

Il CMS oggetto di questa tesi si propone quindi di rispondere a tutte queste esigenze in un ambiente integrato, interamente web-based e orientato ai ruoli che ciascuna figura ricopre all’interno di una struttura che gestisce un sito web: da un lato dare la possibilità ai web designer di potersi concentrare sull’aspetto grafico della pagina attraverso la creazione di template sia per i content sia per le pagine; dall’altra ai content editors di creare contenuti esplicitandone i concetti che espongono sfruttando un’ontologia, creando delle relazioni tra di esse ed esponendole agli agenti di ricerca attraverso l’integrazione di mark-up specifico in fase di pubblicazione.

1.3 Stato avanzamento Lo strumento è stato realizzato nel corso di questi ultimi tre anni durante

l’attività lavorativa dell’autore in qualità di capo progetto e referente tecnico per i sistemi di content management in Tidysoft®, società per la quale lavora da quattro anni.

In una prima fase sono stati definiti i requisiti funzionali e tecnici, individuando le tecnologie di riferimento per lo sviluppo dell’applicazione, ne è stata delineata l’architettura di alto livello, disegnato il modello dati e

Introduzione 9

sviluppato in team l’editor e la prima versione dell’interfaccia di amministrazione.

Da un anno a questa parte l’applicazione ha una nuova interfaccia grafica basata sul paradigma MVC attraverso un framework che lo implementa, è stato aggiunto il concetto di ereditarietà dei contenuti e delle strutture tra siti padre-figlio e sono state introdotte numerose migliorie nella fase di pubblicazione e gestione dei descrittori dei template e pagine in XML.

Attualmente è in totale fase di revisione da parte dell’autore l’implementazione dell’architettura, soprattutto per quel che concerne la trasformazione dei descrittori XML e la parte di persistenza dei dati sia su DB sia su file system attraverso uno strato di astrazione aggiuntivo ottenuto sfruttando dei framework open-source. Questo permetterà all’applicazione una maggiore portabilità su database, rendendone eventualmente l’uso superfluo, e application servers J2EE diversi da quelli attualmente impiegati.

Nel frattempo è in fase di studio e sviluppo l’integrazione con la piattaforma DOSE per l’inserimento delle informazioni semantiche all’interno dei contenuti attraverso l’interrogazione delle ontologie messe a disposizione e e l’arricchimento della stessa. Da questo punto di vista l’applicazione diventa uno strumento rivolto agli end user volto alla costruzione di siti aderenti ai concetti del web semantico.

Da due anni a questa parte un importante istituto bancario utilizza Tidysoft® Publishing per la gestione delle parti redazionali (di vetrina) dei siti istituzionali su Internet, nonché alcuni siti informativi su rete Intranet, in tutto una dozzina di siti. Ultimamente, vista la diffusione ed il riscontro positivo degli utenti, si sta affermando come strumento di riferimento de-facto all’interno dell’istituto.

2 I sistemi di content management • Definizione

• Funzionalità

• Gestione della semantica

In questo capitolo si descrivono molto brevemente le caratteristiche fondamentali di un sistema di content management.

2.1 Definizione Pur non esistendo una definizione univoca di sistema di content

management è possibile ricondurre un’applicazione in questa categoria a partire da alcune sue caratteristiche fondamentali che questa deve presentare. Una definizione possibile riportata sulla rete da più parti [1] è quella che segue, in cui ovviamente il concetto di content non è più necessariamente legato al mondo web:

“Applicazione che permette ad un utente di aggiungere e/o modificare contenuti per un sito web. Tipicamente un CMS è costituito da due elementi: il Content Management Application (CMA) e il Content Delivery Application (CDA). Il CMA permette al content manager o all’autore, che possono non conoscere l’HTML, di gestire la creazione, la modifica e l’eliminazione dei contenuti dal sito web senza la necessità di avere le competenze di un web master. Il CDA utilizza e processa quelle informazioni per aggiornare il sito web.”

Lo scopo ultimo di un tale sistema è dunque quello di gestire l’intero ciclo di vita di oggetto informativo. In Figura 1 viene riportato un workflow di esempio che non vuole essere esaustivo ma tuttavia riporta le attività fondamentali che portano alla pubblicazione di un content. A seconda delle esigenze ogni redazione può aggiungere gli stati, le figure professionali e le attività che ritiene opportuno. Ad esempio un progetto tecnico-scentifico

I sistemi di content management 11

potrebbe dover passare diversi stadi di revisione (formale, funzionale, architetturale, etc.) prima di essere pubblicato. Un content più tradizionale, quale un articolo da pubblicare su una testata giornalistica, potrebbe passare due soli stadi di revisione (revisione, impaginazione).

Figura 1 - Esempio di content workflow

Tutti i prodotti, commerciali e non, che forniscono direttamente o indirettamente (fornendo solo un framework) funzionalità di content management aggiungono inoltre caratteristiche più o meno complesse. Ad esempio prodotti commerciali di livello enterprise quali Vignette® [2] o BroadVision® [3] forniscono funzionalità one-to-one attraverso la definizione di comunità di utenti potenzialmente interessati a determinate informazioni: in questo caso oggetto di management diventano anche gli utenti stessi del portale

12 I sistemi di content management

e le relazioni che questi creano con i contenuti veri e propri. Il framework di CMS Slide [4] facente parte del progetto Jakarta fornisce tutte le funzioni base senza fornire direttamente alcuna interfaccia utente. Il prodotto di CMS di Microsoft® [5] fornisce una soluzione end-to-end per la costruzione di siti attraverso funzionalità di editing WYSIWYG con strumenti simili a quelli esistenti per le pagine web.

L’elenco dei prodotti di CMS nati in questi ultimi anni sarebbe lungo ed elencarlo in questa sede sarebbe oltretutto superfluo. In ogni caso questi pochi esempi forniscono un’idea di quanto variegata sia la categoria delle applicazioni di CMS.

2.2 Funzionalità Visto il ciclo di vita di un content, le funzionalità che un CMS deve

necessariamente presentare sono sostanzialmente quattro:

• Un editor adeguato alla tipologia di content che si desidera trattare

• Un motore di workflow in grado di gestire la macchina a stati che ne sovrintende il ciclo di vita

• Un meccanismo di autenticazione/autorizzazione in base ai ruoli che le figure professionali ricoprono all’interno della redazione

• Un repository che gestisce la persistenza dei content

In alcuni casi, come quello di Slide, non vengono neanche fornite funzionalità di editing astraendo completamente dal tipo di content. Funzionalità aggiuntive, quali ad esempio meccanismi di versioning, non sono realmente caratterizzanti dal punto di vista formale, lo sono esclusivamente dal punto di vista commerciale.

Per i motivi appena esposti anche architetturalmente queste applicazioni presentano una struttura di alto livello molto simile tra loro.

2.3 Gestione della semantica Pur non ricadendo tra le funzionalità obbligatorie di un CMS, la gestione

semantica dei content ha la sua rilevanza in questo contesto. Infatti anche se mancano ancora delle iniziative importanti nel mondo delle aziende private per

I sistemi di content management 13

sviluppare soluzioni che sfruttino in qualche modo le potenzialità offerte da questa tecnologia, le applicazioni che potrebbe avere sono numerose.

Ripensando ad esempio alle funzionalità one-to-one cui si accennava precedentemente in 2.1, una categorizzazione semantica dei contenuti abbinata ad un’ontologia di utenti fornirebbe risultati probabilmente migliori di quelli ottenibili attualmente ad un costo però inferiore. I risultati di adesso si ottengono infatti attraverso un’attività piuttosto intensa di sviluppo di personale specializzato sulla piattaforma oltre a quella che già bisogna fare per poter definire correttamente le comunità. Le attività di ricerca in qualunque campo sarebbero più efficaci. Nel campo dell’intelligenza artificiale, i sistemi esperti avrebbero maggiore successo potendo sfruttare un formalismo aperto e intercambiabile per la gestione della base della conoscenza.

Perché un’iniziativa del genere possa avere successo, la semantica deve essere gestita contestualmente al contenuto e non demandata ad un’ulteriore figura professionale: chi scrive o genera contenuti è d’altronde la persona più indicata per poter esplicitare i concetti che desidera ‘esprimere’. Per questo motivo si parla in questo contesto di gestione della semantica.

3 Separazione di presentazione e informazione • Problematiche

• Possibili approcci

• Metodologie e tecnologie

Per “presentazione” si intende l’insieme degli elementi che contribuiscono a dare forma all’informazione. Per separazione tra presentazione e informazione si intende una qualunque tecnica che separi le informazioni di forma da quelle informative.

3.1 Problematiche Separare informazione e presentazione è diventato un problema con

l’abbassamento della soglia di difficoltà dell’accesso al mondo web (e conseguente aumento degli interessi commerciali) e in tempi più recenti con l’aumentare dei canali disponibili, vocale e mobile in particolare.

Come accennato nell’introduzione è sempre più sentita l’esigenza di permettere ai content writer di creare e gestire le informazioni in autonomia, limitando l’intervento di professionalità tecniche in contesti dove questa è realmente necessaria. Questo permette di ridurre il time to market nella pubblicazione delle informazioni e ridurre i costi necessari al mantenimento della knowledge base.

L’aumentare dei canali disponibili presenta infine un’ulteriore problema di non facile soluzione: la necessità di mettere a fattor comune il pre-esistente limitando l’intervento ai template necessari alla presentazione e che tengono conto delle specificità dei singoli terminali. Ad esempio nel caso di terminali mobili è necessario che l’output sia WML (terminali WAP) piuttosto che cHTML (terminali iMode). Nel caso di terminali vocali sarà necessario generare dei documenti in VoiceXML da mandare ad un sintetizzatore vocale.

Separazione di presentazione e informazione 15

Le difficoltà principali sono quelle di mettere a disposizione strumenti, formalismi e metodologie che siano molto vicine alle singole professionalità coinvolte, che mantengano completamente isolate le diverse aree d’intervento e che allo stesso tempo permettano un colloquio stretto per poter comporre l’oggetto finale. Tutto questo in teoria. Si viene a creare una situazione molto simile alle architetture three-tier dove al posto di base dati, logica e presentazione si trovano content, logica (di composizione/compilazione dei template con l’informazione) e template (Figura 2). L’output dipende ovviamente da questi ultimi due elementi.

Figura 2 - Architettura logica

L’evoluzione stessa delle tecnologie disponibili in qualche modo ripercorre quella delle necessità appena esposte. A titolo di esempio basti pensare a come lo strato di presentazione dell’architettura J2EE di Sun® per Java sia cambiato nel tempo. All’inizio lo sviluppo era dominio incontrastato dei programmatori Java i quali avevano a disposizione esclusivamente le Servlet con le quali scrivere la logica, generare l’output e, annegati da qualche parte, i content. La possibilità d’intervento sia da parte dei web designer che da parte dei content editor era nullo.

16 Separazione di presentazione e informazione

Successivamente la situazione è migliorata un po’ con la nascita delle specifiche JSP e il Model 1 (Figura 3), grazie alle quali i web designer avevano una qualche possibilità d’intervento a patto di non dover eccedere nei ricicli sulla struttura grafica. L’evoluzione successiva è stata l’adozione del paradigma MVC (Model-View-Controller), nato in ambiente SmallTalk negli anni ’70 [6], attraverso il Model 2 (Figura 4) che trova implementazioni quali Jakarta Struts [7] o come componente disponibile in Spring Framework [8] che ha introdotto un ulteriore livello di separazione tra grafica e logica, attraverso l’utilizzo di mark-up aggiuntivo, da inserire nelle pagine JSP, chiamato Tag Libraries. Una di queste, le JSTL (Java Standard Tag Libraries), fanno oggi parte dell’architettura J2EE standard.

Figura 3 – Diagramma di funzionamento del Model 1

Questo ultimo approccio è quello che maggiormente si avvicina a fornire una separazione abbastanza netta tra gli sviluppatori e i web designer sempre che questi ultimi siano in grado di padroneggiare il mark-up aggiuntivo fornito dalle tag libraries. In ogni caso restano da definire le modalità di alimentazione della knowledge base, sia dal punto di vista dell’interazione utente sia da quello applicativo, e come questa influenzerà le scelte architetturali e tecnologiche da adottare nel progetto.


Figura 4 – Diagramma di funzionamento del Model 2 o MVC

3.2 Possibili approcci Da quanto esposto fino ad ora si deduce che i problemi da risolvere in

tema di separazione dei contesti sono due:

1. la scelta o la definizione di un linguaggio di templating;

2. le modalità di composizione o, come viene spesso chiamata, compilazione del template con i content.

Riguardo al primo punto esistono numerose soluzioni già presenti sul mercato, normalmente basate su standard aperti o soluzioni open-source. Per quanto riguarda il secondo punto le possibilità normalmente sono molto più ristrette in quanto dipendono in parte dalla presenza dell’interprete del linguaggio di templating che ovviamente impone alcune restrizioni.

Il template per sua natura è un documento strutturato secondo le regole dettate dall’output finale in cui è possibile inserire dei marcatori o dei segnaposti che forniscono delle indicazioni all’interprete su cosa inserire al loro posto o, ad esempio, come trattare le istruzioni che seguono. In questo tutti i linguaggi di templating non si discostano molto gli uni dagli altri. Quello che invece li caratterizza sono la professionalità richiesta per utilizzare il formalismo adottato e quando/come interviene il processo di compilazione vero e proprio.


In questo contesto per compilazione si intende il processo attraverso il quale i content vengono pubblicati utilizzando i template che i web designer hanno deciso di usare. Non bisogna confonderlo con l’interprete del linguaggio di templating che invece si preoccupa di elaborare le istruzioni inserite nei template stessi.

Gli estremi sono rappresentati da una parte dai template creati utilizzando veri e propri linguaggi di programmazione e che normalmente portano ad una fase di compilazione che coincide con quella di interpretazione dei template. Dall’altra i formalismi che forniscono linguaggi più vicini allo strato di presentazione finale, che richiedono poca o nessuna interpretazione e che hanno processi di compilazione definiti ad-hoc.

La compilazione stessa può avvenire a runtime oppure off-line. Nel primo caso si parla spesso di trasformazione più che di compilazione in quanto si ha un’informazione in input (il/i content) che viene trasformata secondo determinate regole (il/i template) ogni qualvolta viene richiesta l’informazione, producendo l’output in maniera transiente. Nel secondo caso la compilazione produce dei risultati persistenti fino alla prossima invocazione del processo di compilazione. In assenza di questo l’output generato non cambia. Esistono anche soluzioni intermedie che prevedono un approccio misto con parti di output generate in fase di compilazione ed altre generate a runtime. Il prossimo paragrafo illustra alcune delle soluzioni maggiormente adottate e in quali contesti queste danno i maggiori benefici.

Quanto esposto finora riguarda soprattuto i criteri di scelta nell’ottica di risolvere il problema della fase di delivery dei contenuti, non tanto quella di editing. Come accennato in 2.1, i CMS sono composti oltre che dalla componente di delivery (CDA) anche da quelle di editing e gestione (CMA). Da questo punto di vista deve essere fatta innanzitutto una scelta tra due possibili: considerare i template parte del CMA o come contenuti a loro volta.

Nel primo caso i template verranno scritti da personale specializzato che si preoccuperà di crearli con strumenti che non fanno parte del CMA, depositandoli all’interno di un repository da cui il CDA attingerà in fase di compilazione; i contenuti possono essere inseriti al limite con una normale maschera senza alcuna possibilità di editing più evoluto. Nel secondo caso all’interno del CMA dovrà essere presente una componente di editing con un


livello di complessità maggiore che oltre ad essere in grado di gestire i contenuti dovrà mettere a disposizione strumenti di editing specifici per il linguaggio di templating scelto. Inoltre gli strumenti in questione non potranno prescindere dalle funzionalità dalla componente di delivery in quanto i template generati dovranno contenere da subito le istruzioni necessarie al fine di una corretta pubblicazione dei content. Infine, per quel che concerne le attività di editing, se si desidera dare all’utente un ambiente WYSIWYG il linguaggio di templating dovrà essere in qualche modo interpretabile a runtime oppure non influire del tutto.

In ultima analisi la scelta del linguaggio di templating può diventare critica in quanto genera effetti contrastanti sulla semplicità applicativa del sistema da un lato e le funzionalità utente dall’altra.

3.3 Metodologie e tecnologie Nei sotto paragrafi successivi vengono presentate alcune delle tecnologie /

metodologie presenti sul mercato. Le soluzioni presentate vogliono essere rappresentative di un modo di affrontare il problema. In genere è possibile individuare due tipologie diverse di tecniche di templating, a seconda delle finalità che venivano o vengono perseguite in fase di sviluppo:

• i framework di presentazione

• i linguaggi di templating e relativi interpreti

La differenza tra i due è sottile e consiste principalmente nel meccanismo di generazione dell’output finale: nel primo caso esiste un framework che fornisce già tutte le funzionalità necessarie a generare l’output a runtime; nel secondo caso sta allo sviluppatore generare l’output sfruttando le API messe a disposizione dall’interprete. Durante l’esposizione le differenze dovrebbero diventare maggiormente chiare.

3.3.1 Model 1 e Model 2 In questo caso sarebbe più corretto parlare di metodo di templating più

che di linguaggio. Entrambi nascono in ambito Java per fornire uno strato di presentazione all’architettura Enterprise. La diversità architetturale dei due è già stata illustrata brevemente (vd. paragrafo 3.1). Qui verrà approfondita esclusivamente la parte che concerne le JSP e le Tag Libraries.


La combinazione delle tue tecnologie permette di costruire dei template in quanto permette di utilizzare un linguaggio di mark-up, standard (es. JSTL) o proprietario, da inserire nella struttura del documento finale: contestualmente alla creazione delle pagine, allo sviluppatore viene demandato il compito di sviluppare la logica, secondo le modalità dettate dal modello scelto, che carica e visualizza i content a runtime.

Listato 1 – Esempio di template scritto con Velocity

Questo esempio è tipico di molti altri che isolano i livelli di presentazione e informazione a patto che la tecnologia venga sfruttata correttamente da parte degli sviluppatori. Altri esempi sono Velocity [10], Tiles (parte di Struts) o Tapestry [13]. Altri produttori forniscono delle Tag Libraries proprietarie che svolgono i compiti principali in un portale. Il merito maggiore di questo approccio è la flessibilità: non essendoci potenzialmente limiti a quello che uno sviluppatore può implementare, si può ottenere quello che si vuole.

## Provides alignment behavior with table tags ## if the label position is top, ## then give the label it's own row in the table ## otherwise, display the label to the left on same row <tr> #if ($parameters.labelposition == 'top') <td align="left" valign="top" colspan="2"> #else <td align="right" valign="top"> #end #if ($hasFieldErrors) <span class="errorLabel"> #else <span class="label"> #end ## If you want to mark required form fields with an asterisk, ## you can set the required attribute ## Ex. <ui:textfield label="'mylabel'" name="'myname'" required="'true'" /> #if ($parameters.label) #if ($parameters.required) <span class="required">*</span> #end $!webwork.htmlEncode($parameters.label): #end </span> </td> ## add the extra row #if ($parameters.labelposition == 'top') </tr>


I problemi maggiori riguardano la separazione dei ruoli dal punto di vista operativo: un riciclo sulla grafica prevede quasi sicuramente un riciclo sul template finale da parte dello sviluppatore (Listato 1). Inoltre quest’ultimo deve conoscere a priori la struttura delle informazioni e dove queste vanno collocate sulla pagina. Un cambiamento della struttura richiede un intervento non solo del web designer ma anche, visto il riciclo sulla grafica, dello sviluppatore.

3.3.2 Framework per lo sviluppo di applicazione web In questa caegoria ricadono prodotti come Cocoon [11] e WebWork [14].

Entrambi nascono con l’intenzione di fornire uno strato applicativo in grado di fare da collante tra i template e le informazioni. La loro collocazione in un CMS sarebbe all’interno del componente di delivery. La differenza sostanziale rispetto alla soluzione precedente è che il framework nasconde agli sviluppatori molta della logica necessaria alla separazione effettiva dei livelli, sollevandoli dalla responsabilità, o dall’onere, di progettare molto bene l’architettura dell’applicazione.

I template vengono scritti, il primo col formalismo del Model 2, il secondo usando Velocity. Cocoon [11] implementa la nozione di component pipelines dove ogni stadio è specializzato in una particolare operazione. WebWork ha un approccio molto più simile a Struts, implementando di fatto il paradigma MVC.

Questo tipo di approccio soffre purtroppo dello stesso problema di quello precedente: è necessaria la presenza ingombrante di uno sviluppatore anche nel caso si voglia creare un portale di bassa complessità. In compenso apre la strada a possibili estensioni per poter costruire degli strumenti di content management (es. Lenya [12]) al di sopra del framework con investimenti, in termini di sviluppo, minori.

3.3.3 eXtensible Stylesheet Language (XSL) Questo standard del W3C nasce con la finalità di fornire un meccanismo

di trasformazione di documenti strutturati in altri documenti strutturati. Partendo da uno o più documenti conformi alle regole dell’XML, è possibile produrre un altro documento sempre conforme alle regole dell’XML ma espresso per esempio in un altro linguaggio (mark-up). In questo modo è possibile creare dei template in XSL e trasformare attraverso questi dei contenuti (XML) in una pagina XHTML piuttosto che WML o VoiceXML.


Listato 2 – Esempio di foglio di trasformazione XSL

<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">  <xsl:output method="html"/> <xsl:template match="/">  <TABLE> <TR> <TH>Name</TH> <TH>Address</TH> <TH>Home Phone</TH> </TR> <xsl:apply-templates select="dataroot/Employees"> <xsl:sort select="LastName" order="ascending"/> </xsl:apply-templates> </TABLE> </xsl:template>  <xsl:template match="dataroot/Employees"> <TR> <TD> <xsl:value-of select="FirstName" /> <xsl:text> </xsl:text> <xsl:value-of select="LastName" /> </TD> <TD> <xsl:value-of select="Address" /> <br/> <xsl:value-of select="City" /> <xsl:text>, </xsl:text> <xsl:value-of select="Region"/> <xsl:text> </xsl:text> <xsl:value-of select="PostalCode"/> </TD> <TD> <xsl:value-of select="HomePhone" />  <xsl:if test="string-length(Extension)>0"> <xsl:text> Ext </xsl:text> <xsl:value-of select="Extension" /> </xsl:if> </TD> </TR> </xsl:template> </xsl:stylesheet>


La trasformazione avviene attraverso l’utilizzo di API che implementano le specifiche del W3C. Essendo standard il metodo di trasformazione dei documenti, gli XSL vengono utilizzati spesso in parecchi contesti, in particolare nell’ambito dell’Enterprise Application Integration e in quei casi in cui è necessario generare output diversi a partire dalle stesse informazioni.

Questo è uno degli approcci migliori alla soluzione della separazione tra presentazione e informazione tanto che Cocoon stesso sfrutta lo stesso principio all’interno del framework per comporre l’output finale. Lenya, il sistema di content management basato su Cocoon, usa pesantemente gli XSL per generare in automatico gli elementi di navigazione (menu, barre di navigazione, percorsi, mappe del sito).

Se da un lato l’utilizzo di un mark-up rende maggiormente indipendenti i web-designer dagli sviluppatori nell’attività di scrittura dei template, è anche vero che è necessario imparare un nuovo mark-up per poterlo sfruttare, a meno di scrivere un editor in grado di semplificare l’attività di scrittura.

3.4 La soluzione adottata Il CMS oggetto di questa tesi si prefigge di fornire un ambiente integrato

per la grafica, per i content e per la semantica. Per ottenere un tale risultato il linguaggio di templating deve essere il più semplice e il più vicino possibile alle esigenze dei web designer. Invece di inventarne uno nuovo, viene utilizzato l’HTML, adeguatamente arricchito per supportare le funzionalità aggiuntive richieste. In questo modo è possibile operare in modalità WYSIWYG sia a livello di template sia a livello di content. Questo è possibile attraverso il componente di editing, una collezione di funzionalità soprattutto client-side (javascript) in grado di trasformare Internet Explorer™ in un editor HTML.

3.4.1 Elementi che compongono una pagina Per meglio comprendere come e dove il mark-up standard HTML è stato

arricchito viene fornita una spiegazione su come una pagina viene composta e quali sono i suoi elementi fondamentali, elencati qui di seguito.

Definizione di content

È un descrittore XML che dichiara la struttura dei content istanza di questa definizione. L’Xschema per la validazione del descrittore è


riportato in Appendica A. Un esempio di definzione di content è nel Listato 3.

Listato 3 – Esempio di definizione di content

L’esempio definisce un content di nome strillo con attributi Titolo, CorpoTesto, Riassunto, Data. È anche possibile restringere il tipo di contenuto che ogni attributo può contenere.

Listato 4 – Esempio di content

<?xml version="1.0"?> <SEMANTIC_CATEGORY ID="2" NAME="strillo"> <FUNCTION NAME="Titolo"> <DATA_TYPES SPECIF_TYPE="Testo" MAX_INSTANCES="1" /> </FUNCTION> <FUNCTION NAME="CorpoTesto"> <DATA_TYPES SPECIF_TYPE="Testo" MAX_INSTANCES="1" /> <DATA_TYPES SPECIF_TYPE="Immagine" MAX_INSTANCES="1" /> </FUNCTION> <FUNCTION NAME="Riassunto"> <DATA_TYPES SPECIF_TYPE="Testo" MAX_INSTANCES="1" /> </FUNCTION> <FUNCTION NAME="Data"> <DATA_TYPES SPECIF_TYPE="Testo" MAX_INSTANCES="1" /> </FUNCTION> </SEMANTIC_CATEGORY>

<?xml version="1.0" ?> <LIST> <CONTENT_DATA FUNCTION_NAME="Titolo"> <CONTENT_HTML_DATA> <![CDATA[ Titolo ]]> </CONTENT_HTML_DATA> </CONTENT_DATA> <CONTENT_DATA FUNCTION_NAME="CorpoTesto"> <CONTENT_HTML_DATA> <![CDATA[ CorpoTesto ]]> </CONTENT_HTML_DATA> </CONTENT_DATA> <CONTENT_DATA FUNCTION_NAME="Riassunto"> <CONTENT_HTML_DATA> <![CDATA[ Riassunto ]]> </CONTENT_HTML_DATA> </CONTENT_DATA> <CONTENT_DATA FUNCTION_NAME="Data"> <CONTENT_HTML_DATA> <![CDATA[ Data ]]> </CONTENT_HTML_DATA> </CONTENT_DATA> </LIST>


Content

Un content (Listato 4) è un documento XML strutturato secondo la definizione cui risponde. All’interno del content non sono normalmente presenti molte strutture di layout quali DIV e tabelle se non quelle che fanno realmente parte del content (es. dati in forma tabellare).

Schema di content

Uno schema di content fornisce una rappresentazione grafica di un content. Uno schema di content è legato ad una ed una sola definizione di content. L’utente Disegnatore predispone la parte statica e definisce le aree (DIV o celle di tabella) in cui inserire gli attributi del content etichettando l’elemento con il nome dell’attributo stesso. Non è necessario che ogni attributo del content abbia un proprio spazio all’interno dello schema. In questo modo è possibile fornire rappresentazioni diverse dello stesso content. Ad esempio lo schema di content nel Listato 5 fornisce una rappresentazione per tutti i content rispondenti alla definizione data come esempio. In particolare solo dell’attributo Riassunto. Evidenziati in blu gli attributi proprietari inseriti dall’editor.

Listato 5 - Esempio di schema di content

Schema di pagina

Lo schema di pagina è il template di base di una pagina. Questa è composta di tutte le parti statiche di una pagina e può ovviamente essere utilizzata infinite volte. Lo schema di pagina viene creato e modificato con l’editor di schemi di pagine. Il Listato 6 riporta un frammento di schema di pagina come esempio.

<table cellspacing="0" cellpadding="0" width="400" align="center" border="0" tsdeidcatsem="2" tsdeareaname="descrizione" tsdeareatype="tsdecontentschema" unselectable="off"> <tbody unselectable="off"> <tr unselectable="off"> <td style="WIDTH: 400px" align="middle" width="400" tsdeareaname="Riassunto" tsdeareatype="tsdefunction" unselectable="off"></td> </tr> </tbody> </table>


Listato 6 – Frammento di schema di pagina

L’utente Disegnatore, oltre a disegnare le parti statiche del template, definisce quali schemi di content l’utente Autore potrà usare e una o più aree dati, zone dello schema di pagina che accoglieranno i content di un determinata definizione. Le aree dati possono essere associate esclusivamente a tipi di content per i quali esistono degli schemi di content. Nell’esempio è possibile notare gli attributi relativi all’inserimento di una immagine, all’interno dello schema e la definizione di una area dati..

L’utente Disegnatore definisce anche zero o più aree include in cui inserisce file di risorse di tipo Include, componenti applicativi scritti nel linguaggio di programmazione dell’application server che ospiterà le pagina, ad esempio JSP Fragments.

Lo schema di content e di pagina sono in HTML standard. Le celle ed i DIV che definiscono delle funzioni particolari, come ad esempio le aree dati, hanno degli attributi aggiuntivi che forniscono le indicazioni all’editor e al compilatore su come il contenuto delle celle o la cella stessa andrà trattata. In realtà la costruzione di una pagina attraverso l’editor è più complessa, come è possibile vedere nel prossimo paragrafo.

3.4.2 Costruzione di una pagina attraverso l’editor L’utente Autore per prima cosa seleziona lo schema di pagina da

utilizzare per la pagina. Lo schema viene caricato e renderizzato all’interno

<table bgcolor="#f7f3de" border="0" width="155" cellpadding="0" cellspacing="0"> <tbody> <tr> <td tsdeidcatsem="3" tsdeareaname="menu_siti_gruppo" tsdeareatype="tsdedataarea"></td> </tr> <tr> <td> <img tsderesourceid="2" tsdefilename="fondo_spalla.gif" tsdeattributename="src" src="/prototipi/fondo_spalla.gif" /> </td> </tr> </tbody> </table>


dell’editor sfruttando l’ActiveX standard di Internet Explorer. Tutti i nodi del DOM dello schema vengono bloccati in modo che l’utente non possa modificare lo schema. Gli unici punti in cui l’utente può intervenire sono le aree dati.

L’autore carica o crea all’interno di esse, attraverso un apposito dialog, i content (vuoti nel caso di content nuovo) selezionando anche lo schema di content tra quelli messi a disposizione dall’utente Disegnatore. L’HTML relativo viene inserito nell’area dati tante volte quanti sono i content e secondo la disposizione scelta e, di nuovo, viene bloccato in modo da renderlo non modificabile dall’utente Autore. Infine nello schema di content viene caricato il content vero e proprio posizionando gli attributi nelle caselle predisposte.

L’autore può modificare o creare il content in un contesto (la pagina) molto simile a quello che sarà alla termine della compilazione senza temere di poter alterare gli schemi preparati dall’utente Disegnatore.

Listato 7 – Esempio di decrittore di pagina

L’editor è in grado di operare correttamente grazie alla separazione netta tra i (tre) livelli di presentazione e informazione e agli attributi proprietari inseriti nei tag HTML. Il punto di partenza è il descrittore di pagina (Listato 7) che, assieme alle relazioni su DB, fornisce tutte le informazioni necessarie a ricostruire una pagina. Queste vengono utilizzate sia in fase di caricamento e

<?xml version=”1.0” ?> <PAGE METATAG_TITOLO="Investor Relations" METATAG_KEYWORDS="" METATAG_DESCRIPTION=""> <DATA_AREA NAME="titolo" COD_IDCATSEMANTICA="5"> <RULE NAME=""> <FUNCTIONS_ORDER FUNCTION="" ORDER="" /> <FILTER NUMBER="" /> <SCHEMA_RULE ID="" /> <SCHEMA_RULE_HTML_DATA NAME="Righe 1 Cella"> <![CDATA[<TABLE clonethis="true" BORDER=0 tsdeid="4" tsdeareatype="tsderuleschema" WIDTH="100%" ALIGN=center CELLSPACING=0 CELLPADDING="0" UNSELECTABLE="on"> <TR UNSELECTABLE="on"> <TD valign=center align="middle" UNSELECTABLE="on" tsdeareatype="tsderulearea"></TD> </TR></TABLE>]]> </SCHEMA_RULE_HTML_DATA> <CONTENTS_ORDER IDCONTENT="71" /> </RULE> </DATA_AREA> … </PAGE>


modifica nell’editor di una pagine sia, come si vedrà più avanti, in fase di compilazione.

3.4.3 Conclusioni Attraverso questo sistema è possibile avere a disposizione tre livelli

diversi: due relativi alla presentazione e uno relativo all’informazione. Tutt’e tre i livelli restano ben separati e, pur utilizzando un meccanismo proprietario per caratterizzare i template, questi sono completamente mascherati all’utente.

Non è necessario che l’utente conosca i meccanismi con i quali si ottiene questa separazione e lo strumento di editing è funzionalmente ed esteticamente molto simile ad altre applicazioni di office automation. Questo si traduce in una maggiore usabilità anche da parte di utenza non troppo tecnica.

I content manager hanno a disposizione un ambiente user-friendly in cui editare i contenuti, potendone fornire viste diverse e allo stesso tempo sapendo fin da subito quale sarà il risultato finale. In ogni caso è possibile avere una preview vera lanciando direttamente dall’editor una compilazione della pagina in fase di editing sull’ambiente predisposto.

4 Requisiti • Requisiti funzionali

• Requisiti tecnici

Molti offrono soluzioni di content management ognuna con le proprie peculiarità. Anche questo progetto ha le proprie, le più importanti delle quali riguardano l’editor, le modalità di composizione delle pagine e la definizione di content.

4.1 Requisiti funzionali I requisiti funzionali vengono normalmente definiti per conformarsi a

regole di usabilità, esigenze commerciali o perché esplicitamente richiesti dall’utente finale. In linea generale deve essere possibile:

• Fornire delle funzionalità di autenticazione/autorizzazione utenti

• Definire i siti destinazione delle compilazioni

• Fornire un ambiente di preview del tutto identico alla produzione

• Gestire le componenti e le risorse dei siti

• Gestire i content

• Gestire i template

• Fornire funzionalità di editing avanzato per i content ed i template

• Permettere il delivery dei content

Quello fornito è un elenco di alto livello delle funzionalità presenti nel CMS oggetto di questa tesi. Una struttura dell’applicazione, di alto livello anch’essa, può essere schematizzata come in Figura 5 e aiuterà in una esposizione più organica delle funzionalità da implementare. Una descrizione più dettagliata dell’architettura verrà esposta nel relativo capitolo. Visto che

30 Requisiti

normalmente i requisiti funzionali pertengono soprattutto allo strato della User Interface, questi saranno i primi ad essere presi in considerazione.

Figura 5 – Architettura di alto livello dell’applicazione

In alcuni casi vengono riportati diagrammi dei casi d’uso relativi e la spiegazione di ogni singolo caso. In appendice A è possibile leggere alcuni dei test case utilizzati per i test funzionali di accettazione delle modifiche apportate lo scorso anno.

4.1.1 Amministrazione Di seguito le funzionalità fornite dal componente di amministrazione.

Tutti i casi d’uso riportati fanno riferimento alla figura all’interno del sotto-paragrafo relativo.

4.1.1.1 Amministrazione utenti (Figura 6) Crea utente

L’attore Amministratore crea le credenziali dell’utente fornendo le informazioni in Tabella 1.

Tabella 1 – Credenziali utente

Campo Formato Descrizione Login String Login dell’utente Password String Password dell’utente. Deve essere ripetuta

nell’apposito campo per confermare.

Requisiti 31

Modifica utente

L’utente Amministratore modifica le credenziali di un utente esistente modifcando le informazioni in Tabella 1

Figura 6 – Casi d’uso per la gestione utenti

Profilo autorizzativo

L’utente Amministratore assegna i profili cui appartiene l’utente ed i siti su cui può operare. Le azioni che l’utente potrà eseguire dipendono dai profili cui l’utente appartiene. In Figura 7 vengono riportati i profili autorizzativi predefiniti.

Il profilo Amministratore è a sé stante e generalmente può creare e modificare siti, nonché amministrare gli utenti. Il profilo Gestore può gestire i siti cui è stato assegnato dall’Amministratore; il dettaglio delle abilitazioni sono deducibili dai casi d’uso che seguono. Il profilo Disegnatore può creare i template grafici attraverso l’editor e gestirli. Il profilo Autore crea i content, sempre attraverso l’editor e può decidere di porli in uno stato pronto per la pubblicazione. Il profilo Pubblicatore eredita tutte le abilitazioni dei due profili precedenti, inoltre può pubblicare le pagine (ed i content ad essa collegati) e cambiarne lo stato riportandoli in uno stato precedente.

32 Requisiti

Figura 7 – Profili autorizzativi predefiniti

4.1.1.2 Amministrazione di un sito (Figura 8) Crea sito

L’utente amministratore inserisce le informazioni relative alla configurazione del nuovo sito, sia dell’ambiente di preview sia di quello di produzione. Il sito viene creato se il nome è univoco. In Tabella 2 viene riportato un’esempio di dati per la configurazione.

Tabella 2 – Dati configurazione sito

Campo Formato Descrizione Nome String Nome assegnato al sito. Tipo di sito Enum Possibili valori sono BV, J2EE, HTML. Nel

caso di sito statico (HTML) non sarà necessaria la parte relativa all’application.

Requisiti 33

Web server String Elenco dei server web su cui deliverare le risorse statiche (immagini, documenti, etc.)

App server String Elenco application server su cui deliverare le pagine pubblicate.

Utente FTP String Utente FTP utilizzato per il trasferimento delle risorse del sito e delle pagine pubblicate.

Pwd FTP String Password dell’utente FTP di cui sopra. WFS Root String Percorso radice su filesystem sul/sui server

web per le risorse statiche AFS Root String Percorso radice su filesystem sul/sugli

application server per le pagine WHT Root String Percorso radice HTTP che punta ai web

server per le risorse statiche. Utilizzati per la costruzione delle URL complete.

AHT Root String Percorso radice HTTP che punta agli application server per le pagine. Utilizzati per la costruzione delle URL complete.

Modifica sito

L’utente amministratore modifica le informazioni relative alla configurazione del sito esistente.

Predisposizione filesystem

L’utente Amministratore, eventualmente con l’ausilio di un sistemista, predispone il filesystem su cui verranno pubblicate le pagine e create le risorse del sito, creando le strutture iniziali e settando i permessi realativi.

Predisposizione AppSrv

L’utente Amministratore, eventualmente con l’ausilio di un sistemista, predispone l’istanza dell’application server su cui verrà fatto il delivery delle pagine e delle risorse del sito.

34 Requisiti

Figura 8 – Casi d’uso per la gestione di un sito

Predisposizione FTP

L’utente Amministratore, eventualmente con l’ausilio di un sistemista, predispone il servizio FTP che viene utilizzato dall’applicazione per il delivery delle pagine e delle risorse del sito. L’utente FTP utilizzato dovrà avere permessi di scrittura nelle directory predisposte nel casi d’uso precedente.

4.1.1.3 Amministrazione di un multi-sito L’unica differenza tra un multi-sito ed un sito normale è che il primo non

ha un ambiente di pubblicazione, ma pubblica esclusivamente sui siti figli associati. Di conseguenza i casi d’uso sono del tutto identici a quelli del paragrafo precedente.

4.1.2 Gestione Di seguito le funzionalità fornite dal componente di gestione dei siti. Tutti

i casi d’uso riportati fanno riferimento alla figura all’interno del sotto-paragrafo relativo.

4.1.2.1 Gestione definizioni content (Figura 9) Inserisce definizione

L’utente Gestore inserisce una nuova definizione di content. Il sistema provvede a validare il formalismo con cui la definizione è stata scritta.

Requisiti 35

La definizione viene creata se il nome è univoco. Le informazioni da inserire sono riportate in Tabella 3.

Tabella 3 – Dati definizione di content

Campo Formato Descrizione Nome String Nome della definizione di content. Descrittore String Descrittore della definizione di content.

Modifica definizione

L’utente Gestore modifica una definizione di content esistente. Il sistema provvede a validare il formalismo con cui la definizione è stata scritta.

Elimina definizione

L’utente Gestore elimina una o più definizioni di content esistenti. L’eliminazione è possibile a patto che non ci siano content che si riferiscono ad una delle definizioni in fase di cancellazione.

Figura 9 – Casi d’uso per la gestione delle definizioni di content

4.1.2.2 Gestione content (Figura 10) Ricerca content

L’utente può effettuare le ricerche di content per nome fornendo:

• L’inizio del nome del content

36 Requisiti

• Un intervallo fornendo due stringhe

Il risultato è un elenco di content ordinati per nome che risponde ai criteri di ricerca impostati. Ogni record riporta:

• Il nome del content

• L’eventale utente che ha il lock sul content

• Il numero di pagine che usano il content

• Il nome della definizione di content

Visualizza content

L’utente Autore o Pubblicatore seleziona il record e visualizza il content in formato grezzo (senza alcuno stile applicato). Può anche vedere quante pagine lo utilizzano.

Figura 10 – Casi d’uso per la gestione dei content

Elimina content

L’utente Pubblicatore elimina i content selezionati a patto che questi non siano utilizzati da nessuna pagina.

Requisiti 37

Cambia stato content

L’utente Autore o Pubblicatore cambia lo stato del content selezionato (uno ed uno solo per volta). L’utente Pubblicatore ha la facoltà di riportare un content in off-line. Il cambio di stato in on-line si ottiene esclusivamente attraverso la pubblicazione di una delle pagine che lo utilizzano.

4.1.2.3 Gestione schemi (Figura 11) Ricerca schema

L’utente Pubblicatore o Disegnatore seleziona il tipo di schema da gestire (di content o di pagina) e il criterio di ricerca, basato sul nome. Il sistema restituisce un elenco di nomi di schemi e numero di riferimenti complessivi allo schema.

Figura 11 – Casi d’uso per la gestione degli schemi

Visualizza schema

L’utente seleziona dall’elenco uno o più schemi e visualizza lo schema stesso, l’elenco delle pagine, nel caso di schema di pagina, o di schemi di pagina, nel caso di schema di content, che lo utilizzano.

38 Requisiti

Elimina schema

L’utente seleziona dall’elenco uno o più schemi da eliminare. Gli schemi sono eliminabili solo ed esclusivamente se il numero complessivo di riferimenti è zero.

4.1.2.4 Gestione risorse (Figura 12) Precondizioni

L’utente seleziona un sito per il quale è abilitato almeno come Gestore.

Crea risorsa

L’utente crea una risorsa compilando le informazioni riportate in Tabella 4. A seconda del tipo di risorsa questa verrà creata fisicamente sull’application server (risorsa di tipo Include) piuttosto che sul server web (risorsa di altro tipo). La risorsa ha nome univoco e percorso univoco a seconda della destinazione fisica dei files.

Tabella 4 – Dati risorsa

Campo Formato Descrizione Nome String Nome della risorsa Percorso String Percorso relativo della risorsa. Tipo Enum Tipo della risorsa. Una tra Stylesheet, Image,

File, Include. Le prime tre vengono create fisicamente sul web, l’ultima sull’application server.

Modifica risorsa

L’utente modifica uno dei dati di una risorsa esistente. Nel caso venga modificato anche il tipo, i files contenuti nella risorsa vengono eliminati. Nel caso cambi solo il percorso, i files vengono spostati.

Upload files

L’utente effettua l’upload di un file attraverso una form multipart http.

Elimina risorsa

L’utente seleziona ed elimina una o più risorse. I files in essa contenuti vengono eliminati.

Requisiti 39

Visualizza files

L’utente visualizza l’elenco dei files contenuti nella risorsa. L’elenco dei files viene prelevato direttamente da file system tramite il client FTP. Per ognuno di questi viene indicato lo stato di pubblicazione.

Elimina file

L’utente seleziona ed elimina uno o più file.

Figura 12 – Casi d’uso per la gestione delle risorse

4.1.2.5 Gestione sezioni (Figura 13) Precondizioni


Crea sezione

L’utente crea una nuova sezione inserendo le informazioni riportate in Tabella 5. Il nome della sezione deve essere univoca. Le sezioni permettono di strutturare il sito.

Tabella 5 – Dati sezione

Campo Formato Descrizione Nome String Nome della sezione Percorso String Percorso relativo della sezione.

40 Requisiti

Modifica sezione

L’utente modifica i dati una sezione esistente. Nel caso venga cambiato il percorso, per mantenere la navigabilità del sito, questo dovrà essere ricompilato.

Elimina sezione

L’utente seleziona ed elimina una o più sezioni. Una sezione è eliminabile se non contiene pagine.

Figura 13 – Casi d’uso per la gestione delle sezioni

4.1.2.6 Gestione pagine Precondizioni


Sposta pagina

L’utente seleziona la sezione e la pagina che desidera spostare. Seleziona succesivamente la sezione in cui spostare la pagina. È possibile spostare la pagina a patto che non esista già un’altra pagina con lo stesso nome nella sezione di destinazione.

Rinomina pagina

L’utente seleziona sezione e pagina da rinominare. Il nuovo nome della pagina non deve già esistere all’interno della sezione corrente.

Requisiti 41

Figura 14 – Casi d’uso per la gestione delle pagine

Nota

Non è possibile eliminare direttamente una pagina. Questa deve essere prima posta in uno stato particolare dal pubblicatore (vedi casi d’uso relativi).

4.1.2.7 Gestione ereditarietà tra siti (Figura 15) Precondizioni

L’utente seleziona un multi-sito per il quale è abilitato almeno come Gestore.

Associa sito figlio

L’utente seleziona uno o più tra i siti disponibili per associarlo al multi-sito corrente. Un sito è associabile se:

• Non è multi-sito

• Non è già associato al multi-sito corrente

• È dello stesso tipo del multi-sito corrente

Sgancia sito figlio

L’utente seleziona tra i siti già associati quelli da sganciare. Tutte le pagine/sezioni ereditate dai siti sganciati vengono sgnaciati a loro volta. L’operazione non è distruttiva: le pagine e le risorse ereditate già compilate non vengono cancellate.

42 Requisiti

Associa pagine/sezioni

L’utente seleziona il sito figlio cui far ereditare pagine e sezioni. L’utente può selezionare singole pagine, singole sezioni o l’intero multi-sito da associare al sito figlio. La selezione di sezioni implica la selezione di tutte le pagine in quella sezione. La selezione del sito implica la selezione di tutte le pagine del sito.

Figura 15 – Casi d’uso per la gestione dell’ereditarietà

Sgancia pagine/sezioni

L’utente seleziona il sito figlio di cui vuole sganciare pagine o sezioni. L’utente selezione singole pagine, sezioni del sito figlio. La selezione di una sezione implica la selezione di tutte le pagine in essa contenute. L’operazione non è distruttiva nello stesso senso esposto precedentemente nel caso d’uso ‘Sgancia sito figlio’.

Nota

Le risorse vengono sempre ereditate.

4.1.2.8 Pubblicazione (Figura 16) Precondizioni

L’utente seleziona un sito o multi-sito per il quale è abilitato come Autore o come Pubblicatore.

Requisiti 43

Compila pagine

L’utente seleziona e compila una o più pagine. La selezione di una sezione implica la selezione di tutte le pagine in essa contenute. È possibile selezionare anche tutto il sito. Nel caso di compilazione di pagine di un multi-sito, è necessario selezionare anche su quali siti figli compilare le pagine.

Compila risorse

L’utente seleziona e compila una o più risorse. Vengono effettivamente portati solo i files mai portati precedentemente o di cui è stato fatto l’upload in un istante successivo a quello dell’ultima compilazione. La compilazione in ambiente di preview non ha senso in quanto questo viene usato come repository per le risorse.

Figura 16 – Casi d’uso per la compilazione

Cambia stato pagine

L’utente seleziona la sezione e gli viene presentato l’elenco delle pagine in esso contenute ognuna con il proprio stato. L’utente cambia lo stato

44 Requisiti

delle singole pagine e conferma. Non è possibile porre direttamente Online lo stato di una pagina.

Pubblica

L’utente Pubblicatore compila in ambiente di pubblicazione le pagine e le risorse selezionate secondo le modalità indicate nei casi d’uso relativi.

Preview

L’utente compila in ambiente di preview le pagine selezionate secondo le modalità indicate dei cadi s’uso relativi.

Elimina pagine

L’utente Pubblicatore elimina le pagine poste precedentemente in stato Elimina attraverso l’apposita funzione.

4.1.3 Editor Di seguito le funzionalità fornite dal componente di editing. Tutti i casi

d’uso riportati fanno riferimento alla figura all’interno del sotto-paragrafo relativo.

4.1.3.1 Editor di pagine (Figura 17) Operazioni pagine

L’utente può effettuare tutte le operazioni base che normalmente è possibile effettuare su di un file (apri, chiudi, salva, salva con nome). Nel caso di nuova pagina l’utente dovrà scegliere lo schema di pagina di base. Nel caso di primo salvataggio o ‘salva con nome’, l’utente dovrà selezionare il nome della pagina e la sezione in cui salvarla. Il nome della pagina deve essere univoco all’interno della sezione.

Operazioni content

L’utente può caricare uno o più content esistenti del tipo relativo all’area dati. Può altresì crearne di nuovi sempre in base alla stessa definizione. Per ognuno di essi può scegliere uno schema di content tra quelli messi a disposizione e può disporli secondo una delle disposizioni predefinite: una colonna, due colonne, una riga.

Requisiti 45

Operazioni formattazione

In fase di editing dei content è possibile usare le operazioni di formattazione standard messe a disposizione da qualunque word processor. Ad esempio è possibile modificare tipo, corpo e stile dei caratteri; applicare delle classi di stile agli elementi, etc.

Figura 17 – Casi d’uso per l’editor di pagina

Operazioni editing

L’utente oltre a inserire il testo, può: inserire immagini, link esterni o a pagina del sito attraverso un’apposita interfaccia, inserire componenti applicativi (Include), etc.

Semantica

Tra le operazioni di editing ci sono anche quelle relative alla gestione della semantica. L’utente può agganciarsi a un’ontologia e attraverso un’apposita maschera scegliere quali concetti (classi) pertengono maggiormente il content selezionando da una vista ad albero tra quelli disponibili; oppure definirne di nuovi collocandoli nel cluster esistente, definendone gli attributi e le relazioni con le altre classi. Le tuple restituite vengono inserite direttamente nel content come mark-up RDF o Xpointer.

46 Requisiti

4.1.3.2 Editor di schemi (Figura 18)

Figura 18 – Casi d’uso per l’editor di schemi

Operazioni schemi

L’utente può effettuare tutte le operazioni base che normalmente è possibile effettuare su di un file (apri, chiudi, salva, salva con nome). Nel caso di primo salvataggio o ‘salva con nome’, l’utente dovrà selezionare il nome dello schema che deve essere univoco all’interno della sito.

Operazioni editing

L’utente può effettuare tutte le normali operazioni normalmente permesse da un editor di pagine web. Questo comprende operazioni di formattazione, l’inserimento di elementi grafici e tabelle, creazione di elenchi, aggiungere componenti applicative (Include), etc.

Definizione attributi

L’utente definisce gli attributi dello schema. Nel caso di schema di content, questi riguardano:

1. l'associazione dello schema ad una definizione di content

2. la definizione delle aree che ospiteranno i dati membro dei content

Nel caso di schema di pagina, l’utente dovrà:

Requisiti 47

1. associare allo schema di pagina uno o più schemi di content (anche di ‘tipi’ diversi)

2. definire le aree dati assocandogli le definizione di content tra quelle scelte attraverso l’operazione precedente.

4.2 Requisiti tecnici In modo del tutto analogo a quanto fatto per i requisiti funzionali, ogni

componente impone i propri requisiti tecnici. In ogni caso i requisiti tecnici sono in numero nettamente inferiore a qualli funzionali.

4.2.1 Applicazione L’applicazione è interamente sviluppata in Java. In particolare utilizza lo

strato più alto e contemporaneamente più basso dell’architettura J2ee: Java Server Pages, Servlet, JNDI, DataSource, JDBC. È indispensabile quindi un servlet container compatibile con le specifiche JSP 1.2 e Servlet 2.3.

I tipi di siti attualmente supportati sono: Servlet, BroadVision, HTML. A seconda dei siti che si desidera gestire dovranno essere predisposti singole istanze o cluster di web server e/o application server di tipo Servlet o BroadVision.

Per la gestione della semantica è invece necessario disporre di un’installazione di DOSE raggiungibile via Web Services (SOAP) e che siano state predisposte una o più ontologie attinenti agli argomenti generali trattati sui siti pubblicati.

4.2.2 Editor L’editor sfrutta pesantemente alcune caratteristiche avanzate di Microsoft

Internet Explorer in versione 5.5 o superiore su piattaforma Windows. Di conseguenza diventa requisito fondamentale alla realizzazione dell’applicazione.

4.2.3 Persistenza Lo strato di persistenza è realizzato su Database Oracle 8.1.7 o superiore. È

in fase di realizzazione un ulteriore strato di disaccoppiamento tra la logica di

48 Requisiti

persistenza e il DBMS fisico in modo da rendere l’applicazione indipendente dal particolare brand del database server.

In ogni caso il DBMS deve essere in grado di supportare i LOB testuali o analoghi campi di testo grandi.

4.2.4 File system Tutta la gestione delle risorse ed il componente di delivery sfrutta il

protocollo FTP per il trasferimento dei file generati o caricati. È necessario quindi disporre di un utente FTP sul/sui server di destinazione autorizzato a leggere/scrivere sotto le directory di delivery.

5 Progetto • Architettura

• Scelta delle tecnologie

• Implementazioni

Anche se l’architettura dell’applicazione non è in fase di revisione, lo sono alcuni dei suoi componenti. In questa sede si fa riferimento agli sviluppi in corso e non allo status-quo dell’applicazione.

5.1 Architettura Partendo dalla Figura 5 vengono qui descritti alcuni dettagli architetturali

su ogni tier dell’applicazione, nella migliore tradizione dell’analisi di alto livello. Dove necessario vengno fornite acnhe indicazioni sui framework eventualmente utilizzati.

5.1.1 UI Tier Le componenti di amministrazione e gestione della user interface sono

realizzate secondo il paradigma Model-View-Controller già descritto precedentemente di conseguenza esistono tre componenti separate: le pagine (Pages-View, UIObjects-Model, ActionServlet-Controller). Il framework utilizzato che implementa il paradigma è Jakarta Struts con l’ausilio delle JSP Standard Tag Libraries nella versione che fanno uso dell’Expression Language anziché delle runtime expressions.

Gli UIObjects provengono direttamente dallo strato di persistenza quando questi hanno una corrispondenza diretta con un’entità su DB, altrimenti sono oggetti transienti realizzati tramite le DynaActionForms di Struts. Il framework provvede a crearli e popolarli in fase di caricamento tramite form. Le actionServlet richiamate in seguito ad un’interazione utente si preoccupano di

50 Progetto

prelevare le informazioni dagli oggetti transienti e di rimapparli secondo necessità su entità persistenti.

Figura 19 – Architettura della user interface

La parte dell’editor è realizzato utlizzando il browser come client pesante, appoggiandosi a controlli ActiveX e librerie JavaScript sviluppate ad-hoc. In particolare viene utilizzato il DHTML Editing Control di Internet Explorer che permette di avere a disposizione un browser dentro un browser. L’istanza dell’ActiveX è quello che ospita le pagine e gli schemi di cui l’utente effettua l’editing. Un altro ActiveX utilizzato serve a creare le toolbar sull’interfaccia. Le librerie JavaScript manipolano il DOM della pagina o schema attualmente nell’editor e gestiscono lo scambio di informazioni con il back-end attraverso delle modal-dialog.

Il DOSEClient è il componente che accede all’ontologia attraverso chiamate SOAP ad un WebService. Il client è realizzato in Apache Axis [15]. In Appendice C, a titolo esemplificativo, è riportato il WSDL per la ricerca nell’ontologia.

Progetto 51

5.1.2 Business Logic Tier Fanno parte dello strato di business logic le componenti di remotizzazione

del file system ed il compilatore (Figura 20).

Il primo componente è costituito a sua volta da due componenti: il primo virtualizza le operazioni sul file sytem remoto in modo che il client non debba preoccuparsi di gestire in maniera esplicita i trasferimenti dichiarando la destinazione dei files. Il secondo fornisce un servizio FTP clusterizzato. In pratica si preoccupa di gestire il trasferimento di un file da o verso un cluster in maniera trasparente al componente che sta a monte.

Figura 20 – Architettura business logic tier

Il compilatore esegue le operazioni di assemblaggio delle pagine. Per farlo si appoggia a YAXP, una libreria per il parsing XML e HTML sviluppata ad-hoc per esigenze di flessibilità e prestazioni. Le operazioni eseguite dal compilatore sono simili a quanto svolto dall’editor in fase di caricamento di una pagina e che è verrà esplicitata maggiormente nel paragrafo relativo alle implementazioni.

5.1.3 Data Tier Lo strato di persistenza dei dati si appoggia ad un framework di ORM

(Object Relational Mapping) chiamato Hibernate [19]. Il framework si frappone

52 Progetto

tra l’applicazione e il database mascherando le particolarità dello stesso, fornendo agli strati a monte una visione completamente ad oggetti dei dati. Uno schema architetturale del framework è riportato in Figura 21.

Figura 21 – Architettura Hibernate

Lo strato di accesso ai dati persistenti avviene implementando il DAO pattern (Figura 22).

Figura 22 – DAO Pattern

Progetto 53

5.2 Implementazioni Non è nelle intenzioni di questa tesi esporre nel dettaglio

l’implementazione di tutta l’applicazione. Vengono tuttavia brevemente descritte le componenti principali e di maggior interesse ai fini della comprensione del funzionamento degli aspetti salienti del CMS.

5.2.1 Modello dati Lo schema del modello dati generale è troppo grande per poter essere

riportato su queste pagine. Vengono quindi riportati solo alcuni sotto-insiemi del modello dati, quelle parti considerate significative.

5.2.1.1 Composizione di una pagina

Figura 23 – Oggetti che compongono una pagina

54 Progetto

In Figura 23 vengono riportate tutte le tabelle coinvolte nella composizione di una pagina. In particolare abbiamo:

T_IB_PUB_PAGINA Cod_id Identificativo della pagina Desc_nomepagina Nome della pagina Cod_idschema Schema di pagina da utilizzare come

template di base Cod_idsezione Deprecato Flag_lock 1 = pagina aperta in editing Desc_nomeutente Utente che ha aperto la pagina Desc_xmlpagina Descrittore XML della pagina Desc_xmlregola Deprecato

T_IB_PUB_SCHEMA Cod_id Identificativo dello schema Desc_nomeschema Nome dello schema Cod_idsezione Deprecato Cod_idsemantica Nel caso di schema di content, id della

definizione di schema associata Cod_idtiposchema Tipo di schema (content o pagina) Flag_lock 1 = schema aperto in editing Flag_isused Deprecato Desc_nomeutente Utente che ha aperto lo schema Desc_schema HTML dello schema

T_IB_PUB_RELSCHEMA Cod_idpadre ID dello schema di pagina Cod_idfiglio Id dello schema di content

Nota

Questa tabella definisce quali schemi di content è possibile usare all’interno di una pagina creata con lo schema di pagina con id cod_idpadre

Progetto 55

T_IB_PUB_SEZIONE Cod_id ID della sezione Desc_nomesezione Nome della sezione Cod_idsito Id del sito cui è associata Anag_relpath Percorso relativo della sezione Flag_ishpsito Deprecato Flag_ishpsezione Deprecato

T_IB_PUB_CATSEMANTICA Cod_id ID della definizione di content Desc_nomecatsemantica Nome della definizione di content Desc_xmlcatsemantica Descrittore della definizione di

content Nota

In realtà il nome ‘categoria semantica’ è deprecato. Adesso si chiama ‘definizione di content’ o ‘classe di content’.

T_IB_PUB_CONTENT Cod_id ID del content Desc_nomecontent Nome del content asseganto in fase di

creazione Cod_idstatoprod Stato del content Cod_idcatsemantica Definizione di content cui è associato Flag_lock 1 = content aperto in editing Desc_nomeutente Utente che ha aperto il content Desc_xmldati Descrittore del content

T_IB_PUB_CONTENTPAGINA Cod_idpagina Id della pagina su cui pubblicare i

content associati Cod_idcontent Id del content da pubblicare

56 Progetto

Cod_idstatoinclusione 1 = content da pubblicare, 0 = content associato alla pagina ma da non pubblicare

Cod_idschema Schema di content da utilizzare per rappresentare il content

Cod_idsito Id del sito per il quale publicare il content (ereditarietà)

Nota

Questa tabella è una relazione quaternaria con un attributo (cod_idstatoinclusione) ed è quella che definisce quali content vengono pubblicate su quali pagine. Il campo cod_idsito serve a gestire l’ereditarietà dei content quando la pagina appartiene ad un multi-sito: nel caso questo campo sia nulllo, il content verrà pubblicato su tutti i siti figli; nel caso sia valorizzato, verrà pubblicato solo sul sito corrispondente.

5.2.1.2 Gestione dell’ereditarietà di pagine tra sito padre e siti figli In Figura 24 vengono riportate le tabelle coinvolte nella gestione

dell’ereditarietà delle pagine tra sito-pafre e sito figlio.

T_IB_PUB_EREDITA Cod_idsito Id del sito che eredita la pagina Cod_idpagina Id della pagina ereditata Cod_idsezione Id della sezione cui la pagina

appartiene Desc_nomepagina Nome della pagina ereditata Desc_pathsezione Path relativo della sezione cui fa parte

la pagina Desc_statopagina Stato di pubblicazione della pagina

ereditata Nota

Questa tabella non è normalizzata. I campi aggiuntivi (desc_pathsezione e desc_nomepagina) sono stati aggiunti per comodità. Lo stato di pubblicazione della pagina è relativo alla pagina ereditata e non alla pagina del sito padre.

Progetto 57

Figura 24 – Ereditarietà tra sito padre e siti figli

5.2.2 YAXP (Yet Another XML Parser) Inizialmente i descrittori XML delle pagine e l’HTML degli schemi

venivano manipolati i primi attraverso Xerces, parser XML dell’Apache Xml Project, i secondi attraverso Tidy [20], una libreria Java che permette di ottenere un DOM da un HTML nonostante quest’ultimo non sia ben formato.

I problemi continui con l’encoding dei caratteri, le entity inserite nell’HTML ed altri problemi che si venivano a verificare in fase di compilazione, hanno fatto maturare l’idea di sviluppare un parser XML/HTML molto semplice, specializzato e robusto da utilizzare in compilazione.

In seguito all’adozione di YAXP gli errori sono sensibilmente calati, grazie anche alla capacità di recupero degli errori del parser, e i tempi di compilazione si sono notevolmente abbassati.

58 Progetto

YAXP è stato sviluppato come due macchine a stati pilotati da eventi: la prima esegue il riconoscimento lessicale dei token, la seconda riconosce la struttura del DOM. In Figura 25 e Figura 26 vengono riportati i diagramma delle classi del parser.

Figura 25 – Diagramma delle classi dei nodi di YAXP

Progetto 59

Figura 26 – Diagramma delle classi degli eventi di YAXP

5.2.3 Remotizzazione del file system Visto l’uso intensivo che viene fatto del file system, è stato creato un

oggetto in grado di fornire un servizio coerente con le operazioni normalmente fatte su di un file system locale. La complessità dell’accesso al file system vero e proprio viene demandato ad un altro componente che si preoccupa di creare i client FTP necessari a portare o a leggere i file in modo approriato. In Figura 27 viene riportato il diagramma delle classi che compongono il servizio di remotizzazione.

Il client che ha bisogno di effettuare un’operazione su file system invoca il metodo che gli serve su RemoteFileSystem. Questo demanda l’operazione vera e propria di trasferimento dei files al ClusterFTPClient. Quest’ultimo apre le connessioni FTP necessarie ad altrettanti server e inizia il trasferimento di files.

Le modalità di trasferimento sono due, configurabili attraverso una variabile d’ambiente: sequenziale o in parallelo. Nel caso di traferimento parallelo vengono istanziati tanti thread MultiFTPTransfer quante sono le connessioni. Ogni thread si mantiene sincronizzato con il processo padre attraverso delle (*nix) pipe attraverso comunicano l’esito del trasferimento. Una volta ricevuto l’acknowledge da ogni thread, il metodo esce.

Nel secondo caso i trasferimenti sulle singole connessioni FTP vengono effettuate sequenzialmente. Si presentava il problema di evitare che le connessione FTP inattive andassero in time-out. Per risolverlo ogni connessione FTP inizializza un thread FtpClient.Poller che mantiene viva la connessione. Visto l’accesso concorrente alla connessione FTP da parte del Poller e della connessione stessa durante il trasferimento, i due thread si sincronizzano attraverso un semaforo.

60 Progetto

Figura 27 – Diagramma delle classi per la remotizzazione del file system

Progetto 61

5.2.4 Compilatore Il compilatore è responsabile della parte di delivery del CMS. Il

diagramma delle classi coinvolte è in Figura 28. Ovviamente il compilatore utilizza anche i due componenti appena descritti.

Figura 28 – Diagramma delle classi del compilatore

62 Progetto

Per meglio comprendere il funzionamento del compilatore in Figura 29 viene riportato il diagramma di sequenza della compilazione di una pagina.

Figura 29 – Diagramma di sequenza per la compilazione di una pagina

Spiegazione dettagliata delle operazioni svolte

1. preleva e crea il DOM dello schema di pagina 2. preleva dal descrittore di pagina tutti i nodi DATA_AREA e per

ognuno di questi: a. recupera il nodo DATA_AREA b. recupera tutti gli content inseriti nella DATA_AREA,

recuperali e crea i DOM corrispondenti c. carica lo schema di content relativo alla DATA_AREA

Progetto 63

d. crea il DOM dello schema di content e. filtra e ordina i content secondo i criteri specificati nel

descrittore di pagina f. estrae lo SCHEMA_RULE (disposizione dei content

all’interno della DATA_AREA) g. crea il DOM e clona i nodi dei content secondo lo

SCHEMA_RULE h. per ogni content:

i. recupera l’HTML ii. inserisce l’HTML nelle apposite aree

i. restituisce l’HTML risultante 3. appende il nodo appena ricevuto come figlio al nodo corrente

6 Conclusione • Risultati ottenuti

• Possibili sviluppi ed evoluzioni

Un ambiente funzionale e stabile, che riscuote apprezzamenti dove utilizzato e che, come molte altre applicazioni, è suscettibile di miglioramenti.

6.1 Risultati ottenuti La scelta di come mantenere separate le informazioni dalla loro

rappresentazione, critica per uno strumento di questo tipo, si è rivelata pienamente rispondente ad ogni esigenza di editing.

Soluzioni analoghe di CMS che forniscono strumenti di editing evoluti per i template e/o per i content hanno un approccio sostanzialmente diverso e che spesso pone alcuni seri limiti all’usabilità dello strumento. Ad esempio usano template che sfruttano Velocity o gli XSLT e quindi diventa difficile pensare di avere uno strumento di editing che mascheri completamente al web designer le complessità insite in questi linguaggi di templating. Oppure confondono il content con l’intera pagina obbligando gli autori a riscrivere più volte le stesse informazioni non esistendo alternative nel caso si voglia presentare più volte lo stesso content o dare viste diverse su di esso in posti/pagine diversi.

Ad esempio, supponiamo si voglia creare una pagina indice con i titoli delle ultime notizie. Ogni titolo riporta anche la data della notizia ed è linkata alla pagina che riporta la notizia completa. Se il content si identifica con la pagina, l’autore è costretto ad inserire due volte il titolo della setssa notizia. Con l’approccio adottato è sufficiente prepare due schemi di content diversi (uno per il titolo e uno per la notizia completa). Una volta inseriti i content sarà sufficiente utilizzare gli schemi giusti per fornire la vista corretta sugli stessi content.

Progetto 65

Infine l’idea di aggiungere le informazioni semantiche direttamente all’interno dei content permette la creazione di knowledge base correttamente strutturate (a patto di costruire correttamente le definizioni di content) e senza ripetizioni. Nel frattempo si inizia a costruire quell’infrastruttura, ancora abbastanza assente a livello globale, di ontologie necessarie a far diventare il web semantico una realtà.

6.2 Possibili sviluppi ed evoluzioni Come accennato in introduzione, l’applicazione è nata circa tre anni fa. In

questo momento soffre di alcuni anacronismi che o sono in fase di revisione o sono da rivedere. Si è già accennato alla riscrittura dello strato di persistenza dei dati e alla reingegnerizzazione del processo di compilazione. Sono però molti i punti in cui è possibile intervenire. Ad esempio: gli utenti sono attualmente mantenuti su DB e farebbe comodo avere la possibilità di accedere ad una directory LDAP per ottenere i servizi di autenticazione/autorizzazione; il supporto ad altri tipi di siti non è banale perché prevede un’intervento sul codice per ‘cablare’ le modalità di deployment delle pagine. Avere la possibilità di descrivere un tipo di siti eliminerebbe o migliorerebbe la situaizione.

6.2.1 Editor Nell’ultimo periodo sempre più spesso Internet Explorer, requisito di base

dell’applicazione, ha presentato gravi falle di sicurezza. Le patch apportate hanno aumentato notevolmente le restrizioni di sicurezza, impedendo in alcuni casi all’editor di operare correttamente ed obbligando a delle riscritture di codice volte ad aggirarle.

Una possibilità potrebbe essere quella di trasformare in una HTML Application o solo l’editor o l’intero sistema. In questo caso verrebbero a cadere le restrizioni di sicurezza e non ci sarebbe più problemi di questo tipo. Il rovescio della medaglia è che ci si lega ancora di più ad una piattaforma legando il futuro dell’applicazione stessa alle sue vicissitudini.

Un’altra possibilità che pone problemi di natura tecnica non immediatamente superabili, è quella di portare l’editor su di una piattaforma maggiormente diffusa utilizzando esclusivamente il DOM standard e relative

funzionalità. A quel punto si potrebbe utilizzare un qualunque browser su qualunque piattaforma.

6.2.2 Compilatore Visto che la maggior parte delle informazioni sono documenti ben formati

o facilmente riconducibili ad una tale situazione (basterebbe adottare l’xHTML invece dell’HTML), il processo di compilazione potrebbe essere sostituito da una serie di trasformazioni stramite XSLT. In questo modo sarebbe possibile anche disaccoppiare il linguaggio utilizzato in fase di editing da quello di output: sarebbe sufficiente definire set di XSLT diversi a seconda dell’output da generare.

Un punto debole dell’attuale piattaforma è la scarsca integrabilità con fonti dati esterne. Attualmente l’integrazione avviene tramite la scrittura di componenti JSP che vengono integrate nelle pagine costruite attraverso lo strumento di editing. L’autore però non ha nessun ccontrollo ne su dove andare a reperire le informazioni, ne su quali informazioni prelevare e come presentarle. Il punto di svolta è quello di potenziare le definizioni di content in modo che questi possano portare al loro interno le informazioni necessarie all’aggancio della fonte dati esterna. Un componente di bridging parte del sistema di deliver si occuperebbe di effettuare l’integrazione tra esterno ed interno ed esporrebbe delle funzioni di querying a runtime.

6.2.3 Persistenza L’attuale situazione vede relazioni tra oggetti più tradizionalmente a

livello di DB, ma anche all’interno dei descrittori. Questo genera una serie di problemi in casi particolari, come in fase di esportazione ed importazione di siti da un ambiente ad un altro. In fase d’importazione è necessario rigenerare tutte le primary keys mantenendo una tabella di lookup con quelle vecchie e sostuirle sia nelle relazioni sia all’interno dei descrittori.

Utilizzare direttamente una struttura a file system risolverebbe questo problema in quanto la chiave diverrebbe il percorso stesso della pagina o della risorsa. Introdurrebbe però il problema della mancanza di transazionalità e di gestione della concorrenza se si mantiene l’attuale gestione sfruttando il protocollo FTP. L’utilizzo di un protocollo come WebDAV permetterebbe invece di gestire correttamente le autorizzazioni sul file system, gestirebbe la

Progetto 67

concorrenza e potrebbe aggiungere il versioning sugli elementi del sito, funzione quest’ultima completamente assente.

La gestione di tutti i descrittori in XML vengono attualmente gestiti manualmente creando i DOM o serializzando e parserizzando lo stream relativo. Quest’approccio porta alla scrittura di molto codice tutto uguale ma che rende difficilmente manutenibili l’esistente. Una soluzione di XML Data Binding basata su JAXB [16] (Java API for XML Binding), Castor [17] o XMLBeans [18] faciliterebbe non solo la manutenibilità del codice ma anche i flussi logici, rendendolo maggiormente comprensibile.

Appendice A – XSD per la validazione dei descrittori

Pagina <?xml version="1.0"?> <xs:schema id="NewDataSet" targetNamespace="http://tempuri.org/page.xsd" xmlns:mstns="http://tempuri.org/page.xsd" xmlns="http://tempuri.org/page.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified"> <xs:element name="PAGE"> <xs:complexType> <xs:sequence> <xs:element name="DATA_AREA" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="RULE" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="FUNCTIONS_ORDER" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="FUNCTION" form="unqualified" type="xs:string" /> <xs:attribute name="ORDER" form="unqualified" type="xs:string" /> </xs:complexType> </xs:element> <xs:element name="FILTER" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="NUMBER" form="unqualified" type="xs:string" /> </xs:complexType> </xs:element> <xs:element name="SCHEMA_RULE" minOccurs="0" maxOccurs="unbounded"> <xs:complexType>

Progetto 69

<xs:attribute name="ID" form="unqualified" type="xs:string" /> </xs:complexType> </xs:element> <xs:element name="SCHEMA_RULE_HTML_DATA" nillable="true" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="NAME" form="unqualified" type="xs:string" /> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="CONTENTS_ORDER" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="IDCONTENT" form="unqualified" type="xs:string" /> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="NAME" form="unqualified" type="xs:string" /> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="NAME" form="unqualified" type="xs:string" /> <xs:attribute name="COD_IDCATSEMANTICA" form="unqualified" type="xs:string" /> </xs:complexType> </xs:element> <xs:element name="INCLUSION_AREA" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="FILENAME" form="unqualified" type="xs:string" /> <xs:attribute name="LOCALPATH" form="unqualified" type="xs:string" />

<xs:attribute name="NAME" form="unqualified" type="xs:string" /> <xs:attribute name="REMOTEPATH" form="unqualified" type="xs:string" /> <xs:attribute name="ID" form="unqualified" type="xs:string" /> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="METATAG_TITOLO" form="unqualified" type="xs:string" /> <xs:attribute name="METATAG_KEYWORDS" form="unqualified" type="xs:string" /> <xs:attribute name="METATAG_DESCRIPTION" form="unqualified" type="xs:string" /> </xs:complexType> </xs:element> <xs:element name="NewDataSet"> <xs:complexType> <xs:choice maxOccurs="unbounded"> <xs:element ref="PAGE" /> </xs:choice> </xs:complexType> </xs:element> </xs:schema>

Definizione di content <?xml version="1.0"?> <xs:schema id="NewDataSet" targetNamespace="http://tempuri.org/catsem.xsd" xmlns:mstns="http://tempuri.org/catsem.xsd" xmlns="http://tempuri.org/catsem.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified"> <xs:element name="SEMANTIC_CATEGORY"> <xs:complexType> <xs:sequence> <xs:element name="FUNCTION" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence>

Progetto 71

<xs:element name="DATA_TYPES" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="SPECIF_TYPE" form="unqualified" type="xs:string" /> <xs:attribute name="MAX_INSTANCES" form="unqualified" type="xs:string" /> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="NAME" form="unqualified" type="xs:string" /> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="ID" form="unqualified" type="xs:string" /> <xs:attribute name="NAME" form="unqualified" type="xs:string" /> </xs:complexType> </xs:element> <xs:element name="NewDataSet"> <xs:complexType> <xs:choice maxOccurs="unbounded"> <xs:element ref="SEMANTIC_CATEGORY" /> </xs:choice> </xs:complexType> </xs:element> </xs:schema>

Content <?xml version="1.0"?> <xs:schema id="LIST" targetNamespace="http://tempuri.org/content.xsd" xmlns:mstns="http://tempuri.org/content.xsd" xmlns="http://tempuri.org/content.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified"> <xs:element name="LIST"> <xs:complexType> <xs:choice maxOccurs="unbounded">

<xs:element name="CONTENT_DATA"> <xs:complexType> <xs:sequence> <xs:element name="CONTENT_HTML_DATA" type="xs:string" minOccurs="0" /> </xs:sequence> <xs:attribute name="FUNCTION_NAME" form="unqualified" type="xs:string" /> </xs:complexType> </xs:element> </xs:choice> </xs:complexType> </xs:element> </xs:schema>

Appendice B – Casi d‘uso relativi ai multi-sito

Di seguito alcuni casi d’uso relativi alla gestione dei multi-sito utilizzati per testare funzionalmente le modifiche riguardanti l’ereditarietà dei content e dei siti.

Creazione del sito multibanca Informazioni di base

Obiettivo: Permette all’utente di creare, una tantum, il sito multibanca

Ambito (del sistema di riferimento):

Livello Business

Pre-Condizioni: L’utente ha associato il profilo “Amministratore” Il sistema ha validato l’utente all’accesso

Post-Condizioni per Successo:

Il sito multibanca deve essere validamente creato, con path validi sia a livello di web server che di application server

Attore primario: Amministratore

Evento scatenante: Predisposizione dell’ambiente multibanca publishing

Scenario base

Passo Descrizione

1. L’utente accede alle funzionalità relative alle “Zone” all’interno del publishing 2. Il sistema visualizza la pagina di “Gestione siti” con le funzionalità in base al

profilo dell’utente 3. L’utente seleziona il pulsante “Nuovo sito Multibanca” 4. Il sistema visualizza la pagina di “creazione del sito multibanca” 5. L’utente inserisce i dati richiesti e conferma 6. Il sistema riporta l’utente sulla pagina di configurazione e visualizza all’interno

della pagina, in colore diverso, l’avvenuta creazione del sito Multibanca 7. Lo use case termina

Varianti

Passo Descrizione

1. Al temine dello scenario base occorre eseguire lo use case di “import / export” di siti. Occorrerà importare dal sito sanpaoloimi.com al nuovo sito multibanca

Appendice B – Casi d’uso 74

Requisiti aggiuntivi

Requisito Descrizione

1 La creazione del sito multibanca ha come prerequisito la disponibilità all’interno dell’ambiente sistemistico del multibanca della parte di vetrina del sito sanpaoloimi.com

Aggiunta di sezioni

Informazioni di base

Obiettivo: Associare una o più sezioni definite sul sito multibanca a uno o più siti figlio ad esso associato


Livello Business

Pre-Condizioni: Deve essere stato creato il sito multibanca con sezioni Devono essere stati associati dei siti-zona al sito multibanca L’utente ha il profilo di “Amministratore sito” Il sistema ha validato l’utente al momento dell’accesso


L’associazione è validamente eseguita.

Attore primario: Amministratore sito

Evento scatenante: Configurazione di un sito multibanca

Scenario base

Passo Descrizione

1. L’utente accede alla “Gestione Siti” 2. Sono visualizzati i siti (zona e multibanca, con eventuali “figli”) cui l’utente è

abilitato 3. L’utente seleziona il sito multibanca sul quale vuole operare e clicca su “Gestisci

sito” 4. Il sistema presenta le funzionalità standard di gestione del sito e le funzionalità

presenti solo per il sito multibanca, pagina di “Gestione sito MB” con a sinistra la selezione del sito avvenuta

5. L’utente seleziona “Associa sezioni” 6. Il sistema presenta la pagina “Associa sezioni” divisa in due parti:

o A sinistra è visualizzata l’alberatura delle sezioni del sito Multibanca selezionato

o A destra è visualizzata una combo contenente l’elenco dei siti figli associati 7. L’utente seleziona un sito figlio


8. Il sistema ne visualizza l’alberatura fino a quel momento definita 9. L’utente seleziona un nodo sull’alberatura del sito multibanca e seleziona aggiungi 10. Il sistema visualizza la parte destra con l’aggiunta della sezione inserita: l’aggiunta

vale per la sezione e per tutte le pagine di cui è composta la sezione sul sito padre 11. Una volta selezionati tutti i nodi che intende aggiungere, l’utente conferma 12. Il sistema ritorna ad “Associa sezioni” 13. lo use case termina

Varianti

Passo Descrizione

Rimozioni di sezioni 9.A L’utente seleziona un nodo sull’alberatura del sito figlio e seleziona “Rimuovi” 10.A Il sistema verifica se esistono pagine on-line associate alla sezione che si intende eliminare 10.1 A in caso positivo visualizza un pop-up di conferma 11.A Il sistema visualizza la parte destra con la rimozione avvenuta

Associazioni di foglie/radici 9.b L’utente seleziona un nodo foglia la cui radice non era stata associata. 10.a Il sistema associa anche la radice

9.c L’utente seleziona un nodo radice le cui foglie non erano state associate. 10.b Il sistema associa tutte le foglie.

Aggiunta di pagine


Obiettivo: Associare una o più pagine definite sul sito multibanca a uno o più siti figlio ad esso associato


Livello Business

Pre-Condizioni: Deve essere stato creato il sito multibanca con sezioni e pagine Devono essere stati associati dei siti-zona al sito multibanca L’utente ha il profilo di “Amministratore sito” Il sistema ha validato l’utente al momento dell’accesso


L’associazione delle pagine è validamente eseguita.

Attore primario: Amministratore sito


Estende il caso d’uso (opzionale):

002: Aggiunta di un sito al sito multibanca e / o 003: Aggiunta di sezioni

Scenario base

Passo Descrizione

1. L’utente accede alla “Gestione Siti” 2. Sono visualizzati i siti (zona e multibanca, con eventuali “figli”) cui l’utente è

abilitato 3. L’utente seleziona il sito multibanca sul quale vuole operare e clicca su “Gestisci

sito” 4. Il sistema presenta le funzionalità standard di gestione del sito e le funzionalità

presenti solo per il sito multibanca: ovvero la pagina di “Gestione sito MB” con a sinistra la selezione del sito avvenuta

5. L’utente seleziona “Associa pagine” 6. Il sistema presenta la pagina “Associa pagine” con visualizzata l’alberatura delle

sezioni del sito Multibanca selezionato 7. L’utente seleziona una sezione sull’alberatura del sito multibanca fino ad arrivare

alla sezione foglia 8. Il sistema visualizza le pagine (in qualsiasi stato) di cui è composta la sezione 9. L’utente seleziona la pagina e clicca sul pulsante “Aggiungi pagine” 10. Il sistema visualizza una pop-up con la scelta del sito, associato al multibanca, su

cui aggiungere la pagina 11. L’utente sceglie 12. Il sistema visualizza l’alberatura del sito figlio selezionato 13. L’utente seleziona una sezione e preme su “Aggiungi pagina” 14. Il sistema visualizza l’alberatura con l’aggiunta della pagina inserita 15. lo use case termina

Varianti

Passo Descrizione

Eliminazione di pagine da un multi-sito 5.a L’utente seleziona “Elimina pagine da Multibanca” 6.a Il sistema presenta la pagina “Elimina pagine da Multibanca” con visualizzata l’alberatura delle sezioni del sito Multibanca selezionato 7.a L’utente seleziona una sezione sull’alberatura del sito multibanca fino ad arrivare alla sezione foglia 8.a Il sistema visualizza le pagine di cui è composta la sezione 9.a L’utente seleziona la pagina e clicca sul pulsante “Elimina” 10.a Il sistema visualizza una pop-up con l’elenco dei siti su cui la pagina è presente e chiede conferma della cancellazione


11.a L’utente conferma 12.a Il sistema ritorna sulla pagina di “Gestione sito MB” 13.a lo use case termina

Eliminazione di pagine

3.b L’utente seleziona il sito sul quale vuole operare e clicca su “Gestisci sito” 4.b Il sistema presenta le funzionalità standard di gestione del sito: ovvero la pagina di “Gestione sito” con a sinistra la selezione del sito avvenuta 5.b L’utente seleziona “Elimina pagine” 6.a Il sistema presenta la pagina “Elimina pagine ” con visualizzata l’alberatura delle sezioni del sito selezionato 7.a L’utente seleziona una sezione sull’alberatura del sito multibanca fino ad arrivare alla sezione foglia 8.a Il sistema visualizza le pagine di cui è composta la sezione 9.a L’utente seleziona la pagina e clicca sul pulsante “Elimina” 10.a Il sistema visualizza una pop-up di conferma 11.a L’utente conferma 12.a Il sistema ritorna sulla pagina di “Gestione sito MB” 13.a lo use case termina

Creazione di pagine composte da content multi-sito


Obiettivo: L’utente vuole comporre pagine dinamiche sul sito multibanca, composte da content che si possono differenziare per banca


Livello Business

Pre-Condizioni: Esiste un sito multibanca con almeno un sito figlio L’utente ha il profilo di “Disegnatore” L’utente è abilitato almeno su un sito multibanca e su almeno un sito figlio Il sistema ha validato l’utente al momento dell’accesso


Le pagine si compilano dinamicamente visualizzando content diversi in base alla banca.

Attore primario: Disegnatore

Evento scatenante: Costruzione di pagine con content comuni su più banche

Scenario base

Passo Descrizione


1. Creazione dello schema di content 1.1. L’utente accede alle funzioni di editor per Schemi di content 1.2. L’utente seleziona la creazione di un nuovo schema di content 1.3. Il sistema presenta una pop-up per la selezione di sito e sezione 1.4. L’utente seleziona il sito multibanca a cui associare lo schema di content ed

eventualmente la sezione relativa 1.5. L’utente associa una categoria semantica 1.6. L’utente salva lo schema di content

2. Creazione dello schema di pagina 2.1. L’utente accede alle funzioni di editor per Schemi di pagina 2.2. L’utente seleziona la creazione di un nuovo schema di pagina 2.3. Il sistema presenta una pop-up per la selezione di sito e sezione 2.4. L’utente seleziona il sito multibanca a cui associare lo schema di pagina e la

sezione relativa 2.5. L’utente associa lo schema di content e salva

3. Creazione della pagina con content multibanca 3.1. L’utente accede alle funzioni di editor per pagine 3.2. L’utente seleziona la creazione di una nuova pagina 3.3. L’utente seleziona lo schema di pagina e preme il pulsante “Mostra Dettagli” di

visualizzazione delle “Aree dati” 3.4. Il sistema visualizza le aree dati a cui sono associabili content 3.5. L’utente procede al caricamento del content multibanca, per ogni content

multibanca da caricare all’interno dello stesso schema: i. Con il pulsante dx del mouse seleziona l’opzione “Aree Dati”

ii. Il sistema apre il “Pannello Area Dati” iii. Seleziona il tasto “Nuovo Content” iv. Si apre un pop-up di definizione del content che richiede di inserire il

nome del content v. L’utente inserisce il nome e conferma

vi. Il sistema presenta il “Pannello Area Dati” di caricamento del content e richiede l’associazione di uno schema e la definizione di una regola di visualizzazione

vii. L’utente inserisce i dati e seleziona il pulsante “Multibanca” viii. Il sistema presenta una pop-up contenente la lista con check box dei siti

figlio associati al multibanca e su cui l’utente è abilitato ix. L’utente seleziona i siti per cui intende creare il content multibanca e

conferma x. Il sistema presenta il “Pannello Area Dati”

xi. L’utente conferma xii. Il sistema visualizza la pagina in cui caricare il valore dei content con

una label contenente tutti i siti figlio selezionati xiii. L’utente valorizza il content


3.6. L’utente salva la pagina 3.7. Il sistema salva la pagina sul sito multibanca 3.8. L’utente richiede la visualizzazione dell’anteprima 3.9. Il sistema richiede su quale sito effettuarla 3.10. L’utente seleziona da pop-up 3.11. Il sistema visualizza l’anteprima

Varianti

Passo Descrizione

Estensione di un content multi-sito ad un sito aggiuntivo 3.5. L’utente seleziona l’area dati su cui è presente il content multibanca:

i. Con il pulsante dx del mouse seleziona l’opzione “Aree Dati” ii. Il sistema apre il “Pannello Area Dati”

iii. L’utente seleziona il content multibanca iv. L’utente seleziona il pulsante “Multibanca” v. Il sistema presenta una pop-up contenente la lista con check box dei siti figlio

associati al multibanca con selezionati i siti a cui il content multibanca era stato associato

vi. L’utente seleziona il sito per cui estendere il content multibanca vii. Il sistema presenta il “Pannello Area Dati”

viii. L’utente conferma ix. Il sistema visualizza la pagina con la label del content estesa alla nuova banca

selezionata x. Il sistema ritorna al punto 3.6

Rimozione di un sito da un content multi-sito

3.5. L’utente seleziona l’area dati su cui è presente il content multibanca: i. Con il pulsante dx del mouse seleziona l’opzione “Aree Dati”

ii. Il sistema apre il “Pannello Area Dati” iii. L’utente seleziona il content multibanca iv. L’utente seleziona il pulsante “Multibanca” v. Il sistema presenta una pop-up contenente la lista con check box dei siti figlio

associati al multibanca con selezionati i siti a cui il content multibanca era stato associato

vi. L’utente de-seleziona il sito per cui intende eliminare il content multibanca e conferma

vii. Il sistema presenta il “Pannello Area Dati” viii. L’utente conferma

ix. Il sistema visualizza la pagina in cui, nella label del content in oggetto, non è più presente la banca deselezionata


x. Il sistema ritorna al punto 3.6

Requisiti aggiuntivi

Requisito Descrizione

Visualizzazione anteprima

Se si apre la pagina sul sito multibanca la visualizzazione dell’anteprima il sistema apre una pop-up con la scelta del sito su cui costruirla. Al contrario l’apertura della pagina in anteprima su uno dei siti figlio che l’hanno ereditata comporta la visualizzazione dei content specifici solo per quella banca

Abilitazioni autori Se, ad esempio, è stato creato un content valido per Spimi, BdN e CariVe, e l’utente loggato al sistema è abilitato solo su due non potrà modificare quel content neanche per le due banche su cui è abilitato

Pagine ereditate Un utente abilitato solo su un sito figlio non può modificare pagine ereditate dal multibanca. Sul sito figlio non si possono aprire pagine ereditate dal padre

Bottone E’ presente un bottone per disabilitare la visualizzazione delle label

Appendice C – WSDL per il servizio di ricerca

WSDL per il servizio di ricerca nell’ontologia. <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions targetNamespace="http://localhost:8080/axis/SearchEngineWS.jws" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://localhost:8080/axis/SearchEngineWS.jws" xmlns:intf="http://localhost:8080/axis/SearchEngineWS.jws" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <wsdl:types> <schema targetNamespace="http://localhost:8080/axis/SearchEngineWS.jws" xmlns="http://www.w3.org/2001/XMLSchema"> <import namespace="http://schemas.xmlsoap.org/soap/encoding/" /> <complexType name="ArrayOf_xsd_string"> <complexContent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:string[]" /> </restriction> </complexContent> </complexType> <complexType name="ArrayOf_xsd_double"> <complexContent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:double[]" /> </restriction> </complexContent> </complexType> </schema> </wsdl:types> <wsdl:message name="initServiceResponse"> <wsdl:part name="initServiceReturn" type="xsd:string" /> </wsdl:message> <wsdl:message name="isReadyRequest"></wsdl:message> <wsdl:message name="searchResponse">


<wsdl:part name="searchReturn" type="impl:ArrayOf_xsd_string" /> </wsdl:message> <wsdl:message name="isReadyResponse"> <wsdl:part name="isReadyReturn" type="xsd:boolean" /> </wsdl:message> <wsdl:message name="initServiceRequest"> <wsdl:part name="annoEndpoint" type="xsd:string" /> <wsdl:part name="annoServer" type="xsd:string" /> <wsdl:part name="expanderEndpoint" type="xsd:string" /> <wsdl:part name="expanderServer" type="xsd:string" /> <wsdl:part name="nResults" type="xsd:int" /> </wsdl:message> <wsdl:message name="searchRequest"> <wsdl:part name="concepts" type="impl:ArrayOf_xsd_string" /> <wsdl:part name="weights" type="impl:ArrayOf_xsd_double" /> </wsdl:message> <wsdl:portType name="SearchEngineWS"> <wsdl:operation name="search" parameterOrder="concepts weights"> <wsdl:input message="impl:searchRequest" name="searchRequest" /> <wsdl:output message="impl:searchResponse" name="searchResponse" /> </wsdl:operation> <wsdl:operation name="isReady"> <wsdl:input message="impl:isReadyRequest" name="isReadyRequest" /> <wsdl:output message="impl:isReadyResponse" name="isReadyResponse" /> </wsdl:operation> <wsdl:operation name="initService" parameterOrder="annoEndpoint annoServer expanderEndpoint expanderServer nResults"> <wsdl:input message="impl:initServiceRequest" name="initServiceRequest" /> <wsdl:output message="impl:initServiceResponse" name="initServiceResponse" /> </wsdl:operation> </wsdl:portType> <wsdl:binding name="SearchEngineWSSoapBinding" type="impl:SearchEngineWS">


<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="search"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="searchRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://DefaultNamespace" use="encoded" /> </wsdl:input> <wsdl:output name="searchResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost:8080/axis/SearchEngineWS.jws" use="encoded" /> </wsdl:output> </wsdl:operation> <wsdl:operation name="isReady"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="isReadyRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://DefaultNamespace" use="encoded" /> </wsdl:input> <wsdl:output name="isReadyResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost:8080/axis/SearchEngineWS.jws" use="encoded" /> </wsdl:output> </wsdl:operation> <wsdl:operation name="initService"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="initServiceRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://DefaultNamespace" use="encoded" /> </wsdl:input> <wsdl:output name="initServiceResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost:8080/axis/SearchEngineWS.jws" use="encoded" /> </wsdl:output> </wsdl:operation> </wsdl:binding>


<wsdl:service name="SearchEngineWSService"> <wsdl:port binding="impl:SearchEngineWSSoapBinding" name="SearchEngineWS"> <wsdlsoap:address location="http://localhost:8080/axis/SearchEngineWS.jws" /> </wsdl:port> </wsdl:service> </wsdl:definitions>

Bibliografia e indirizzi web [1] searchWebServices.com - http://searchWebServices.com e John Hopkins Institutions –

http:// jhmcis.jhmi.edu [2] Vignette - http://www.vignette.com [3] BroadVision - http://www.broadvision.com [4] The Jakarta Project – Slide - http://jakarta.apache.org/slide/ [5] Microsoft Windows Server System - Content Management Server -

http://www.microsoft.com/cmserver/ [6] The original MVC - Trygve M. H. Reenskaug - Xerox Parc 1978-79 -

http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html [7] The Jakarta Project – Struts - http://jakarta.apache.org/struts/ [8] Spring Application Framework - http://www.springframework.org [9] Java Server Pages Standard Tag Libraries – Sun® Microsystems -

http://java.sun.com/products/jsp/jstl/ [10] The Jakarta Project - Velocity – http://jakarta.apache.org/velocity [11] The Apache Cocoon Project – http://cocoon.apache.org [12] Apache Lenya - http://cocoon.apache.org/lenya/index.html [13] Tapestry – The Jakarta Project - http://jakarta.apache.org/tapestry [14] WebWork – OpenSymphony – http://www.opensymphony.com/webwork [15] Axis – Apache Web Services Project - http://ws.apache.org/axis/index.html [16] Java Architecture for XML Binding – Sun® Microsystems -

http://java.sun.com/xml/jaxb/index.jsp [17] The Castor Project – Exolab.org – http://www.castor.org [18] Apache XML Beans – The XML Apche Project - http://xmlbeans.apache.org/ [19] Hibernate – Jboss.org – http://www.hibernate.org [20] Tidy – Dave Raggett - http://www.w3.org/People/Raggett/tidy/

Date post:	19-Feb-2019
Category:	Documents
Upload:	doandien
View:	214 times
Download:	0 times

Grafica, contenuti, semantica: un ambiente integrato per la costruzione di...

Documents