Studio e implementazione di uno strumento di configurazione e visualizzazione di dati di progetto, nell’ambito delle applicazioni cae (computer aided engineering) (2)

UNIVERSITÀ DEGLI STUDI DI TRIESTE
DIPARTIMENTO DI INGEGNERIA E ARCHITETTURA
Corso di Laurea Magistrale in Ingegneria Informatica

Tesi di laurea in
Reti di Calcolatori

Studio e implementazione di uno strumento di
configurazione e visualizzazione di dati
di progetto, nell’ambito delle applicazioni
CAE (Computer Aided Engineering)

LAUREANDO

RELATORE

Matteo Miotto

Prof. Alberto Bartoli
CORRELATORE

Ing. Sergio Benedetti

Anno accademico 2012/2013

INDICE

Indice
1

Introduzione ......................................................................................................... 1

2

Analisi .................................................................................................................. 3
2.1

Scenario ......................................................................................................... 3

2.1.1

Sviluppo Agile ....................................................................................... 3

2.1.2

L’applicazione esistente: SOMO ........................................................... 4

2.1.3

Opportunità di personalizzazione in SOMO .......................................... 5

2.2

Requisiti ........................................................................................................ 6

2.2.1
2.2.2

Personalizzare la dashboard di SOMO .................................................. 9

2.2.3
3

Widget e Page Editor ............................................................................. 7

Page Manager ...................................................................................... 11

Progettazione ..................................................................................................... 13
3.1

User Experience: Principi e processi di progettazione ................................ 13

3.2

Page Editor e Widget .................................................................................. 14

3.2.1

F-shaped pattern e layout ..................................................................... 14

3.2.2

Widget .................................................................................................. 18

3.3
3.4
4

I widget per la dashboard di SOMO ........................................................... 21
Page Manager .............................................................................................. 23

Interfaccia .......................................................................................................... 25
4.1
4.2

Personalizzare una pagina ........................................................................... 26

4.3
5

Accedere al Page Editor .............................................................................. 25

Gestire molteplici pagine personalizzate .................................................... 29

Implementazione ................................................................................................ 33
5.1

Page Editor .................................................................................................. 33

INDICE

5.1.1

Integrazione in SOMO ......................................................................... 33

5.1.2

Design Area ......................................................................................... 35

5.1.3

Caricamento asincrono dei widget nella design area ........................... 38

5.1.4

Il managed bean per il Paged Editor .................................................... 40

5.1.5

Salvataggio di una pagina .................................................................... 42

5.1.6

Widget store e aggiunta di un widget alla design area ........................ 46

5.2

Widget ......................................................................................................... 47

5.2.1

Linee guida per lo sviluppo di un widget ............................................ 47

5.2.2

Managed bean: soluzione proposta dai widget per la dashboard di

SOMO ............................................................................................................. 50
5.3

Accesso ai dati............................................................................................. 52

5.3.1
5.3.2
6

Estensione del database esistente ......................................................... 52
JPA: Implementazione di Entity e Session EJB .................................. 53

Conclusioni ........................................................................................................ 59

Riferimenti ................................................................................................................. 61

Capitolo 1 - INTRODUZIONE

1 Introduzione
Lo scopo di questo lavoro di tesi è progettare e realizzare uno strumento che consenta
all’utente di una specifica applicazione web di configurare le informazioni che
desidera visualizzare e utilizzare, personalizzando così la propria esperienza d’uso.
L’applicazione web considerata è SOMO: tale applicazione permette ai professionisti
di un’organizzazione, anche geograficamente distribuita, il controllo e la
collaborazione nella progettazione (modellazione, simulazione, raccolta e analisi dei
dati) e nello sviluppo di un prodotto in ambito ingegneristico. Le diverse
responsabilità, competenze e necessità degli utenti di SOMO motivano la ricerca di
uno strumento per la personalizzazione delle informazioni. Si vuole dunque passare
dal paradigma “un’applicazione per tutti gli utenti” a quello “un’applicazione per ogni
utente”.
Il lavoro di tesi è stato svolto presso ESTECO S.p.A., azienda operante nel campo
dell’ottimizzazione numerica, specializzata nella ricerca e nello sviluppo di prodotti
software utilizzati in ambito ingegneristico, tra i quali SOMO.
Il risultato ottenuto si identifica in:


Un editor integrato in SOMO, detto Page Editor, che permette la creazione e
la gestione di pagine personalizzate. La personalizzazione si concretizza
attraverso il posizionamento, il ridimensionamento e la configurazione di
generici componenti, ai quali ci si riferirà in seguito con il termine widget.



La definizione di linee guida e la realizzazione di un sistema di partenza che
consentano a sviluppatori di terze parti di costruire widget utilizzabili in
SOMO.



Lo sviluppo di tre widget con lo scopo di dimostrare l’utilizzo del Page Editor
nella personalizzazione della pagina dashboard di SOMO.

1

Capitolo 1 - INTRODUZIONE

Al momento della scrittura di questo documento, nelle applicazioni web impiegate in
ambito ingegneristico non si possono apprezzare soluzioni simili a quella proposta. I
tratti innovativi presenti nel lavoro di tesi sono da ricercare nelle tecnologie utilizzate.
La peculiarità dello strumento realizzato infatti è la possibilità di essere utilizzato
mediante browser web, senza la necessità di installare alcun componente aggiuntivo.
Durante il lavoro di tesi si è provveduto a:


Studiare le tecnologie necessarie, quali HTML5, CSS3, JavaScript, JSF
(JavaServer Faces) e JPA (Java Persistence Api).



Affrontare le fasi dello sviluppo seguendo i principi proposti dalle metodologie
Agile, con particolare riferimento al framework Scrum.

I vincoli di progetto impongono l’uso esclusivo delle tecnologie HTML, CSS e
JavaScript per il lato client e della piattaforma JavaEE (Java Enterprise Edition) per il
lato server.
Nel capitolo 2 si affrontano l’analisi dei requisiti e la descrizione dello scenario nel
quale si inserisce il lavoro di tesi. Nel capitolo 3 viene dato ampio spazio alla
progettazione della User Experience (UX) e dei principali componenti da
implementare. Nel capitolo 4 si presenta un esempio d’uso di quanto prodotto in questo
lavoro di tesi. Infine, nel capitolo 5, si descrivono gli aspetti implementativi più
significativi dei principali componenti software realizzati.

2

Capitolo 2 - ANALISI

2 Analisi
2.1

Scenario

2.1.1

Sviluppo Agile

Lo sviluppo Agile è un particolare approccio allo sviluppo software. Sebbene esistano
numerose incarnazioni di tale approccio, tutti i metodi “agili” enfatizzano i seguenti
principi, enunciati nel “Agile Manifesto” [1] formulato nel 2001:


Lavoro di gruppo.



Frequenti rilasci di funzionalità software completamente funzionanti.



Stretta collaborazione con i clienti.



Capacità di rispondere velocemente ai cambiamenti tecnologici, del mercato
e dei requisiti.

Tra le diverse metodologie agili disponibili, è possibile scegliere quella più adatta ai
propri scopi, personalizzarla, oppure fondere caratteristiche derivanti da diverse
metodologie al fine di soddisfare particolari esigenze. Nello svolgimento del lavoro di
tesi si è fatto riferimento principalmente alla metodologia o, più precisamente, al
framework Scrum [2]. Ampiamente utilizzato nel contesto aziendale nel quale il lavoro
di tesi è stato svolto, Scrum propone un metodo di sviluppo iterativo e incrementale
per ottimizzare la prevedibilità ed il controllo del rischio.
Il cuore di Scrum è uno sprint. Uno sprint è un intervallo di tempo caratterizzato da
una durata di al massimo un mese nel quale viene creato un incremento di prodotto
potenzialmente rilasciabile. Ogni sprint può essere considerato un progetto e contiene
le fasi di pianificazione (analisi e definizione dei requisiti), progettazione,
implementazione e validazione dei risultati. La breve durata di uno sprint e il ridotto
numero di funzionalità prodotte consentono una rapida raccolta di feedback e la

3


possibilità, sprint dopo sprint, di far convergere agevolmente i risultati verso le idee
dei clienti, spesso confuse.
Nello svolgimento di questa tesi, il lavoro si è concentrato principalmente in 3 sprint.
In ognuno di questi si è provveduto ad analizzare e definire i requisiti, progettare e
implementare le funzionalità richieste. Per questo motivo, i capitoli e le sezioni
riguardanti le fasi di sviluppo (analisi dei requisiti, progettazione e implementazione)
sono organizzati in modo tale da evidenziare i risultati di ogni sprint. I risultati ottenuti
negli sprint definiscono congiuntamente il prodotto finale del lavoro di tesi.

2.1.2

L’applicazione esistente: SOMO

Come già anticipato, il lavoro di tesi è stato svolto presso ESTECO S.p.A. [3].
L’azienda produce SOMO [4], un’applicazione web nella quale il risultato del lavoro
di tesi trova applicazione.
SOMO offre alle organizzazioni, anche geograficamente distribuite, un alto livello di
controllo e collaborazione in tutte le fasi del processo di progettazione e sviluppo di
un prodotto, permettendo di:


Gestire risorse di calcolo condivise in HPC (High Performance Computing) e
ambienti cloud pubblici.



Immagazzinare i dati in ambiente centralizzato e sicuro.



Organizzare l’accesso, il “versioning” e il trasferimento di dati di simulazioni
e ottimizzazioni.



Definire piani di calcolo di Design Of Experiments (DOE) e ottimizzazioni
multi obiettivo.



Creare e gestire complessi progetti multidisciplinari.



Analizzare i risultati attraverso strumenti interattivi e di reporting.

È possibile utilizzare SOMO da uno qualsiasi dei principali browser, senza la necessità
di installare alcun componente aggiuntivo.

4


2.1.3

Opportunità di personalizzazione in

SOMO
All’interno di una stessa organizzazione, nell’ambito di un progetto multidisciplinare,
SOMO permette la collaborazione ad utenti con responsabilità, competenze e necessità
differenti. Ciò permette di individuare, all’interno dell’applicazione web, delle aree in
cui utenti diversi necessitano di informazioni diverse. Al momento della raccolta dei
requisiti per il lavoro di tesi sono state individuate in SOMO due principali aree
candidate alla personalizzazione: dashboard e report page.
La dashboard è la prima pagina che l’utente visualizza dopo aver effettuato l’accesso.
Essa contiene informazioni sintetiche e aggiornate sullo stato del lavoro dell’utente
all’interno di SOMO.
La report page è una pagina che permette all’utente di monitorare lo stato di una
sessione di ottimizzazione/simulazione in esecuzione o di valutare i risultati di una
sessione terminata. Questa pagina si propone come un avanzato strumento interattivo
di reporting e analisi dei dati.

Figura 2.1 – La report page di SOMO

La candidatura alla personalizzazione di queste due pagine non è casuale. In esse,
infatti, è possibile individuare blocchi informativi ben delineati che, per utenti diversi,
possono:


Essere necessari o meno.
5




Avere livelli di importanza differenti.



Presentare troppe o troppe poche informazioni.



Essere resi disponibili solo se dispongono delle autorizzazioni necessarie.

Componendo a piacimento i vari blocchi informativi e personalizzandone ognuno
individualmente, l’utente ha la possibilità di:


Visualizzare solamente le informazioni necessarie ai propri scopi e consentite
per il ruolo ricoperto.



