UNIVERSITÀ DEGLI STUDI DI TRIESTE
DIPARTIMENTO DI INGEGNERIA E ARCHITETTURA
Corso di Laurea Magistrale in Ingegneria Infor...
Alla mia famiglia
INDICE

Indice
1

Introduzione ..............................................................................................
INDICE

5.1.1

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

5.1.2

D...
Capitolo 1 - INTRODUZIONE

1 Introduzione
Lo scopo di questo lavoro di tesi è progettare e realizzare uno strumento che co...
Capitolo 1 - INTRODUZIONE

Al momento della scrittura di questo documento, nelle applicazioni web impiegate in
ambito inge...
Capitolo 2 - ANALISI

2 Analisi
2.1

Scenario

2.1.1

Sviluppo Agile

Lo sviluppo Agile è un particolare approccio allo sv...
Capitolo 2 - ANALISI

possibilità, sprint dopo sprint, di far convergere agevolmente i risultati verso le idee
dei clienti...
Capitolo 2 - ANALISI

2.1.3

Opportunità di personalizzazione in

SOMO
All’interno di una stessa organizzazione, nell’ambi...
Capitolo 2 - ANALISI



Avere livelli di importanza differenti.



Presentare troppe o troppe poche informazioni.



Es...
Capitolo 2 - ANALISI



I requisiti per lo strumento di gestione di molteplici pagine personalizzate
create da un utente....
Capitolo 2 - ANALISI



Dimensioni di default: Ossia le misure, secondo una qualche metrica, di altezza
e larghezza prede...
Capitolo 2 - ANALISI



Il Page Editor, in generale, dovrà essere accessibile da qualsiasi pagina di
SOMO considerata per...
Capitolo 2 - ANALISI

terminate e una per quelle ancora in corso. Entrambe le tabelle presentano le
stesse colonne, ossia ...
Capitolo 2 - ANALISI

PROJECTS

MY WORKSPACES

SESSIONS

SCOPE

Dashboard

Dashboard

Dashboard

CATEGORIA

Tabella

Tabel...
Capitolo 2 - ANALISI

e condividere le pagine personalizzate create ad un gruppo di utenti, gestendo i
permessi di modific...
Capitolo 3 - PROGETTAZIONE

3 Progettazione
3.1

User Experience: Principi e

processi di progettazione
Nella progettazion...
Capitolo 3 - PROGETTAZIONE

La progettazione di tutte le principali funzionalità (Page Editor, Widget e Page
Manager) si è...
Capitolo 3 - PROGETTAZIONE

Figura 3.1 - Heatmaps ricavate mediante tecniche di eyetracking

La progettazione del layout d...
Capitolo 3 - PROGETTAZIONE

2. Editor Action Pane. È il pannello dedicato ad ospitare i comandi per le
principali operazio...
Capitolo 3 - PROGETTAZIONE

d. Icona del widget. Uno studio [9], svolto sulle pagine dei risultati del motore di
ricerca G...
Capitolo 3 - PROGETTAZIONE

verticale viene automaticamente determinata, dato che i widget vengono
verticalmente posiziona...
Capitolo 3 - PROGETTAZIONE

All’interno del widget container è possibile, seguendo la numerazione considerata in
figura 3....
Capitolo 3 - PROGETTAZIONE

6. Configuration Content: Contiene l’insieme dei controlli per gestire la
configurazione delle...
Capitolo 3 - PROGETTAZIONE

Figura 3.7 – Flusso di eventi durante il caricamento di un widget e la successiva applicazione...
Capitolo 3 - PROGETTAZIONE

Workspaces e Sessions ci si è concentrati solamente nella definizione della loro Widget
View, ...
Capitolo 3 - PROGETTAZIONE

3.4

Page Manager

La fase di progettazione del Page Manager, lo strumento addetto alla gestio...
Capitolo 3 - PROGETTAZIONE

e. Page Detail Action Pane: Gruppo di tre pulsanti che permette
l’eliminazione, la modifica e ...
Capitolo 4 - INTERFACCIA

4 Interfaccia
In questo capitolo verrà presentato un esempio d’uso di quanto prodotto in questo
...
Capitolo 4 - INTERFACCIA

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

All’apertura del...
Capitolo 4 - INTERFACCIA

Figura 4.3 - Inserimento di un widget nella Design Area

Il widget scelto verrà inserito nell’an...
Capitolo 4 - INTERFACCIA

Figura 4.5 - Spostamento di un widget

È possibile ridimensionare un widget trascinando il suo a...
Capitolo 4 - INTERFACCIA

Una volta scelte le configurazioni desiderate, è possibile applicarle al widget oppure
annullare...
Capitolo 4 - INTERFACCIA

operazioni è denominato Page Manger ed è accessibile dal Page Editor facendo click
sul pulsante ...
Capitolo 4 - INTERFACCIA

Figura 4.12 – Pulsante per modificare una pagina

Per eliminare una pagina occorre fare click su...
Capitolo 4 - INTERFACCIA

Figura 4.14 - Pulsante per impostare una pagina come "corrente "(sopra) e indicatore della pagin...
Capitolo 5 - IMPLEMENTAZIONE

5 Implementazione
5.1

Page Editor

Lo strumento Page Editor è costituito dai seguenti compo...
Capitolo 5 - IMPLEMENTAZIONE



Managed Beans: Java Bean che possono essere utilizzati dai documenti
XHTML. Un Java Bean ...
Capitolo 5 - IMPLEMENTAZIONE

5.1.2

Design Area

Nella sezione 3.2.1.2 è stato illustrato il risultato della progettazion...
Capitolo 5 - IMPLEMENTAZIONE

denominati custom data attributes. Come specificato nel W3C Working Draft di
HTML5 [15], un ...
Capitolo 5 - IMPLEMENTAZIONE



In riga 1 il tag JSF <c:forEach>. Data una collezione di oggetti, in questo caso
la lista...
Capitolo 5 - IMPLEMENTAZIONE

14
15

</li>
</ui:repeat>

Il codice 5.6 riporta un esempio del codice HTML risultato dell’e...
Capitolo 5 - IMPLEMENTAZIONE

del browser, per ogni widget container contenuto nella Design Area, si effettua una
richiest...
Capitolo 5 - IMPLEMENTAZIONE



In riga 3, mediante a un selettore jQuery, si ottengono i riferimenti agli
elementi <li> ...
Capitolo 5 - IMPLEMENTAZIONE

o Page currentEditorPage: Oggetto di tipo Page (Entity Page, vedi
sezione 5.3.2) relativo al...
Capitolo 5 - IMPLEMENTAZIONE

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

corrispond...
Capitolo 5 - IMPLEMENTAZIONE

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

L’utente preme il puls...
Capitolo 5 - IMPLEMENTAZIONE

Il salvataggio dell’anteprima è reso possibile dalla libreria JavaScript html2Canvas
[23] ut...
Capitolo 5 - IMPLEMENTAZIONE

save(PageID)

NO

Aggiorna in DB il
widget con ID=dbId

Aggiungi in DB
widgetsInEditor
[i] a...
Capitolo 5 - IMPLEMENTAZIONE

5.1.6

Widget store e aggiunta di un widget

alla design area
Così come i widget container, ...
Capitolo 5 - IMPLEMENTAZIONE

5.2

Widget

5.2.1

Linee guida per lo sviluppo di un

widget
Quando si desidera sviluppare ...
Capitolo 5 - IMPLEMENTAZIONE

15
16

Contenuto configurazione widget
</div>
<div class=”configuration-footer widget-config...
Capitolo 5 - IMPLEMENTAZIONE

applyWidgetConfig(wdgContainer, jsonConfigString) ,

addetta all’applicazione

delle configu...
Capitolo 5 - IMPLEMENTAZIONE

L’implementazione del managed bean è a discrezione dello sviluppatore di un widget.
Nella se...
Capitolo 5 - IMPLEMENTAZIONE

Managed
Bean Init

Estrazione dei
parametri dalla richiesta

Nella richiesta è
contenuto
par...
Capitolo 5 - IMPLEMENTAZIONE

5.3

Accesso ai dati

5.3.1

Estensione del database esistente

In figura 5.5 è rappresentat...
Capitolo 5 - IMPLEMENTAZIONE

La porzione di database realizzato, nonostante sia di tipo relazionale, al suo interno
conti...
Capitolo 5 - IMPLEMENTAZIONE

Gli oggetti Java che vengono “tradotti” in tabelle e viceversa vengono denominati
entity. JP...
Capitolo 5 - IMPLEMENTAZIONE

o Annotazione @Id utilizzata per denotare una chiave primaria.
o Annotazione @GeneratedValue...
Capitolo 5 - IMPLEMENTAZIONE

18
19
20
21

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

Le entity racchiudono i dati, le rel...
Capitolo 5 - IMPLEMENTAZIONE



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



Riga ...
Capitolo 5 - IMPLEMENTAZIONE

Query PagesOfScopeQuery =
em.createNamedQuery("Page.findByScope");
PagesOfScopeQuery.setPara...
Capitolo 6 - CONCLUSIONI

6 Conclusioni
In questo lavoro di tesi è stato presentato uno strumento che permette di personal...
Capitolo 6 - CONCLUSIONI