Posizionare in primo piano le informazioni che ritiene più importanti.



Aumentare o ridurre la complessità delle informazioni visualizzate a seconda
delle necessità.

Nell’ambito di questo lavoro di tesi si è provveduto a rendere personalizzabile, a titolo
dimostrativo, solamente la pagina dashboard di SOMO. Il principale scopo della tesi,
infatti, non è quello di concentrarsi sulla personalizzazione di una particolare pagina,
ma quello di ideare e realizzare uno strumento che permetta di personalizzare, in
generale, una qualsiasi pagina di SOMO.

2.2

Requisiti

In precedenza è stato presentato SOMO e le sue caratteristiche principali. È stata
inoltre analizzata la possibilità di personalizzare alcune delle sue sezioni, come ad
esempio la dashboard. Trattandosi di un’applicazione web, con il termine “sezione” si
fa riferimento essenzialmente ad una particolare pagina. Lo strumento che si vuole
realizzare dovrà dunque permettere la composizione e la personalizzazione di pagine
di un’applicazione web attraverso l’utilizzo e la configurazione di particolari
componenti base, denominati widget.
In seguito si definiranno:


Il concetto di widget e i requisiti desiderati per lo strumento di
personalizzazione di una pagina.



I requisiti per i widget della dashboard di SOMO.

6




I requisiti per lo strumento di gestione di molteplici pagine personalizzate
create da un utente.

2.2.1

Widget e Page Editor

Un widget può essere definito come un contenitore di informazioni configurabili. Esso
deve rappresentare un’entità indipendente, ossia non deve scambiare informazioni con
altri widget e deve poter essere utilizzato in modo autonomo.
Un widget si compone essenzialmente di una parte relativa al contenuto, ossia le
informazioni, e di una parte relativa alle configurazioni applicabili. Al fine di garantire
all’utente la massima capacità di composizione e personalizzazione di una pagina, un
widget dovrebbe contenere informazioni quanto più omogenee. Le possibili
configurazioni applicabili possono essere di qualsiasi tipo. Esempi di configurazione
possono essere la scelta delle colonne da visualizzare in una tabella, l’applicazione di
un particolare filtro sui dati rappresentati in un grafico, etc. Le responsabilità di
definizione del contenuto e delle possibilità di configurazione sono, comunque,
delegate al produttore del widget.
I produttori di widget sono principalmente gli sviluppatori dell’applicazione web. Non
si vuole precludere però la possibilità che, in futuro, sviluppatori di terze parti
producano i propri widget da utilizzare all’interno di SOMO. Si rende perciò
necessaria la definizione di linee guida per la costruzione dei widget, così da
uniformarne la struttura e il funzionamento.
La costruzione di un widget, oltre alla definizione del contenuto informativo e delle
configurazioni applicabili, passa anche attraverso la definizione di alcuni suoi attributi,
quali:


Categoria: Corrisponde al tipo di informazioni contenute nel widget. Un
widget può appartenere ad una sola categoria. Esempi di categorie possono
essere “testo”, “tabella”, “grafico”, etc.



Scope: Definisce l’ambito di applicazione, ossia la sezione (pagina) nella quale
il widget può essere utilizzato. Ad esempio è possibile definire che lo scope di
un generico widget X è la pagina “dashboard”.

7




Dimensioni di default: Ossia le misure, secondo una qualche metrica, di altezza
e larghezza predefinite.

Dopo aver definito i requisiti dei widget, si procede con la descrizione delle
caratteristiche desiderate per lo strumento destinato alla loro manipolazione,
denominato Page Editor. Si desidera che il Page Editor sia in grado di personalizzare,
in linea teorica, una qualsiasi pagina di SOMO. Il suo funzionamento deve essere
indipendente dal contenuto dei widget che controlla e dalle configurazioni ad essi
applicabili. In altre parole, esso deve trattare i widget come black-box delle quali
conosce e gestisce solamente dimensioni e posizione all’interno di una pagina.
Di seguito sono elencate le caratteristiche e le funzionalità desiderate per il Page
Editor:


Deve esser possibile consultare una lista dei widget disponibili per la pagina
(scope) che si desidera personalizzare, ordinati secondo la categoria
d’appartenenza.



Nell’ambito della pagina da personalizzare, deve esser possibile eseguire le
seguenti operazioni sui widget disponibili:
o Aggiunta di un widget. Uno stesso widget può essere inserito un
numero di volte arbitrario all’interno di una pagina.
o Rimozione di un widget.
o Posizionamento di un widget.
o Ridimensionamento di un widget.
o Configurazione di un widget.



I widget contenuti nella pagina devono rappresentare informazioni reali, così
che l’utente disponga di un’anteprima fedele delle informazioni contenute nella
pagina.



In un widget, la modifica e l’applicazione delle configurazioni devono
innescare l’aggiornamento delle informazioni in esso contenute.



La composizione di una pagina, i cambiamenti apportati e le configurazioni
applicate ai widget contenuti nella pagina devono essere resi persistenti solo
nel momento in cui l’utente lo desidera.

8




Il Page Editor, in generale, dovrà essere accessibile da qualsiasi pagina di
SOMO considerata personalizzabile.

2.2.2

Personalizzare la dashboard di SOMO

Come anticipato nella sezione 2.1.3, si vuole rendere personalizzabile la dashboard di
SOMO. L’operazione di “rendere personalizzabile” un pagina consiste nel ricercare al
suo interno gruppi di informazione che definiranno i widget.
In generale, i principali obiettivi di uno strumento dashboard sono:


Presentare all’utente le informazioni più importanti, provenienti da un’ampia
quantità di dati e da più sorgenti, nel modo più semplice e veloce possibile.



Evidenziare particolari criticità o eventi che richiedono l’attenzione
dell’utente.



Monitorare processi in tempo reale.

La dashboard attualmente presente in SOMO consente all’utente di visualizzare lo
stato del suo lavoro all’interno dell’applicazione. Essa è suddivisa in tre blocchi
principali:


Projects: Contiene le informazioni sui progetti ai quali l’utente ha accesso. È
possibile verificare il numero totale di progetti, così come il numero di progetti
caricati dall’utente. È anche disponibile una panoramica degli ultimi progetti
ai quali l’utente ha lavorato, presentata sotto forma di tabella. Le colonne di
tale tabella sono Project Name, Creator e Created e corrispondono al nome del
progetto, al nome dell’utente che lo ha creato e alla data e ora di creazione.



My Workspaces: Contiene le informazioni sui workspace ai quali l’utente è
assegnato. Le informazioni sui workspace vengono presentate all’utente
mediante una tabella. Le colonne di tale tabella sono Workspace Name,
Description e Created e corrispondono al nome del workspace, ad una breve
descrizione e alla data e ora di creazione.



Sessions: Contiene le informazioni sulle valutazioni (sessioni di ottimizzazione
e/o simulazione) eseguite dall’utente, sia completate che in esecuzione. Tali
informazioni vengono presentate mediante due tabelle, una per le valutazioni

9


terminate e una per quelle ancora in corso. Entrambe le tabelle presentano le
stesse colonne, ossia Status, Category, Session Name, Project Name, Submitter
e Created e corrispondono allo stato dell’esecuzione (Pending, Completed,
Error), al tipo di valutazione, al nome della sessione, al nome del progetto
nell’ambito del quale la valutazione viene eseguita, al nome dell’utente che ha
eseguito la valutazione e alla data e ora di esecuzione.

Figura 2.2 - La dashboard di SOMO

La definizione dei widget, in questo contesto, si rivela immediata dato che le
informazioni sono già raggruppate in tre blocchi ben definiti, ossia quelli sopra citati.
Dato che le informazioni in Projects, My Workspaces e Sessions sono presentate in
forma tabellare, i corrispondenti widget apparterranno alla categoria tabella. Essi
avranno inoltre come scope la pagina dashboard e presenteranno le stesse
informazioni contenute nei blocchi sopra descritti. Le configurazioni possibili per
questi widget sono piuttosto limitate. Per tutti e tre si vuole offrire all’utente
l’opportunità di scegliere se visualizzare o nascondere ogni colonna definita nelle
tabelle.
La tabella seguente riassume le informazioni contenute nei widget della dashboard di
SOMO e le configurazioni ad essi applicabili.

10


PROJECTS

MY WORKSPACES

SESSIONS

SCOPE

Dashboard

Dashboard

Dashboard

CATEGORIA

Tabella

Tabella

Tabella



Project Name



Workspaces



Status



Creator

name



Category



Created



Description



Session Name



Created



Project Name



Submitter



Created

INFORMAZIONI
VISUALIZZATE
(colonne)

CONFIGURAZIONI

Rendi

Rendi

Rendi

POSSIBILI

visibile/nascosta

visibile/nascosta

visibile/nascosta

ogni colonna

ogni colonna

ogni colonna

2.2.3

Page Manager

Fino ad ora sono state definite le caratteristiche e le funzionalità del Page Editor e dei
widget che permetteranno ad un utente di personalizzare una determinata pagina di
SOMO, come la dashboard o la report page.
A questo meccanismo di personalizzazione si vuole aggiungere un’ulteriore
funzionalità, ossia uno strumento che permetta all’utente di creare e gestire diverse
versioni personalizzate di una stessa pagina di SOMO. In questo modo l’utente, ad
esempio, avrà la possibilità di creare più dashboard personalizzate, modificarle,
eliminarle e scegliere quella da utilizzare in base alle proprie necessità. In seguito ci si
riferirà alle diverse versioni personalizzate di una sezione di SOMO con il generico
termine “pagina”.
Anche se esula dagli scopi di questo lavoro di tesi, si vuole sottolineare come un tale
strumento di gestione delle pagine personalizzate possa aprire gli spiragli a
funzionalità quali la condivisione di pagine tra gli utenti di una stessa organizzazione,
di uno stesso workspace, ecc. In questo modo, ad esempio, gli utenti potrebbero creare

11


e condividere le pagine personalizzate create ad un gruppo di utenti, gestendo i
permessi di modifica e utilizzo.
Le caratteristiche e le funzionalità desiderate per lo strumento di gestione delle pagine,
denominato Page Manager, sono le seguenti:


Deve essere possibile accedere al Page Manager direttamente dal Page Editor.



Nell’ambito di una particolare sezione di SOMO (dashboard, report page, …)
lo strumento deve visualizzare tutte le versioni personalizzate create
dall’utente. Per ognuna di esse devono essere presentate le seguenti
informazioni:
o Anteprima della pagina, sotto forma di immagine.
o Nome della pagina.
o Data di creazione.



Le possibili operazioni sulle pagine, intese come versioni personalizzate di una
pagina di SOMO, sono le seguenti:
o Creazione di una nuova pagina.
o Modifica di una pagina esistente: Questa operazione comporterà
l’apertura del Page Editor per permettere la modifica della pagina
scelta.
o Rimozione di una pagina esistente.
o Impostazione di una pagina come “corrente”. Mediante questa
operazione l’utente sceglie, tra le diverse versioni create, quella che
desidera utilizzare. Ad esempio, nel caso un utente abbia creato più
pagine personalizzate per la dashboard, potrà scegliere quale di queste
verrà visualizzata durante il normale utilizzo della dashboard di
SOMO.

12

Capitolo 3 - PROGETTAZIONE

3 Progettazione
3.1

User Experience: Principi e

processi di progettazione
Nella progettazione di ogni componente si è prestata molta attenzione alla User
Experience (UX). In tutta la fase di progettazione, si è fatto riferimento ai seguenti
principi [5]:


Ridurre i concetti, aumentare la semplicità e la familiarità
a. È stato introdotto un nuovo concetto? Perché? È necessario? È coerente
con i concetti già presenti?
b. È possibile rimuovere concetti non necessari e le distrazioni?
c. È possibile ridurre la complessità delle informazioni presentate
all’utente?
d. C’è un modo più semplice per risolvere il problema o per presentare i
dati?



Attenzione ai piccoli dettagli
a. Preferire poche funzionalità completamente funzionanti a molte mal
funzionanti.
b. Curare le interazioni con l’utente, anche le più semplici.



Il tempo conta
a. Attenzione alle performance.
b. Evitare che processi prolungati obblighino l’utente a lunghe attese che
impediscano l’interazione con l’applicazione.
c. Chiedere “conferma” solo prima di eseguire operazioni irrevocabili.
d. Mettere in primo piano le informazioni che contano veramente, così
che possano essere consultate velocemente.

13


La progettazione di tutte le principali funzionalità (Page Editor, Widget e Page
Manager) si è svolta sulla base del processo “design thinking” [6] [7] che si articola
essenzialmente nelle seguenti fasi:
1. Definizione: Consiste nel comprendere il problema da risolvere, definire i
parametri per valutare la futura soluzione, ricercare informazioni utili alla
risoluzione del problema, raccogliere esempi di soluzioni a problemi simili e
discutere con clienti e utenti.
2. Ideazione: Ha come obiettivo la generazione del maggior numero di idee
possibili per la risoluzione del problema.
3. Decisione: Consiste nel valutare le idee generate e scegliere, tra queste, la
migliore.
4. Modellazione: Prevede la creazione di mockup e prototipi della soluzione
scelta.
5. Validazione: Consiste nel presentare agli utenti i risultati dei passi precedenti
e raccogliere i feedback.
Nelle seguenti sezioni verranno mostrati i risultati finali della fase di progettazione.

3.2

Page Editor e Widget

3.2.1

F-shaped pattern e layout

Nel 2006, il ricercatore Jakob Nielsen dimostrò [8] come, mediamente, gli utenti
visualizzino le pagine web in modo predicibile, seguendo un pattern denominato Fshaped pattern. Secondo questo studio, condotto sfruttando tecniche di eye-tracking, i
visitatori di pagine web assimilano in pochi secondi il contenuto di una pagina,
disegnando con lo sguardo sullo schermo una traccia a forma di F.

14


Figura 3.1 - Heatmaps ricavate mediante tecniche di eyetracking

La progettazione del layout del Page Editor è stata condotta basandosi su tale pattern.
Il risultato ottenuto è mostrato in figura 3.2.

Figura 3.2 - Layout del Page Editor (Mockup)

Seguendo la numerazione proposta in figura 3.2, l’analisi del layout del Page editor
permette di evidenziare le seguenti aree:
1. Menu di SOMO. Essendo integrato in SOMO, il Page Editor viene visualizzato
all’interno dell’applicazione come una qualsiasi altra pagina. Il menu di SOMO
permette di navigare verso le principali sezioni dell’applicazione.

15


2. Editor Action Pane. È il pannello dedicato ad ospitare i comandi per le
principali operazioni offerte dal Page Editor:
a. Salvataggio della pagina che si sta personalizzando.
b. Chiusura dell’editor.
c. Accesso al Page Manager.
d. Possibilità di visualizzare/nascondere il widget store.
3. Widget Store: Questo panello contiene tutti i widget disponibili per la pagina
che si sta personalizzando. Può essere nascosto per facilitare la
personalizzazione della pagina.
4. Design Area: Essenzialmente rappresenta la pagina che si sta personalizzando.
In quest’area verranno posizionati, ridimensionati e configurati i widget.

3.2.1.1

Widget Store

Il pannello relativo al widget store occupa l’ipotetica fascia verticale del sopracitato
F-shaped pattern. All’interno del widget store i widget sono raggruppati, secondo la
categoria di appartenenza, in blocchi espandibili/comprimibili. In questo modo è
possibile semplificare la ricerca di un widget, escludendo categorie non necessarie ai
fini della ricerca.

Figura 3.3 - Blocco espandibile/comprimibile contenente i widget appartenti ad una particolare
categoria (Mockup)

Facendo riferimento alle lettere contrassegnate in figura 3.3, ogni blocco espandibile
contiene:
a. Nome categoria widget.
b. Numero dei widget contenuti all’interno della categoria.
c. Elemento (widget) della lista.

16


d. Icona del widget. Uno studio [9], svolto sulle pagine dei risultati del motore di
ricerca Google, evidenza come i risultati contenenti anteprime (immagini,
video, ecc) attirino maggiormente l’attenzione dell’utente rispetto a quelli
senza. Inoltre, prodotti commerciali ampiamente usati come Microsoft Office,
utilizzano nei pulsanti dei suoi menu la combinazione Icona-Descrizione per
facilitare la comprensione delle azioni correlate. In questo contesto, l’uso di
un’icona aiuta l’utente ad individuare il widget ricercato all’interno della lista.
e. Nome del widget.
f. Breve descrizione del widget.

3.2.1.2

Design Area

Al fine di semplificare il posizionamento e il ridimensionamento dei widget, l’area che
rappresenta la pagina da personalizzare viene suddivisa in numero n di colonne.
L’ampiezza delle colonne corrisponde alla dimensione minima (sia per l’altezza che
la larghezza) assumibile dai widget, detta dimensione base. La dimensione applicabile
ai widget di una pagina sarà un multiplo della dimensione base.

Figura 3.4 - Organizzazione in colonne della design area: dimensionamento e posizionamento dei
widget (Mockup)

Nella design area è possibile posizionare e ridimensionare un widget:


Posizionamento:

è

possibile

posizionare

a

piacimento

un

widget

semplicemente trascinandolo all’interno della design area. Mentre la posizione
orizzontale di un widget può essere decisa arbitrariamente dall’utente, quella

17


verticale viene automaticamente determinata, dato che i widget vengono
verticalmente posizionati in pila. La posizione di un widget è determinata da
una coppia di coordinate:
o La coordinata orizzontale corrisponde al numero della colonna
occupata dall’angolo in alto a sinistra del widget. Ad esempio, in figura
3.4 la posizione del widget di dimensione 3x3 avrà coordinata
orizzontale 2.
o La coordinata verticale, determinata automaticamente, corrisponde alla
somma delle altezze dei widget posizionati sopra a quello esaminato.
Ad esempio, in figura 3.4, la posizione del widget di dimensione 6x2
avrà coordinata verticale 4.


Ridimensionamento: è possibile impostare la dimensione di un widget
trascinando l’angolo in basso a destra. La dimensione (altezza o larghezza o
entrambe) del widget aumenterà o diminuirà di una quantità proporzionale alla
dimensione base.

3.2.2

Widget

Come richiesto nella definizione dei requisiti, il Page Editor deve trattare i widget
come black-box, ossia dei contenitori dei quali conosce e gestisce solamente
dimensioni e posizione all’interno di una pagina. La progettazione dei widget ha
portato alla definizione del componente widget container (Figura 3.5). Il widget
container è un contenitore in grado di racchiudere il contenuto del widget e trascinarlo
e ridimensionarlo all’interno della design area.

Figura 3.5 - Widget Container (Mockup)

18


All’interno del widget container è possibile, seguendo la numerazione considerata in
figura 3.5, evidenziare le seguenti aree:
1. Widget Action Pane: è un pannello che viene visualizzato solamente quando il
cursore del mouse si trova all’interno del widget container. Il widget action
pane contiene due pulsanti che permettono l’accesso alla Widget Configuration
View (vedi in seguito) e la rimozione del widget dalla design area.
2. Resize Grip: è una piccola area triangolare che, se trascinata, permette il
ridimensionamento del widget.
3. Widget Wrapper: è l’area in cui viene inserito il contenuto del widget, quello
definito dal produttore.
Il contenuto del widget, definito dal produttore dello stesso, deve essere composto da
due viste (figura 3.6), che verranno alternativamente visualizzate all’interno del widget
wrapper:


Widget View: contiene le informazioni che il widget vuole presentare.



Widget Configuration View: contiene l’insieme delle configurazioni applicabili
al widget.

Figura 3.6 - Widget View e Widget Configuration View (Mockup)

Con riferimento alla numerazione proposta in figura 3.6, è possibile evidenziare i
seguenti componenti all’interno delle view sopra definite:
4. Widget Header: Contiene il titolo del widget e, eventualmente, altre
informazioni che si desidera mettere in primo piano.
5. Widget Content: Rappresenta il contenuto informativo del widget.

19


6. Configuration Content: Contiene l’insieme dei controlli per gestire la
configurazione delle informazioni contenute nel Widget Content.
7. Apply/Cancel Configurations: E’ una coppia di pulsanti che permette di
applicare o annullare le configurazioni impostate nel Configuration Content.

3.2.2.1

Caricamento widget e applicazione delle configurazioni

In questa sezione si vogliono descrivere i processi di caricamento dei widget e
dell’applicazione delle configurazioni. La progettazione di tali processi si basa sulle
seguenti considerazioni:


Nella definizione dei requisiti si richiede che “I widget contenuti nella pagina
devono rappresentare informazioni reali, così che l’utente disponga di
un’anteprima fedele delle informazioni contenute nella pagina”.



Nei principi di progettazione ci si impone di “Evitare che processi prolungati
obblighino l’utente a lunghe attese che impediscano l’interazione con
l’applicazione”.

Dato che la generazione delle informazioni reali può richiedere tempi non trascurabili
(ad esempio la creazione di alcuni grafici può richiedere anche diverse decine di
secondi), si vuole che i processi in esame non siano bloccanti, ossia non impediscano
all’utente di interagire con l’applicazione.
Il caricamento di un widget può avvenire in momenti diversi:


In fase di personalizzazione di una pagina, quando un widget viene inserito dal
widget store.



In fase di preparazione della design area, quando il Page Editor viene eseguito
con lo scopo di modificare una pagina precedentemente creata.



In fase di applicazione delle configurazioni, quando le informazioni del widget
devono essere aggiornate.

La figura 3.7 mostra la concatenazione degli eventi che si susseguono a seguito del
caricamento di un widget e della successiva applicazione di configurazioni. I numeri
e le lettere fanno riferimento alla figura 3.8.

20


Figura 3.7 – Flusso di eventi durante il caricamento di un widget e la successiva applicazione di
configurazioni

Figura 3.8 - I vari stati di un widget (Mockup)

3.3

I widget per la dashboard di

SOMO
Come già detto nella sezione 2.2.2, la definizione dei widget per la dashboard di
SOMO si rivela immediata dato che le informazioni sono già raggruppate in blocchi
ben definiti. Alla luce di ciò, nella fase di progettazione dei widget Projects, My

21


Workspaces e Sessions ci si è concentrati solamente nella definizione della loro Widget
View, seguendo i principi introdotti nella sezione 3.1.
Come risultato della fase di progettazione, nelle figure 3.9, 3.10 e 3.11 si riportano i
modelli (mockup) dei widget per la personalizzazione della dashboard di SOMO.

Figura 3.9 - Widget View del widget "My workspaces" (Mockup)

Figura 3.10 - Widget View del widget "Projects" (Mockup)

Figura 3.11 - Widget View del widget "Sessions" (Mockup)

22


3.4

Page Manager