Personalmente mi ritengo molto soddisfatto del lavoro svolto e dei risultati ottenuti.
La variet...
RIFERIMENTI

Riferimenti
[1]

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

[11] D. Geary and C. Horstmann, "The Life Cycle," in Core JavaServer Faces,
Prentice Hall, 2010, pp. 20-31.
[...
RIFERIMENTI

[23] N. von Hertzen, "html2canvas Documentation," [Online]. Available:
http://html2canvas.hertzen.com/documen...
Upcoming SlideShare
Loading in …5
×

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

524 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
524
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. 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
  2. 2. Alla mia famiglia
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. Capitolo 2 - ANALISI 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
  9. 9. Capitolo 2 - ANALISI 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
  10. 10. Capitolo 2 - ANALISI  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
  11. 11. Capitolo 2 - ANALISI  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
  12. 12. Capitolo 2 - ANALISI  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
  13. 13. Capitolo 2 - ANALISI  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
  14. 14. Capitolo 2 - ANALISI 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
  15. 15. Capitolo 2 - ANALISI 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
  16. 16. Capitolo 2 - ANALISI 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
  17. 17. 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
  18. 18. Capitolo 3 - PROGETTAZIONE 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
  19. 19. Capitolo 3 - PROGETTAZIONE 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
  20. 20. Capitolo 3 - PROGETTAZIONE 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
  21. 21. Capitolo 3 - PROGETTAZIONE 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
  22. 22. Capitolo 3 - PROGETTAZIONE 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
  23. 23. Capitolo 3 - PROGETTAZIONE 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
  24. 24. Capitolo 3 - PROGETTAZIONE 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
  25. 25. Capitolo 3 - PROGETTAZIONE 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
  26. 26. Capitolo 3 - PROGETTAZIONE 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
  27. 27. Capitolo 3 - PROGETTAZIONE 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
  28. 28. Capitolo 3 - PROGETTAZIONE 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
  29. 29. 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
  30. 30. Capitolo 4 - INTERFACCIA 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
  31. 31. Capitolo 4 - INTERFACCIA 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
  32. 32. Capitolo 4 - INTERFACCIA 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
  33. 33. Capitolo 4 - INTERFACCIA 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
  34. 34. Capitolo 4 - INTERFACCIA 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
  35. 35. Capitolo 4 - INTERFACCIA 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
  36. 36. Capitolo 4 - INTERFACCIA 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
  37. 37. 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
  38. 38. Capitolo 5 - IMPLEMENTAZIONE  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
  39. 39. Capitolo 5 - IMPLEMENTAZIONE 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
  40. 40. Capitolo 5 - IMPLEMENTAZIONE 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
  41. 41. Capitolo 5 - IMPLEMENTAZIONE  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
  42. 42. Capitolo 5 - IMPLEMENTAZIONE 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
  43. 43. Capitolo 5 - IMPLEMENTAZIONE 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
  44. 44. Capitolo 5 - IMPLEMENTAZIONE  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
  45. 45. Capitolo 5 - IMPLEMENTAZIONE 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
  46. 46. Capitolo 5 - IMPLEMENTAZIONE 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" value="#{editorServiceBean.currentEditorPage.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" value="#{editorServiceBean.currentEditorPage.pageID}"/> </h:commandLink> </h:form> 42
  47. 47. Capitolo 5 - IMPLEMENTAZIONE 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
  48. 48. Capitolo 5 - IMPLEMENTAZIONE 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
  49. 49. Capitolo 5 - IMPLEMENTAZIONE 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
  50. 50. Capitolo 5 - IMPLEMENTAZIONE 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
  51. 51. Capitolo 5 - IMPLEMENTAZIONE 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
  52. 52. Capitolo 5 - IMPLEMENTAZIONE 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
  53. 53. Capitolo 5 - IMPLEMENTAZIONE 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
  54. 54. Capitolo 5 - IMPLEMENTAZIONE 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
  55. 55. Capitolo 5 - IMPLEMENTAZIONE 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
  56. 56. Capitolo 5 - IMPLEMENTAZIONE 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
  57. 57. Capitolo 5 - IMPLEMENTAZIONE 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
  58. 58. Capitolo 5 - IMPLEMENTAZIONE 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
  59. 59. Capitolo 5 - IMPLEMENTAZIONE 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
  60. 60. Capitolo 5 - IMPLEMENTAZIONE 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
  61. 61. Capitolo 5 - IMPLEMENTAZIONE  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
  62. 62. Capitolo 5 - IMPLEMENTAZIONE 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
  63. 63. 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
  64. 64. 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
  65. 65. 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
  66. 66. 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
  67. 67. 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

×