La fase di progettazione del Page Manager, lo strumento addetto alla gestione di
molteplici pagine personalizzate, ha portato al risultato mostrato in figura 3.12.

Figura 3.12 - Layout del Page Manager (Mockup)

Riferendosi alla numerazione riportata in figura 3.12 si evidenziano i seguenti
componenti:
1. Finestra popup: Il Page Manager si presenta come una finestra popup, la cui
apertura può essere invocata dal Page Editor, come richiesto nei requisiti. Il
Page Manager contiene una lista delle pagine create dall’utente. Ogni elemento
della lista è definito come discusso nel punto 2.
2. Page Box: Riferendosi alle lettere riportante in figura 3.13:
a. Page Preview: Anteprima della pagina.
b. Page Name: Nome della pagina.
c. Page Current Marker: E’ un indicatore che viene visualizzato se la
pagina è attualmente impostata come “corrente” dall’utente.
d. Page Detail: Pannello che contiene informazioni di dettaglio sulla
pagina. Esso viene visualizzato solamente quando il cursore del mouse
si trova sopra l’elemento Page Box.

23


e. Page Detail Action Pane: Gruppo di tre pulsanti che permette
l’eliminazione, la modifica e l’impostazione come “corrente” della
pagina.
f. Delete Page Confirmation: Pannello che viene visualizzato quando si
sceglie di eliminare una pagina.

Figura 3.13 - Componenti di un elemento Page Box nel Page Manager (Mockup)

3. Create Page Button: Permette, dopo l’inserimento di un nome, la creazione di
una nuova pagina.

Figura 3.14 - Inserimento del nome per una nuova pagina (Mockup)

4. Close Button: Consente la chiusura del Page Manager e permette all’utente di
proseguire l’utilizzo del Page Editor.

24

Capitolo 4 - INTERFACCIA

4 Interfaccia
In questo capitolo verrà presentato un esempio d’uso di quanto prodotto in questo
lavoro di tesi. In particolare verrà descritta la personalizzazione della dashboard di
SOMO (Page Editor) e la gestione di molteplici versioni personalizzate della
dashboard (Page Manager).
Al fine di utilizzare gli strumenti di personalizzazione e gestione realizzati non è
necessaria alcuna installazione e/o configurazione, dato che essi sono integrati
nell’applicazione (SOMO).

4.1

Accedere al Page Editor

Figura 4.1 - Dashboard di SOMO con due widget

Una sezione di SOMO per la quale è permessa la personalizzazione, presenta un
pulsante a forma di matita posizionato in alto a destra. Nell’esempio d’uso considerato
in questo capitolo si vuole personalizzare la dashboard di SOMO che, inizialmente, si
presenta come in figura 4.1.
Il click sul pulsante sopra citato provocherà l’accesso al Page Editor, il quale
permetterà di personalizzare la pagina (dashboard) corrente.

25


Figura 4.2 - Apertura del Page Editor per la personalizzazione della dashboard

All’apertura del Page Editor, facendo riferimento alla figura 4.2, si notano:


Il pannello Action Menu, che contiene i pulsanti (da sinistra a destra) che
permettono di:
o Visualizzare/nascondere il widget store.
o Salvare le modifiche apportate alla pagina.
o Accedere al Page Manager.
o Chiudere il Page Editor.



Il pannello Widget Store, che contiene i widget utilizzabili per la
personalizzazione della dashboard.



L’area di editing, o Design Area, dove è possibile comporre e personalizzare
la dashboard. In fase di apertura del Page Editor, come mostrato in figura 4.2,
i widget sono rappresentati da contenitori senza informazioni nei quali è
presente solamente un indicatore di attesa. Le informazioni dei widget saranno
visualizzate non appena disponibili. Il tempo di caricamento dipende da diversi
fattori (velocità della connessione, tempi di elaborazione del server, ecc.). È
possibile cominciare a comporre e personalizzare la pagina senza attendere che
il caricamento dei widget all’interno della Design Area sia terminato.

4.2

Personalizzare una pagina

Per inserire un widget nella pagina è necessario fare click sull’elemento
corrispondente all’interno del widget store, come mostrato in figura 4.3.

26


Figura 4.3 - Inserimento di un widget nella Design Area

Il widget scelto verrà inserito nell’angolo in alto a sinistra della design area, come
mostrato in figura 4.4.

Figura 4.4 - Il widget Projects inserito nell'angolo in alto a sinistra nella Design Area

Per spostare un widget all’interno della design area è sufficiente posizionare il mouse
in un punto qualsiasi del widget stesso e trascinarlo verso la posizione desiderata.
Durante il trascinamento nella design area è possibile vedere, grazie ad
un’ombreggiatura (figura 4.5), la posizione che il widget occuperebbe nel caso venisse
rilasciato.
Nell’esempio d’uso considerato il widget “My Workspaces” viene spostato accanto al
widget “Last Projects”. Questa posizione era precedentemente occupata da un altro
widget che, automaticamente viene spostato più in basso.

27


Figura 4.5 - Spostamento di un widget

È possibile ridimensionare un widget trascinando il suo angolo in basso a destra, fino
a raggiungere la dimensione desiderata, come mostrato in figura 4.6.

Figura 4.6 - Ridimensionamento di un widget: Prima (sinistra) e Dopo (destra)

Per accedere al pannello che consente la configurazione di un widget occorre
posizionare il cursore del mouse al suo interno e fare click sull’icona a forma di
ingranaggio che compare in alto a destra, come mostrato in figura 4.7.

Figura 4.7 - Pulsante per accedere alla configurazione del widget

28


Una volta scelte le configurazioni desiderate, è possibile applicarle al widget oppure
annullare la procedura di configurazione, come mostrato in figura 4.8. Nel caso si
decida di applicare le configurazioni impostate, il contenuto del widget verrà ricaricato
con le informazioni aggiornate.

Figura 4.8 - Configurazione di un widget

Tutte le modifiche applicate alla pagina e ai suoi widget vengono rese persistenti
solamente quando l’utente lo desidera. Per salvare le modifiche è necessario fare click
sul pulsante “Save” contenuto nell’Action Pane. In figura 4.9 vengono mostrati gli
stati del salvataggio di una pagina, evidenziati all’utente dal pulsante stesso.

Figura 4.9 - Stati della procedura di salvataggio, evidenziati dal pulsante "Save"

4.3

Gestire

molteplici

pagine

personalizzate
Nell’esempio d’uso considerato finora, è stato mostrato
come personalizzare una pagina per la dashboard di SOMO.
L’utente ha la possibilità di creare e gestire molteplici

Figura 4.10 - Pulsante per

dashboard personalizzate e scegliere, in base alle necessità, accedere al Page Manager
quale utilizzare. Lo strumento che permette queste

29


operazioni è denominato Page Manger ed è accessibile dal Page Editor facendo click
sul pulsante “Pages” (figura 4.10) contenuto nell’Action Menu.
Il Page Manager si presenta sotto forma di una finestra di popup (figura 4.11) che
contiene la lista delle pagine create in precedenza dall’utente. Ogni elemento della lista
è rappresentato da un riquadro contenente l’anteprima della pagina.

Figura 4.11 - Page Manager

Posizionando il cursore del mouse sopra il riquadro relativo ad una pagina si fa in
modo che compaia un pannello contenente alcune informazioni di dettaglio e un
gruppo di pulsanti che permettono di eliminare la pagina, impostarla come “pagina
corrente” e modificarla mediante il Page Editor.
Per modificare una pagina, occorre fare click sul pulsante a forma di matita (figura
4.12) contenuto nel pannello di dettaglio relativo ad una pagina. Questa operazione
provocherà l’apertura del Page Editor consentendo così di editare la pagina scelta.

30


Figura 4.12 – Pulsante per modificare una pagina

Per eliminare una pagina occorre fare click sul pulsante a forma di cestino contenuto
nel pannello di dettaglio relativo alla pagina e confermare l’operazione (figura 4.13).

Figura 4.13 - Pulsante per eliminare una pagina (sopra) e conferma di eliminazione (sotto)

È possibile impostare una pagina come “corrente” facendo click sul pulsante
raffigurante un simbolo di “spunta” contenuto nel pannello di dettaglio relativo alla
pagina (figura 4.14). Questa operazione farà in modo che, al prossimo utilizzo della
dashboard di SOMO, l’utente visualizzi la pagina impostata come “corrente”.

31


Figura 4.14 - Pulsante per impostare una pagina come "corrente "(sopra) e indicatore della pagina
corrente (sotto)

È possibile creare una nuova pagina dashboard facendo click sul pulsante “New
dashboard” posizionato in basso nella finestra popup (figura 4.15). Verrà
successivamente richiesto di inserire un nome da assegnare alla nuova pagina e di
confermare l’operazione di creazione mediante il pulsante “Create”. La creazione della
nuova pagina provocherà l’apertura del Page Editor, che ne permetterà la
composizione e la personalizzazione.

Figura 4.15 - Creazione di una nuova pagina

32

Capitolo 5 - IMPLEMENTAZIONE

5 Implementazione
5.1

Page Editor

Lo strumento Page Editor è costituito dai seguenti componenti software:


Lato client:
o pageEditor.xhtml
o editor.css
o main.js



Lato server:
o EditorServiceBean.java

5.1.1

Integrazione in SOMO

Uno dei principali requisiti espressi per il Page Editor riguarda la completa
integrazione in SOMO. In SOMO la costruzione delle pagine viene realizzata mediante
la tecnologia JSF (JavaServer Faces) [10]. Basata sul design pattern architetturale
MVC (Model View Controller), JSF è riconosciuta da Oracle come tecnologia
standard per la costruzione di interfacce utente lato server. JSF è un framework basato
su componenti. È possibile utilizzare set di componenti predefiniti, di terze parti,
oppure creare componenti personalizzati. In questo lavoro di tesi si è fatto riferimento
alla versione JSF 2.0.
In un’applicazione web che fa uso della tecnologia JSF gli ingredienti necessari sono:


Documenti XHMTL: contengono codice HTML mescolato a speciali elementi
JSF (tag ed espressioni). I documenti XHTML vengono elaborati [11] lato
server dal framework e trasformati in documenti HTML fruibili da un browser
web.

I

documenti

XHTML

costituiscono

il

presentation

layer

dell’applicazione web.

33




Managed Beans: Java Bean che possono essere utilizzati dai documenti
XHTML. Un Java Bean è una classe Java che espone attributi e metodi ad un
framework, in questo caso JSF. In generale, verrà creata un’istanza (o utilizzata
un’istanza esistente) di un managed bean ogni volta che verrà richiesto un
documento XHTML contenente riferimenti ad attributi e metodi esposti dal
managed bean stesso. I managed bean rappresentano la business logic
dell’applicazione web.

In JSF, con il termine Facelets [12] si fa riferimento al View Declaration Language
che sostituisce JSP. Facelets supporta un set di tag finalizzati al templating [13], con
lo scopo di definire componenti e pagine web riutilizzabili. In JSF è possibile definire
un template mediante un documento XHTML che definisce la struttura del documento
e contiene le informazioni comuni alle pagine che usufruiranno di esso. I documenti
XHTML che utilizzano un template definiscono solamente i contenuti propri della
pagina che rappresentano. Per soddisfare i requisiti di integrazione in SOMO, il file
pageEditor.xhtml

utilizza il template mainTemplate.xhtml, definito dagli sviluppatori

dell’applicazione.
Con riferimento al codice 5.1, in riga 1 viene definito il tag <ui:composition> con il
riferimento al template che il documento pageEditor.xhtml utilizza. I contenuti propri
della pagina web vengono definiti mediante i tag <ui:define>.
Codice 5.1
1
2
3
4
5
6
7
8
9

XHTML

<ui:composition template=”./templates/mainTemplate.xhtml”>
...
<ui:define name=”breadcrumb”>
Codice HTML che definisce il contenuto di Action Pane
</ui:define>
...
<ui:define name=”content”>
Codice HTML che definisce il contenuto di Widget Store
e Design Area
</ui:define>

Oltre all’utilizzo di particolari template, l’integrazione in SOMO ha richiesto l’attenta
valutazione della compatibilità delle librerie JavaScript e dei plugin jQuery utilizzati
con le librerie e i plugin presenti nell’applicazione.

34


5.1.2

Design Area

Nella sezione 3.2.1.2 è stato illustrato il risultato della progettazione della Design Area.
L’organizzazione a colonne, la gestione del posizionamento e del dimensionamento
dei widget sono facilitati dall’impiego di un plugin jQuery: gridster.js [14]. Al fine di
poter utilizzare Gridster occorre:


Definire, nel codice HTML contenuto in pageManager.xhtml, una struttura
simile a quella riportata nel codice 5.2.



Inizializzare il plugin. Il codice Javascript necessario all’inizializzazione di
Gridster è riportato nel codice 5.3.
Codice 5.2

1
2
3
4
5
6
7
8

<div class="gridster">
<ul>
<li> ... </li>
<li> ... </li>
...
<li> ... </li>
</ul>
</div>

Codice 5.3
1
2
3
4
6
7

HTML

JS

$(function(){ //DOM Ready
$(".gridster ul").gridster ({
widget_margins: [10, 10],
widget_base_dimensions: [100, 100]
});
});

Si è detto che Gridster permette il posizionamento e il ridimensionamento dei widget
nella design area. Per essere più precisi, Gridster gestisce posizione e dimensione dei
contenitori che avvolgono un widget, ossia i widget container, introdotti nella sezione
3.2.2. Con riferimento al codice 5.2, ogni elemento <li> della lista non ordinata <ul>
corrisponde ad un widget container.
Gridster gestisce i valori di posizione (orizzontale e verticale) e di dimensione
(orizzontale e verticale) di ogni widget container mediante speciali attributi,

35


denominati custom data attributes. Come specificato nel W3C Working Draft di
HTML5 [15], un custom data attribute, in generale:


È un attributo applicabile a qualsiasi elemento HTML.



Ha nome che deve avere prefisso “data-“ mentre il suffisso, composto da
almeno un carattere, può essere scelto in modo arbitrario.



È destinato a contenere dati privati utilizzati dalla pagina web o
dall’applicazione per i quali non esistono elementi HTML o attributi più
appropriati.

Nel codice 5.4, si riporta un esempio di come Gridster faccia uso dei custom data
attributes per gestire posizione e dimensione dei widget container: in data-row viene
salvata la posizione verticale, in data-col quella orizzontale, in data-sizex la
dimensione orizzontale e in data-sizey quella verticale.
Codice 5.4
1

HTML

<li data-row=”2” data-col=”1” data-sizex=”1” data-sizey=”1”></li>

Oltre ai dati necessari al posizionamento e al dimensionamento nella Design Area, i
widget container necessitano di ulteriori informazioni riguardo ai widget che
contengono. Tali informazioni sono necessarie fondamentalmente per poter caricare il
contenuto dei widget e salvare le loro configurazioni. Seguendo la strategia seguita da
Gridster, si è deciso di sfruttare gli attributi data- per salvare tutte le informazioni
necessarie alla gestione dei widget all’interno degli elementi <li>, ossia i widget
container. In questo modo:


Non è necessario costruire apposite strutture dati all’interno del codice
JavaScript in esecuzione nel contesto della pagina web.



Si evita di introdurre dati ridondanti difficili da mantenere aggiornati.



Si contribuisce a mantenere la separazione tra informazioni (HTML) e codice
(JS).

Nel codice 5.5 si mostra la definizione dei widget container contenuti nella Design
Area. Nel dettaglio è possibile osservare:

36




In riga 1 il tag JSF <c:forEach>. Data una collezione di oggetti, in questo caso
la lista pageDetail di oggetti di tipo Widget (Entity, vedi sezione 5.4.2) esposta
dal managed bean EditorServiceBean, l’elaborazione del costrutto forEach
permette di generare una porzione di codice HTML avente tanti elementi <li>
quanti sono gli elementi di pageDetail.



Nelle righe 2-14 è racchiusa la definizione di un widget container.
o Nelle righe 3-10 sono definiti i custom data attributes necessari per la
gestione del widget. Il valore di tali attributi è determinato
dall’elaborazione delle espressioni JSF #{…}.


data-dbid

corrisponde all’ID nel database associato al widget

nella pagina corrente.


data-config contiene una stringa in formato JSON che descrive

la configurazione del widget.


data-templatepath indica l’URL nel quale risiede il documento

XHTML che definisce il contenuto configurabile del widget
(vedi sezione 5.2.1).


data-stylepath

e data-scriptpath indicano gli URL nei quali

risiedono i file .css e .js necessari alla rappresentazione e al
funzionamento del widget.


In riga 13 è presente l’elemento <div> appartenente alla classe widget-wrapper.
All’interno di tale elemento verrà inserito il contenuto del widget (vedi sezione
5.1.3).
Codice 5.5

1
2
3
4
5
6
7
8
9
10
11
12
13

XHTML

<c:forEach items="#{editorServiceBean.pageDetail}" var="widget">
<li class="new widget-container"
data-col="#{widget.col}" data-row="#{widget.row}"
data-sizex="#{widget.width}" data-sizey="#{widget.height}"
data-dbid="#{widget.pageWidgetID}"
data-widgettype="#{widget.widgetID.widgetID}"
data-config="#{widget.configJSON}"
data-templatepath="#{widget.widgetID.templatePath}"
data-stylepath="#{widget.widgetID.stylePath}"
data-scriptpath="#{widget.widgetID.scriptPath}">
<div class="widget-action-pane"> ... </div>
<div class="widget-loader"> ... </div>
<div class="widget-wrapper"></div>

37


14
15

</li>
</ui:repeat>

Il codice 5.6 riporta un esempio del codice HTML risultato dell’elaborazione del
codice 5.5, nel caso in cui pageDetail contenga un solo oggetto:
Codice 5.6
1
2
3
4
5
6
7
8
9
10
11
12
13

HTML

<li class="new widget-container"
data-col="1" data-row="1"
data-sizex="3" data-sizey="3"
data-dbid="974"
data-widgettype="6"
data-config="JSONString"
data-templatepath="widgets/sessions-pkg/sessions.xhtml"
data-stylepath=" widgets/sessions-pkg/style.css"
data-scriptpath=" widgets/sessions-pkg/script.js">
<div class="widget-action-pane"> ... </div>
<div class="widget-loader"> ... </div>
<div class="widget-wrapper"></div>
</li>

5.1.3

Caricamento asincrono dei widget

nella design area
L’accesso dell’utente al Page Editor per la personalizzazione di una particolare pagina
corrisponde alla richiesta del documento pageEditor.xhtml all’application server.
Come già descritto nel capitolo 3, la generazione del contenuto di un widget può
richiedere tempi prolungati. Nel caso si volesse rendere disponibile il contenuto dei
widget al momento dell’accesso al Page Editor, si costringerebbe l’utente ad attendere
la generazione dei contenuti di tutti i widget presenti nella pagina prima di poter
interagire con l’editor stesso.
La soluzione proposta in questo lavoro di tesi sfrutta la tecnologia Ajax [16] per il
caricamento asincrono del contenuto dei widget. La richiesta del documento
pageEditor.xhtml produce un documento HTML contenente la definizione dei widget

container, ossia un insieme di elementi <li> aventi particolari attributi data-, come
descritto nella sezione 5.1.2. Una volta che tale documento è stato caricato nel contesto

38


del browser, per ogni widget container contenuto nella Design Area, si effettua una
richiesta (per il contenuto del widget):


Per la risorsa che risiede all’URL indicato dal valore dell’attributo datatemplatepath



del widget container (riga 8 codice 5.5)

Con parametro avente nome id e valore corrispondente a quello dell’attributo
data-dbid

del widget container (riga 5 codice 5.5)

Il codice HTML del widget richiesto, contenuto nella risposta, viene inserito
all’interno del widget container opportuno. Più precisamente, il contenuto viene
inserito all’interno dell’elemento <div> appartenente alla classe widget-wrapper (riga
13 codice 5.5). I particolari relativi alla costruzione lato server del widget richiesto
(avente id data-dbid) vengono illustrati nella sezione 5.2.
La figura 5.1 rappresenta un diagramma di sequenza d’esempio relativo al caricamento
nel Page Editor di una pagina con due widget. Dopo aver ottenuto il documento
pageEditor.xhtml,

vengono inviate in sequenza le richieste per i widget aventi data-

dbid=30 e data-dbid=2. Una volta che il codice HTML relativo ai due widget sarà reso

disponibile verrà inserito all’interno del widget container opportuno.
BROWSER
UI

AJAX
ENGINE

PAGE EDITOR
SERVICE BEAN

PROJECTS
WIDGET BEAN

SESSIONS
WIDGET BEAN

pageEditor.xhtml?pageID=1
(HTML)
load projects widget ID=30
load sessions widget ID=2

.../projects.xhtml?id=30

inserisci HTML
nel widget container

inserisci HTML
nel widget container

.../sessions.xhtml?id=2
(HTML)

(HTML)

Figura 5.1 - Diagramma di sequenza relativo al caricamento nel Page Editor di una pagina con 2
widget

La richiesta dei widget e il loro caricamento nei widget container vengono
implementati mediante il codice 5.7:

39




In riga 3, mediante a un selettore jQuery, si ottengono i riferimenti agli
elementi <li> di classe widget-container. Per ognuno di essi, nelle righe 811, viene invocato il metodo jQuery load() [17] avente per argomenti:
o URL della risorsa desiderata (valore di data-templatepath)
o Stringa contenente i parametri della richiesta (valore di data-dbid)
o Funzione di callback da eseguire quando la richiesta è stata completata



In

riga

8,

$(pageWidgets[i]).find('.widget-wrapper')

fornisce

il

riferimento all’elemento nel quale inserire il codice HTML contenuto nella
risposta.
Codice 5.7
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

JS

function loadPageWidgets() {
var pageWidgets = [];
var pageWidgets = $('#page .widget-container);
for (var i = 0; i < pageWidgets.length; i++)
{
...
$(pageWidgets[i]).find('.widget-wrapper').fadeOut();
$(pageWidgets[i]).find('.widget-wrapper').load(
$(pageWidgets[i]).attr('data-templatepath'),
"id=" + $(pageWidgets[i]).attr('data-dbid'),
function(responseText, statusText, xhr) {
...
});
...
} //end for
}

5.1.4

Il managed bean per il Paged Editor

Il managed bean associato al documento pageEditor.xhtml è definito dalla classe
EditorServiceBean.java:



Espone al documento pageEditor.xhtml i seguenti attributi attraverso metodi
getter/setter:
o String JSONObj: Stringa in formato JSON [18] utilizzata per il
salvataggio dei dati (attributi data-) relativi ai widget contenuti nella
Design Area.
o String pageScreenshot: Stringa contenente i dati relativi all’anteprima
del contenuto della Design Area.
40


o Page currentEditorPage: Oggetto di tipo Page (Entity Page, vedi
sezione 5.3.2) relativo alla pagina in fase di editing nella Design Area.
o List<Widget> textWidgets: Lista di oggetti di tipo Widget (Entity
Widget,

vedi sezione 5.3.2). E’ utilizzata per il caricamento nel widget

store dei widget appartenenti alla categoria “text”.
o List<Widget> tableWidgets: Lista di oggetti di tipo Widget utilizzata
per il caricamento nel widget store dei widget di tipo “table”.
o List<Widget> chartWidgets: Lista di oggetti di tipo Widget utilizzata
per il caricamento nel widget store dei widget di tipo “chart”.
o List<Widget> pageDetail: Lista di oggetti di tipo Widget utilizzata per
il caricamento dei widget container nella Design Area. Il suo utilizzo in
pageEditor.xhtml



è già stato descritto i precedenza (codice 5.5)

Espone i seguenti metodi pubblici:
o public String save (Integer pageID): metodo invocato per il
salvataggio della pagina rappresentata nella Design Area, avente id
pageID

o public void savePageScreenshot (Integer pageID) : metodo invocato
per il salvataggio dell’anteprima della Design Area


È annotato come @RequestScoped [19]. Utilizzando questa annotazione
un’istanza del managed bean verrà creata ad ogni richiesta di un documento
contenente riferimenti ad attributi e metodi esposti dal managed bean.



Possiede un metodo privato init() annotato come @PostConstruct [20].
Questa annotazione viene utilizzata per identificare un metodo che deve essere
eseguito non appena un’istanza dell’oggetto EditorServiceBean viene creata.
Quando si accede al Page Editor per personalizzare una pagina, da un punto di
vista implementativo, si effettua una richiesta
o

Per la risorsa pageEditor.xhtml

o Con parametro avente nome pageID e valore corrispondente all’ID della
pagina che si desidera personalizzare.
Lo scopo del metodo init() è quello di estrarre dalla richiesta il valore del
parametro pageID e popolare la lista pageDetail, utilizzata in seguito

41


nell’elaborazione del documento pageManager.xhtml per generare gli elementi
<li>

corrispondenti ai widget container.

5.1.5

Salvataggio di una pagina

Quando l’utente, durante l’utilizzo del Page Editor, decide di rendere persistenti le
modifiche apportate alla pagina preme il pulsante Save. Ciò innesca una catena di
operazioni che coinvolgono l’esecuzione di codice lato client (JavaScript), lato server
(Java) e l’utilizzo di particolari tag JSF (XHTML) per l’implementazione della
tecnologia Ajax. In codice 5.8 si riporta il frammento di codice XHTML destinato alle
operazioni di salvataggio della pagina. Si sottolinea come la tecnologia JSF supporti
Ajax attraverso librerie Javascript integrate. Il tag JSF <f:ajax> [21] permette di
implementare funzionalità Ajax senza la necessità di codice JavaScript aggiuntivo.
Codice 5.8
1
2
3
4
5
6
7
8
9
10
11
12
13
14

XHTML

<h:form id="saveForm">
<h:inputHidden id="pageID"
value="#{editorServiceBean.currentEditorPage.pageID}"/>
<h:inputHidden id="JSONObj"
value="#{editorServiceBean.JSONObj}" />
<h:inputHidden id="pageScreenshot"
value="#{editorServiceBean.pageScreenshot}"/>
<h:commandButton id="invisibleScreenshotSendClick">
<f:param name="pageID"
<f:ajax execute="pageScreenshot" render="@none"
listener="#{editorServiceBean.savePageScreenshot(
editorServiceBean.currentEditorPage.pageID)}"/>
</h:commandButton>
<h:commandLink class="action-menu-item"
action="#{editorServiceBean.save(editorServiceBean.currentEdit
orPage.pageID)}" onclick="editorManager.objectify();
saveScreenshot();">
...
<f:ajax delay=”100” execute=”JSONObj” render=”JSONObj”
onevent="ajaxSaveMonitor"
onerror="ajaxSaveErrorMonitor"/>
<f:param name="pageID"
</h:commandLink>
</h:form>

42


Si riportano i passaggi del processo di salvataggio della pagina:
1.

L’utente preme il pulsante per il salvataggio

2.

Viene invocato (codice 5.8 riga 9) il metodo objectify() esposto dall’oggetto
Javascript editorManager definito in main.js. Questo oggetto implementa il
design pattern revealing module pattern [22], che permette di creare un oggetto
JavaScript in grado di esporre pubblicamente alcuni attributi e funzioni. Il
metodo objectify() salva nell’elemento nascosto JSONObj (codice 5.8 riga 3)
una stringa in formato JSON contenente una lista di oggetti rappresentanti i
widget container. Gli attributi di tali oggetti coincidono con i valori degli
attributi dei widget container data-dbId, data-widgetType, data-config,
data-row, data-col, data-width, data-height, data-pageId.

3.

Viene invocato (codice 5.8 riga 9), nel contesto di una transazione Ajax, il
metodo editorServiceBean.save(pageID) . Il metodo save(pageID) è esposto
dal managed bean EditorServicBean ed è responsabile per il salvataggio nel
database dei widget contenuti nella Design Area. In figura 5.2 viene
rappresentato il processo eseguito dal metodo save(PageID). A scopo di
chiarimento, il controllo “widgetsInEditor[i] ha dbId==null?” equivale a
verificare se l’i-esimo widget in widgetsInEditor non è presente nel database.

4.

Una volta che il metodo save() ha aggiornato il campo nascosto JSONObj, la
transazione Ajax è terminata. La funzione JavaScript ajaxSaveMonitor (codice
5.8 riga 11) monitora gli eventi associati alla transazione Ajax relativa alla
procedura di salvataggio. Quando lo stato della transazione coincide con
“success” la funzione ajaxSaveMonitor aggiorna gli attributi data- dei widget
container con i dati contenuti in JSONObj.

Parallelamente alla transazione Ajax che permette il salvataggio della pagina, viene
avviata un’ulteriore transazione che consente di salvare un’anteprima del contenuto
della Design Area. Il motivo per il quale si è scelto di suddividere queste due
operazioni in transazioni Ajax distinte è dettato dalla lunghezza variabile e spesso
prolungata dell’operazione di creazione dell’anteprima. Suddividendo le due
operazioni è possibile salvare immediatamente la pagina senza dover attendere il
completamento della creazione dell’anteprima.

43


Il salvataggio dell’anteprima è reso possibile dalla libreria JavaScript html2Canvas
[23] utilizzata dalla funzione (codice 5.8 riga 9) saveScreenshot(). html2Canvas
permette di generare la rappresentazione grafica del contenuto di un elemento HTML.
Tale rappresentazione viene fornita dalla libreria sotto forma di un elemento HTML di
tipo <canvas> [24]. È possibile ottenere una stringa (esempio in figura 5.2) che
codifica il contenuto dell’elemento <canvas>. La strategia adottata in questo lavoro di
tesi è di salvare tale stringa nel database.
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAVgAAAE/CAYAAAADnduiAAAAA
XNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAACoKSURBVHhe7d0HeBTV2gfwF9JDQujV0HsR
QYo0RayIF/ … xviLZ2GsA8bAAAAAElFTkSuQmCC
Figura 5.2 - Esempio di una stringa che codifica il contenuto di un elemento <canvas >

44


save(PageID)

NO

Aggiorna in DB il
widget con ID=dbId

Aggiungi in DB
widgetsInEditor
[i] appartenente
alla pagina PageID

Ricava da JSONObj
elenco widget nella
design area e popola
lista
widgetsInEditor

Ricava da DB elenco
widget nella pagina
PageID e popola
lista widgetInPage

Ricava da DB
informazioni sulla
pagina con ID =
PageID

SI

widgetsInEdito
r[i] ha dbId ==
null?

NO

widgetsInEdito
r è vuota?

NO

Aggiorna
widgetsInEditor
[i] con il nuovo
dbId

Sono stati
analizzati tutti i
widget in
widgetsInEdito
r ?

SI

SI

Rimuovi da DB tutti i
widget contenuti in
widgetInPage che
non sono contenuti
in
widgetInEditor

return

Aggiorna JSONObj
con
widgetsInEditor
aggiornata

Figura 5.3 - Flow chart relativo al metodo save esposto da EditorServiceBean

45


5.1.6

Widget store e aggiunta di un widget

alla design area
Così come i widget container, anche gli elementi elencati nel widget store fanno largo
uso dei custom data attributes. Il codice 5.9 riportato di seguito rappresenta il codice
XHTML dedicato alla generazione dell’elenco dei widget appartenenti alla categoria
table.
Codice 5.9
1
2
3
4
5
6
7
8
9
10
11
12
13
14

XHTML

<ui:repeat value="#{editorServiceBean.tableWidgets}" var="widget">
<li class="widget-store-view" title="Click to pin
#{widget.name} to the design area"
data-widgettype="#{widget.widgetID}"
data-defaultsizex="#{widget.defaultSizeX}"
data-defaultsizey="#{widget.defaultSizeY}"
data-templatepath="#{widget.templatePath}"
data-defaultconfigjson="#{widget.defaultConfigJSON}"
data-stylepath="#{widget.stylePath}"
data-scriptpath="#{widget.scriptPath}">
<div class="widget-store-info">
...
</div>
</li>
</ui:repeat>

Quando un utente sceglie di inserire nella design area un widget dal widget store, viene
invocata la funzione pinToPage(widgetToPin) esposta dall’oggetto JavaScript
editorManager.

Questa funzione farà in modo che venga aggiunto un nuovo widget

container nella design area. Più precisamente verrà inserito un elemento <li>
appartenente alla classe widget-container e avente attributi data- con valori
corrispondenti a quelli degli attributi data- dell’elemento widgetToPin, passato come
argomento alla funzione. L’argomento widgetToPin è un riferimento ad un elemento
<li>

appartenente alla classe widget-store-view (vedi codice 5.9 riga 2).

La funzione pinToPage, nell’ambito di una transazione Ajax, si occupa di effettuare la
richiesta per caricare il contenuto del widget nel widget container. L’URL della risorsa
richiesta corrisponde all’attributo data-templatepath dell’elemento widgetToPin.

46


5.2

Widget

5.2.1

Linee guida per lo sviluppo di un

widget
Quando si desidera sviluppare un nuovo widget occorre fornire:


Directory widget-name-pkg contenente:
o widget-name.xhtml: Documento che deve rispettare una determinata
struttura, descritta in seguito. widget-name.xhtml è il documento al
quale si riferisce l’URL contenuto nell’attributo data-templatepath.
o style.css: Foglio di stile per il contenuto del widget.
o script.js: Codice Javascript necessario per il funzionamento del
widget.



Managed Bean: Java Bean che può essere creato nel caso si vogliano esporre
attributi e metodi al documento widget-name.xhtml.

La costruzione del documento widget-name.xhtml deve cominciare dal codice
XHTML 5.10. È possibile notare come la struttura richiami i concetti introdotti nella
sezione 3.2.2.. Le parti dove lo sviluppatore del widget può inserire il contenuto
desiderato sono indicate nelle righe 4,7,12,15.
Codice 5.10
1
2
3
4
5
6
7
8
9
10
11
12
13
14

XHTML

<ui:composition>
<div class=”widget-view”>
<div class="widget-header">
Contenuto header widget
</div>
<div class=”widget-content”>
Contenuto informativo Widget
</div>
</div>
<div class=”widget-configuration-view hidden”>
<div class=”configuration-header”>
Contenuto header configurazione
</div>
<div class=”configuration-content”>

47


15
16

Contenuto configurazione widget
</div>
<div class=”configuration-footer widget-configurationbuttons pull-right”>
<a class="btn btn-success btn-sm projects-widgetconfiguration-apply-btn">Apply</a>
<a class="btn btn-default btn-sm widgetconfiguration-cancel-btn">Cancel</a>
</div>

17
18
19
20
21
22

</div>
</ui:composition>

5.2.1.1

Caricamento di un widget

Come già descritto nella sezione 5.1.3 il caricamento di un widget all’interno del
widget container associato avviene, nell’ambito di una transazione Ajax, mediante una
richiesta


Per la risorsa che risiede all’URL indicato dal valore dell’attributo datatemplatepath



del widget container

Con parametro avente nome id e valore corrispondente a quello dell’attributo
data-dbid

del widget container

Il managed bean del widget per il quale si desidera caricare il contenuto deve essere in
grado di:


Estrarre dalla richiesta il valore del parametro id



Caricare le configurazioni del widget



Applicare le configurazioni al contenuto

L’implementazione del managed bean è a discrezione dello sviluppatore di un widget.
Nella sezione 5.2.4 viene riportata la soluzione adottata nello sviluppo dei widget per
la dashboard di SOMO.

5.2.1.2

Applicazione delle configurazioni

L’oggetto JavaScript editorManager, già utilizzato nella sezione 5.1.5 con la
funzione objectify(), è visibile anche al codice JavaScript associato ad un widget
(file script.js contenuto nella directory widget-name-pkg). Tra le diverse funzioni
esposte da editorManager, si sottolinea la presenza della funzione

48


applyWidgetConfig(wdgContainer, jsonConfigString) ,

addetta all’applicazione

delle configurazioni impostate dall’utente ad un certo widget. Gli argomenti di
questa funzione sono:


wdgContainer,

riferimento all’elemento HTML di classe widget-container

che contiene il widget in questione.


jsonConfigString,

la stringa in formato JSON contenente le informazioni

sulla configurazione del widget.
Il codice contenuto in script.js, al momento dell’applicazione delle configurazioni,
deve preoccuparsi di:
1. Comporre la stringa JSON di configurazione.
2. Selezionare l’elemento di classe widget-container che contiene il widget al
quale si desidera applicare le configurazioni.
3.

Invocare la funzione applyWidgetConfig(wdgContainer, jsonConfigString) .

La funzione applyWidgetConfig(wdgContainer, jsonConfigString) si occuperà di:
1. Impostare la stringa jsonConfigString come valore dell’attributo data-config
dell’elemento <li> di classe widget-container (codice 5.5 riga 7) riferito da
wdgContainer.

2. Ricaricare il widget con le configurazioni aggiornate. Questa operazione
avviene, nell’ambito di una transazione Ajax, mediante una richiesta:
a. Per la risorsa widget-name.xhtml

all’URL indicato dal valore

dell’attributo data-templatepath del widget container wdgContainer
b.

Con parametro avente nome config e valore jsonConfigString

La risposta conterrà il codice HTML relativo al widget con le configurazioni
aggiornate. Il contenuto di tale risposta viene inserito all’interno dell’elemento
<div>

di classe widget-wrapper (codice 5.5 riga 13), figlio di wdgContainer.

Il managed bean del widget per il quale si desidera aggiornare il contenuto deve essere
in grado di:


Estrarre dalla richiesta il valore del parametro config



Applicare le configurazioni

49


L’implementazione del managed bean è a discrezione dello sviluppatore di un widget.
Nella sezione 5.2.2 viene riportata la soluzione adottata nello sviluppo dei widget per
la dashboard di SOMO.

5.2.2

Managed bean: soluzione proposta dai

widget per la dashboard di SOMO
In figura 5.4 si riporta il processo di inizializzazione dei managed bean creati per i
widget della dashboard di SOMO. Parlando di processo di inizializzazione si fa
riferimento ad un metodo annotato come @PostConstruct contenuto nel managed
bean.
Con riferimento al flow chart (figura 5.4) è possibile discriminare i tre casi per i quali
può venire richiesta la risorsa widgetName.xhtml:
1. Caricamento di un widget nella design area: è il caso, descritto nella sezione
5.1.3, in cui la richiesta contenga il parametro id.
2. Applicazione delle configurazioni per un widget nella design area: è il caso in
cui la richiesta contenga il parametro config. In questo caso non è necessario
alcun accesso al database. Il managed bean, infatti, viene utilizzato solamente
per applicare al codice HTML del contenuto del widget le configurazioni
impostate dall’utente.
3. Inserimento di un widget dal widget store alla design area: è il caso in cui la
richiesta non contenga né il parametro id né il parametro config. L’assenza del
parametro id è dovuta al fatto che il widget appena aggiunto ad una pagina,
non essendo ancora presente nel database, non possiede un id.

50


Managed
Bean Init

Estrazione dei
parametri dalla richiesta

Nella richiesta è
contenuto
parametro id?

SI

Estrai valore widgetID
del paramentro id

SI

Carica da DB la stringa
di configurazione in
formato JSON per il
widget con ID widgeID

Estrai valore
jsonConfigString
del paramentro config

NO

Nella richiesta è
contenuto
parametro
config?

NO

Carica da DB la stringa
di configurazione di
default per il widget
richiesto

Applica configurazione

Fine init

Figura 5.4 - Flow chart relativo all'inizializzazione dei managed bean per i widget della dashboard di
SOMO

51


5.3

Accesso ai dati

5.3.1

Estensione del database esistente

In figura 5.5 è rappresentata la porzione di database realizzato. La tabella (sfondo
tratteggiato) user_somo fa parte del database esistente, somodb. Le rimanenti tabelle
sono state aggiunte a somodb al fine di raggiungere gli scopi di questo lavoro di tesi.
tblPage

tblPageDetail

PK PageID

PK PageWidgetID

tblWidget
PK WidgetID

Name

FK PageID

Name

Scope

FK WidgetID

DefaultSizeX

Creator

ConfigJSON

DefaultSizeY

LastEditDate

Row

TemplatePath

PreviewImage

Col

ScriptPath

Width

StylePath

Height

DefaultConfigJSON
Thumbnail

Description
FK Scope

FK Type

tblUserEditorSettings
PK UserEditorSettingsID
FK CurrentDashboardPageID

tblScope
PK ScopeID

tblWidgetType
PK WidgetTypeID

Name

TypeName

FK UserID

user_somo
PK id
username

...

Figura 5.5 - Estensione del database esistente

52


La porzione di database realizzato, nonostante sia di tipo relazionale, al suo interno
contiene dei dati strutturati in maniera particolare. Si fa riferimento agli attributi
ConfigJSON della tabella tblPageDetail e DefaultConfigJSON

della tabella tblWidget.

Questi attributi, di tipo String, contengono al loro interno dati in formato JSON. La
scelta di utilizzare questo approccio è motivata dal fatto che i dati delle configurazioni
dei widget non hanno una struttura comune definibile a priori. In questo modo, è
possibile permettere a sviluppatori di terze parti di realizzare i propri widget senza
conoscere gli aspetti implementativi del modo in cui i dati vengono resi persistenti.

5.3.2

JPA: Implementazione di Entity e

Session EJB
Il database realizzato, come descritto in precedenza, è di tipo relazionale. La parte
server dell’applicazione è scritta in un linguaggio Object-oriented: Java. In Java, un
modo per accedere ai dati contenuti in un database relazionale è attraverso l’uso
dell’API JDBC (Java Database Connectivity). Essa permette la connessione al
database, l’esecuzione di comandi SQL (Structured Query Language) e la raccolta dei
risultati. Sebbene ancora ampiamente utilizzato, JDBC è stata sostituita dai più
flessibili strumenti ORM (Object-relational mapping).
Il principio su cui si basano gli strumenti ORM consiste nel delegare l’accesso ai
database relazionali ad altri framework, i quali offrono agli utilizzatori una visuale
object-oriented dei dati relazionali, mappando i dati relazionali in oggetti e viceversa.
Esistono diversi framework ORM, tra i quali JPA (Java Persistence API) [25], incluso
in Java EE 6 e utilizzato in questo lavoro di tesi. I componenti principali di JPA sono
i seguenti:


ORM, il meccanismo che si occupa del mapping bidirezionale oggetti-tabelle
dei database relazionali.



Entity Manager API, che consente di eseguire le operazioni CRUD nel
database, quali Create, Read, Update, Delete.



JPQL (Java Persistence Query Language), il quale permette di recuperare i dati
mediante query espresse in un linguaggio object-oriented.



JTA (Java Transaction API), che gestisce l’accesso concorrente ai dati.
53


Gli oggetti Java che vengono “tradotti” in tabelle e viceversa vengono denominati
entity. JPA permette di gestire le entity: aggiungere una entity ad un database,
rimuoverla, aggiornarla, ecc. È possibile definire una entity creando una classe Java e
annotandola come @Entity. La classe che definisce una entity, in generale, possiede:


Attributi che corrispondono alle colonne della tabella alla quale la entity fa
riferimento.



Costruttore.



Metodi getter e setter per esporre gli attributi.

In questo lavoro di tesi sono state definite sei entity, una per ogni tabella della porzione
di database realizzata, denominate:


Page.java



PageDetail.java



Scope.java



UserEditorSetting.java



Widget.java



WidgetType.java

La definizione delle entity può essere automatizzata, grazie a particolari strumenti
proposti dagli ambienti di sviluppo come NetBeans, utilizzato in questo lavoro di tesi.
A titolo di esempio si riporta nel codice 5.11 la definizione dell’entity Page.java. Si
sottolineano i seguenti particolari:


Riga 1: annotazione @Entity.



Riga 2: annotazione @Table che permette di indicare il nome tabella nel
database corrispondente alla entity che si sta definendo.



Riga 4: annotazione @NamedQueries che permette di indicare un insieme di
@NamedQuery,

ossia query definite in linguaggio SQL. Le query indicate

possono essere utilizzate in un modo simile ad un metodo Java, avente nome
name

e una lista di eventuali parametri. In seguito verrà mostrato un esempio

d’uso di una query.


Righe 10-13: definizione di un attributo, in questo caso corrispondente alla
primary key della tabella tblPage.

54


o Annotazione @Id utilizzata per denotare una chiave primaria.
o Annotazione @GeneratedValue utilizzata per specificare il metodo di
generazione dei valori per la chiave primaria. In questo caso il metodo
scelto è AUTO che delega la creazione del valore al DBMS (Database
Management System).
o Annotazione @Column utilizzata per indicare il nome della colonna
corrispondente all’attributo che si sta definendo, in questo caso PageID.
o Integer pageID indica il tipo associato all’attributo pageID.


Righe 15,16: definizione di una relazione uno-a-molti tra le tabelle tblPage e
tblPageDetail

o Annotazione @OneToMany utilizzata per definire il tipo di relazione.
o Cascade=CascadeType.ALL indica che ogni operazione sulla entity Page
verrà propagata alle entity associate.
o fetch=FetchType.LAZY indica il metodo di fetch mediante il quale
vengono

caricati

da

pageDetailCollection.

database

gli

elementi

della

collection

In questo caso, il tipo LAZY indica che la

collection sopra citata verrà popolata solamente quando si cerca di
accedere ai suoi valori, attraverso i metodi getter e setter associati.
Codice 5.11
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

JAVA

@Entity
@Table(name = "tblPage")
@XmlRootElement
@NamedQueries({
@NamedQuery(name="Page.findAll", query="SELECT p FROM Page p"),
//Altre named Query
@NamedQuery(name="Page.findByScope", query="SELECT p FROM Page
p WHERE p.scope =:scope"),
@NamedQuery(name="Page.findByCreatorAndScope", query="SELECT p
FROM Page p WHERE (p.scope=:scope AND p.creator=:creator)")})
public class Page implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "PageID")
private Integer pageID;
//altri attributi
@OneToMany(cascade=CascadeType.ALL, mappedBy="pageID",
fetch=FetchType.LAZY)
private Collection<PageDetail> pageDetailCollection;

55


18
19
20
21

public Page(){
}
//Metodi getter e setter

Le entity racchiudono i dati, le relazioni e, eventualmente, semplici regole di
validazione. Le entity vengono gestite da altri componenti, detti session bean. Essi
vengono utilizzati per implementare business logic, processi e workflow. Esistono tre
tipi di session bean: stateless, stateful e singleton. In questo lavoro di tesi si è fatto uso
di session bean di tipo stateless, adatti nei casi in cui ogni operazione necessaria può
essere conclusa in un’unica chiamata ad un metodo [26]. Esempi di operazioni di
questo genere possono essere la creazione, l’aggiornamento, la rimozione di entity nel
database e l’esecuzione di una query.
Così come le entity, anche la definizione dei session bean può essere automatizzata. In
questo lavoro di tesi sono stati definiti sei stateless session bean, uno per ogni entity:


PageFacade.java



PageDetailFacade.java



ScopeFacade.java



UserEditorSettingFacade.java



WidgetFacade.java



WidgetTypeFacade.java

Tutti i session bean sopra elencati estendono una classe astratta, AbstractFacade.java,
che espone i seguenti metodi generici:


public void create(T entity)



public void edit(T entity)



public void remove(T entity)



public T find(Object id)



public List<T> findAll()



public List<T> findRange(int[] range)

A titolo di esempio si riporta nel codice 5.12 la definizione dello stateless session bean
PageFacade.java,

della quale si sottolineano i seguenti particolari:

56




Riga 1: Annotazione @Stateless che indica il tipo di session bean
implementato.



Riga 4: L’entity manager è un componente fondamentale in JPA. Esso gestisce
lo stato e il ciclo di vita delle entity. Quando un entity manager ottiene un
riferimento a una entity, essa si dice essere managed. Fino a quel momento, la
entity è vista come un normale POJO (Plain Old Java Object). Grazie a JPA,
le entity possono essere utilizzate dai vari livelli di un’applicazione come
normali oggetti Java, finché non si renda necessario caricare o inserire dati nel
database. Quando si rendono necessarie tali operazioni, le entity vengono
gestite (managed) dall’entity manager che sincronizza lo stato delle entity con
il database.



Riga 3: Annotazione @PersistenceContext. Il persistence context, che può
essere visto come un primo livello di cache, è un insieme di istanze di managed
entity in un dato istante. L’entity manager consulta e aggiorna il persistence
context. Il parametro unitName = "somo-persistence-unit" indica l’insieme
dei dati di connessione ad un database, inclusi in un file xml di configurazione.



Righe 14-18: Utilizzo di una named query definita nella entity Page
o In riga 15 viene creato un’oggetto di tipo Query in base alle definizione
della named query ("Page.findByScope")
o In riga 16 viene impostato il parametro della query
o In riga 17 si ottengono i risultati dell’esecuzione della query
Codice 5.12

1
2
3
4
5
6
7
8
9
10
11
12
13
14

JAVA

@Stateless
public class PageFacade extends AbstractFacade<Page> {
@PersistenceContext(unitName = "somo-persistence-unit")
private EntityManager em;
@Override
protected EntityManager getEntityManager() {
return em;
}
public PageFacade() {
Super(Page.class);
}
public List<Page> getPagesByScope(Scope scope) {

57


Query PagesOfScopeQuery =
em.createNamedQuery("Page.findByScope");
PagesOfScopeQuery.setParameter("scope", scope);
return PagesOfScopeQuery.getResultList();

15
16
17
18
19

}
public List<Page> getPagesByCreatorAndScope(User userID, Scope
scope) {
…
}

20
21
22
23

}

58

Capitolo 6 - CONCLUSIONI

6 Conclusioni
In questo lavoro di tesi è stato presentato uno strumento che permette di personalizzare
le pagine di un’applicazione web esistente, denominata SOMO. Si è mostrato come
sia possibile, per ogni pagina personalizzabile, creare molteplici versioni
personalizzate e scegliere quale si desidera utilizzare. Le funzionalità implementate
sono integrate all’interno dell’applicazione SOMO e sono state sviluppate utilizzando
unicamente tecnologie web riconosciute come standard, quali HTML5, CSS3,
Javascript e Ajax. In questo modo l’utente ha la possibilità di fruire di qualsiasi
funzionalità, senza la necessità di installare alcun componente aggiuntivo al proprio
browser. Si è definito un insieme di linee guida e si è realizzata un’infrastruttura di
base per consentire a sviluppatori di terze parti di produrre widget utilizzabili in
SOMO. Gli obiettivi posti inizialmente sono dunque stati raggiunti.
Il lavoro di tesi è attualmente in fase di test e validazione. I criteri di validazione sono
sia funzionali che tecnici e riguardano principalmente gli aspetti di usabilità, sicurezza
e performance. Nel caso la validazione abbia esito positivo, il lavoro di tesi è destinato
ad entrare nell’ambiente di produzione.
Il lavoro di tesi, svolto seguendo i principi delle metodologie di sviluppo agile, ha
richiesto un tempo di circa 4 mesi. Il risultato ottenuto apre le porte a numerosi sviluppi
futuri, tra i quali:


Estensione della capacità di personalizzazione ad altre sezioni di SOMO.



Consolidamento dell’integrazione in SOMO.



Introduzione di nuovi widget.



Rafforzamento delle linee guida e dell’infrastruttura per la costruzione di
widget da sviluppatori di terze parti.



Aggiunta di funzionalità di condivisione delle pagine personalizzate.

59

Capitolo 6 - CONCLUSIONI

Personalmente mi ritengo molto soddisfatto del lavoro svolto e dei risultati ottenuti.
La varietà delle tecnologie considerate, l’apprendimento di nuove metodologie di
sviluppo, la risoluzione dei problemi incontrati e il lavoro svolto in Esteco S.p.A. a
stretto contatto con persone professionali e motivate hanno rappresentato per me
motivo di accrescimento sia formativo che personale.

60

RIFERIMENTI

Riferimenti
[1]

"Manifesto for Agile Software Development," 2001. [Online]. Available:
http://agilemanifesto.org/.

[2]

«Scrum

(software

development),»

[Online].

Available:

http://en.wikipedia.org/wiki/Scrum_(software_development).
[3]

"Esteco: Corporate," [Online]. Available: http://www.esteco.com/corporate.

[4]

"Esteco: SOMO," [Online]. Available: http://www.esteco.com/somo.

[5]

"Windows User Experience Design Principles," [Online]. Available:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd834141.aspx.

[6]

"Design

Thinking,"

[Online].

Available:

http://en.wikipedia.org/wiki/Design_thinking.
[7]

J. Knapp, «The product design sprint: a five-day recipe for startups,» [Online].
Available: http://www.designstaff.org/articles/product-design-sprint-2012-1002.html.

[8]

J. Nielsen, "F-Shaped Pattern For Reading Web Content," Nielsen Norman
Group,

17

Aprile

2006.

[Online].

Available:

http://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/.
[9]

P. J. Meyers, "Eye-Tracking Google SERPs," 5 Ottobre 2011. [Online].
Available: http://moz.com/blog/eyetracking-google-serps.

[10] Oracle,

"JavaServer

Faces

Technology,"

[Online].

Available:

http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html.

61

RIFERIMENTI

[11] D. Geary and C. Horstmann, "The Life Cycle," in Core JavaServer Faces,
Prentice Hall, 2010, pp. 20-31.
[12] Oracle, "Introduction to Facelets," Settembre 2013. [Online]. Available:
http://docs.oracle.com/javaee/7/tutorial/doc/jsf-facelets.htm.
[13] Oracle, "Using Facelets Templates," Settembre 2013. [Online]. Available:
http://docs.oracle.com/javaee/7/tutorial/doc/jsf-facelets004.htm#GIQXP.
[14] Ducksboard,

"gridster.js

Documentation,"

[Online].

Available:

http://gridster.net/#documentation.
[15] W3C, "Embedding custom non-visible data with the data-* attributes,"
[Online].

Available:

http://www.w3.org/TR/2011/WD-html5-

20110525/elements.html#embedding-custom-non-visible-data-with-the-dataattributes.
[16] "Ajax

(programming),"

[Online].

Available:

http://en.wikipedia.org/wiki/Ajax_(programming).
[17] jQuery, ".load()," [Online]. Available: http://api.jquery.com/load/.
[18] "Introducing JSON," [Online]. Available: http://json.org/.
[19] Oracle,

"Annotation

Type

RequestScoped,"

[Online].

Available:

http://docs.oracle.com/javaee/6/api/javax/enterprise/context/RequestScoped.ht
ml.
[20] Oracle,

"Annotation

Type

PostCosntruct,"

[Online].

Available:

http://docs.oracle.com/javaee/6/api/javax/annotation/PostConstruct.html.
[21] Oracle,

"Using

Ajax

with

Facelets,"

[Online].

Available:

http://docs.oracle.com/javaee/6/tutorial/doc/gkabr.html.
[22] A. Osmani, "The Revealing Module Pattern," 2012. [Online]. Available:
http://addyosmani.com/resources/essentialjsdesignpatterns/book/#revealingmo
dulepatternjavascript.

62

RIFERIMENTI

[23] N. von Hertzen, "html2canvas Documentation," [Online]. Available:
http://html2canvas.hertzen.com/documentation.html.
[24] W3C,

"The

canvas

element,"

[Online].

Available:

http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#thecanvas-element.
[25] A. Goncalves, Beginning Java EE 6 Platform with GlassFish 3, Apress, 2012.
[26] A. Goncalves, "Stateless Beans," in Beginning Java EE 6 Platform with
GlassFish 3, Apress, 2010, pp. 202-204.
[27] "Enterprise

software,"

22

Ottobre

2013.

[Online].

Available:

http://en.wikipedia.org/wiki/Enterprise_software.

63

Studio e implementazione di uno strumento di configurazione e visualizzazione di dati di progetto, nell’ambito delle applicazioni cae (computer aided engineering) (2)

Recommandé

Recommandé

Contenu connexe

Similaire à Studio e implementazione di uno strumento di configurazione e visualizzazione di dati di progetto, nell’ambito delle applicazioni cae (computer aided engineering) (2)

Similaire à Studio e implementazione di uno strumento di configurazione e visualizzazione di dati di progetto, nell’ambito delle applicazioni cae (computer aided engineering) (2) (20)

Studio e implementazione di uno strumento di configurazione e visualizzazione di dati di progetto, nell’ambito delle applicazioni cae (computer aided engineering) (2)